# 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.