Operating Obligation Record

Machine authority

architecture/operating-obligations.ts defines the Zod and JSON-compatible TypeScript contract. This note explains its semantics; it does not duplicate the field schema.

Record sections

Section Required meaning
Source Verifiable title and citation; jurisdiction/revision/effective dates where relevant
Force Binding, contractual, normative, or explicitly committed
Applicability applicable, not-applicable, or open, plus products, modules, actors, data, interfaces, rationale, authority, and decision
Interpretation Approved Idea references and the product/system meaning of the source
Requirements Atomic statements, state, Behaviour references, acceptance criteria, and prohibited outcomes
Controls Implementation/Infra references, named commands, failure behaviour, and recovery
Assurance Suites, Tests, runtime evidence, Anomalies, Events, Journals, and verification method
Accountability Owner, approver, escalation, and review cadence

State rules

  • as-built means current implementation and verification evidence exist.
  • target means an approved decision and acceptance criteria exist.
  • mixed must be decomposed into separately state-labelled requirements or controls.
  • open names the unresolved decision and the authority that must resolve it.
  • applicable and not-applicable require a durable decision reference; open does not masquerade as either conclusion.

Nine-hub mapping

References use the existing prefixes only: idea:, implementation:, journal:, behaviour:, suite:, test:, anomaly:, infra:, and event:. obligation: identifies the boundary record itself; it is deliberately not accepted as a semantic-hub reference.

Current seed

The register contains one honest seed: CareerVector's explicit zero-user-cost commitment. It is target-state because the complete Behaviour, control, and assurance chain is not yet linked. The seed proves the schema without pretending that a legal review or implementation gate already exists.

Change discipline

Changing a source, applicability conclusion, requirement, or prohibited outcome is an architectural decision. Updating evidence links after implementation is traceability maintenance. Both are reviewed, but only the former changes product meaning.

Source: architecture/modules/operating-obligation-record.md