Source Authority

Authority rule

The workflow is source-grounded. A claim may enter public RFC text only when an accepted claim record ties it to source evidence or to an explicit design decision recorded in evidence artifacts.

Authority hierarchy

When sources disagree, use the highest available authority.

1. Primary source corpus
   • Checked-in source text, schemas, fixtures, examples, tests, traces, captured protocol exchanges, or other first-order artifacts in scope for the selected pack.
   • Exact locators are required.
2. Source-derived discovery aids
   • Graphs, indexes, inventories, relationship extracts, search handles, or equivalent aids derived from the corpus.
   • Use them to find and cross-check evidence, not to replace it.
3. Project-pack orientation context
   • Curated terminology, concept maps, prior synthesis, and corpus notes supplied by the selected pack.
   • Useful for orientation; not sufficient by itself for public technical claims.
4. Source scout reports
   • Bounded summaries produced from specific source areas or observations.
   • They must carry locators and uncertainty notes.
5. Workflow notes and prompts
   • Operational intent, structure, and run control.
   • Never authoritative for technical behavior.
6. Synthesized RFC prose
   • Workflow output.
   • It must be corrected whenever it conflicts with higher authority.

Claim classes

Every claim record uses one class.

• Source-grounded — directly supported by primary source evidence.
• Map-supported — discovered through a source-derived aid and then confirmed against primary source locators.
• Context-supported — introduced by orientation context and still awaiting source confirmation.
• Inferred — derived from multiple grounded facts; requires explicit reviewer approval before public use.
• Design decision — chosen intentionally by the workflow; not presented as discovered behavior.
• Open question — unresolved; cannot appear in final public text as settled behavior.
• Rejected — disproven, stale, duplicate, or out of scope.

Backing-record discipline

Public prose is composed from backing records; it is not written first and justified later.

For each accepted claim record, keep enough evidence to show how the claim was established:

• read — grounded by direct source reading.
• observed — grounded by an execution, trace, or other observed behavior.
• inferred — grounded by combining accepted source-backed facts.
• pending — carried forward but not yet verified; never permitted in final public deliverables.

A public requirement with no accepted backing record is ungrounded and must be removed, repaired, or escalated.

Claim admission checklist

A claim may move to accepted only when:

• [ ] It has a stable claim ID.
• [ ] It states one behavior, rule, constraint, or definition.
• [ ] It names the relevant source or design-decision ID.
• [ ] It includes a source locator, observation handle, discovery-aid reference, or evidence artifact reference.
• [ ] It records whether the claim is normative, explanatory, or illustrative.
• [ ] It identifies affected RFC sections.
• [ ] It has no unresolved contradiction.
• [ ] It has reviewer status recorded.

Evidence reference shape

Use compact references in evidence artifacts:

• source_id — stable identifier for the source unit.
• path — repository-relative path when applicable.
• locator — line range, section name, symbol, fixture, packet, or other stable localizer.
• established_by — read, observed, inferred, or pending.
• excerpt_hash — short checksum when exact text needs tamper detection.
• discovery_ref — source-map query ID, node ID, edge ID, search handle, or equivalent reference.
• observed_in — example, validation, or review artifact that exercised the claim.
• verified_at — run-local timestamp, digest, or sequence marker.
• notes — brief uncertainty, conflict, or interpretation notes.

Keep long excerpts and raw retrieval output in evidence artifacts, not in public RFC prose.

Conflict handling

When authorities disagree:

1. [ ] Identify the conflicting claim IDs.
2. [ ] Compare authority levels.
3. [ ] Check whether one source is stale, generated, test-only, or scoped to a different mode.
4. [ ] Use the discovery aid or the smallest direct source read needed to resolve the conflict.
5. [ ] Ask for a narrower scout pass if the conflict still spans too much surface.
6. [ ] Resolve the conflict in the claim ledger before editing public prose.
7. [ ] If unresolved, mark the claim as an open question and block final packaging.

Disallowed moves

• [ ] Do not rely on memory, preference, or prior drafts as technical evidence.
• [ ] Do not promote orientation notes directly into public RFC text without source confirmation.
• [ ] Do not write the public document as a narration of the workflow's audit, calibration, or source-authority debate.
• [ ] Do not hide contradictions by weakening public wording without updating the claim record.
• [ ] Do not keep unsupported placeholders in final drafts.
• [ ] Do not let examples imply behavior that the accepted claim set does not support.