34 lines
2.3 KiB
Markdown
34 lines
2.3 KiB
Markdown
# Workflow and Decision Authority
|
|
|
|
## Authority order
|
|
|
|
Use the first applicable authority:
|
|
|
|
1. Approved feature contract and explicit user decisions
|
|
2. Governing physics, mathematics, standards, and safety obligations
|
|
3. Official documentation and verification cases for a project-selected reference product or format
|
|
4. Repository architecture decisions, configuration, and established conventions
|
|
5. The simplest deterministic choice that preserves the authorities above
|
|
|
|
A commercial solver is a behavioral reference only when the project contract selects it. Its public input semantics, output definitions, documented procedures, and verification examples may support decisions; never infer undocumented internals or claim implementation equivalence.
|
|
|
|
## Autonomous decisions
|
|
|
|
Proceed without user review for reversible choices within approved contracts: internal naming and data layout, test organization, diagnostics, equivalent implementation mechanics, documentation formatting, and correction of clear build or test defects. Record assumptions that affect interpretation.
|
|
|
|
## User decisions
|
|
|
|
Return `needs-user-decision` only for a choice that changes at least one of:
|
|
|
|
- supported physics, formulation meaning, or analysis scope;
|
|
- public compatibility or an authoritative I/O schema;
|
|
- acceptance choices where reasonable criteria split the same evidence between pass and fail and change product acceptance or a public accuracy promise, or where authoritative requirements and reference evidence cannot be reconciled technically;
|
|
- a material security/trust-boundary or credential-handling change, or acceptance of an unresolved security, legal, licensing, or compliance risk;
|
|
- external reference-solver execution, destructive history changes, publication, deployment, or release.
|
|
|
|
Everything else follows the authority order. Lack of a preference is not a blocker when a deterministic in-contract choice exists.
|
|
|
|
## Contract flow
|
|
|
|
Requirements own acceptance intent; research owns evidence; formulation owns mathematics; numerical review owns independent numerical findings and logical verification coverage; I/O owns external/internal mappings; implementation owns code and tests; physics review owns physical plausibility; release review owns closure evidence. A downstream stage returns a defect to the owning upstream stage instead of silently rewriting its contract.
|