Skip to content

Authority and Inheritance

This is the key precedence document for this repository. Anyone — human or AI agent — trying to work out which of two conflicting documents wins should start here.

Inheritance model

  • Company policy applies to all ventures. A policy set at company level (in docs/governance/ or docs/decisions/) binds every venture unless a documented exception exists (see below).
  • Company standards apply to ventures unless a documented exception exists. An exception must be an explicit, recorded decision (typically a venture-level ADR), not an assumption or an omission.
  • Venture documents supplement company documents. Venture-level policy, standards, and specifications add detail and constraints specific to that venture; they do not restate company material wholesale.
  • Venture documents may be stricter than company documents, but never weaker on safety-relevant dimensions. A venture may add requirements; it may not quietly drop one.
  • Venture documents cannot silently weaken company-level security, privacy, ethics, evidence, or approval requirements. Any venture-level deviation on these dimensions must be explicit, justified, and approved at the appropriate level — never implicit through omission or looser wording.
  • Product specifications inherit company and venture requirements. A product spec is written in the context of, and constrained by, both the company-level and venture-level documents that apply to it.
  • Implementation details cannot override approved specifications. If code, a workbook, or any other implementation artifact contradicts an approved specification, the implementation is wrong until the specification is formally changed — not the other way around.
  • Examples are informative, not authoritative. Sample content, illustrative snippets, and template fill-ins never carry the authority of the policy, standard, or specification they appear alongside.

Precedence order

When two pieces of guidance conflict, resolve using this order (highest first):

  1. Explicit current human instruction — a direct, current instruction from an authorized human in the moment takes precedence over any written document, because it is the most up-to-date expression of intent.
  2. Legal, security, privacy, and safety requirements — non-negotiable constraints that exist regardless of what any internal document says.
  3. Approved company ADRs and policies.
  4. Approved company standards.
  5. Approved venture ADRs and standards.
  6. Approved product specifications.
  7. Approved component specifications.
  8. Templates and guides.
  9. Implementation details (code, workbook structure, configuration as actually built).
  10. Examples and historical artifacts.

Lower-numbered items outrank higher-numbered items. A draft or proposed document does not outrank an approved document at a lower position in this list — draft/proposed status caps a document's authority regardless of its type or position (see document-metadata-standard.md for status definitions).

How contradictions must be handled

Surfacing

When a contradiction between two authoritative sources is found:

  • It must be flagged explicitly — stated in plain terms, naming both sources.
  • It must not be silently resolved by picking one interpretation and proceeding as if there were no conflict. Silent resolution hides the problem from the people who need to fix it.
  • It must be escalated to a human if it cannot be resolved unambiguously using the precedence order below, or if resolving it would affect a high-risk area (see docs/ai/task-classification-and-routing.md).

Resolving

  • If the two sources sit at different levels of the precedence order above, the higher-precedence source wins, and the lower-precedence document should be flagged for correction.
  • If the two sources sit at the same level (e.g. two approved company standards that disagree), this is not something an agent or contributor resolves unilaterally — escalate to a human with decision rights over that document type (see decision-rights.md).
  • Once a human resolves a same-level conflict, the resolution should be recorded (e.g. as an ADR or an update to one of the conflicting documents with a note explaining the change) so the conflict does not resurface unnoticed.

Report an issue about this page