Rendered from docs/taxonomies/evidence-and-obligation/doctrine.md in the Headwater
corpus. Every document on this half of the site is typed by the taxonomy
the descriptor names: corpus.json.
The evidence-and-obligation taxonomy
One kind, evaluation, and the two reader intents that this repository and the design-spec entry called evidence and obligation. This entry exists because HW-DR-0044 found that decision-record required all of design-spec for these two addresses and nothing else it declared, and it is a bundle of its own rather than a rewrite of design-spec. The library index lists it as a bundle that admission does not carry. It models no tradition and it ships no worked corpus of its own.
What the finding was, and what this entry is not
Design-spec's own doctrine already recorded the shape of the problem, three times over, in its "Composition between two library entries has no add-only form" finding: a shared purpose, an endpoint list of concrete kinds, and a facet requirement list, each stopped by the same rule — the first bundle to declare an address owns it, and nothing may add a second entry beside it. HW-DR-0095 (Q67) later let an entry write into an entry that it names in requires, and that write still costs the whole dependency. decision-record paid the first of the three in full: it declared requires: [design-spec] for the obligation purpose alone, and inherited six kinds and three shelves along with it.
This entry is not the four-way split that HW-DR-0044's Context section named as candidates to test — specification-series, decision-refinement, evidence-and-review and obligation-tracking, each its own bundle. Tracing what decision-record actually reaches showed that only evaluation, purposes.evidence, purposes.obligation and the narrative voice regime could leave design-spec without creating a cycle. obligation_register, review_prompt and review_record stayed in design-spec, because each needs doc_type or sequence, both of which discriminate shelves that stayed there too. A finer split is left for a later proposal, if adopter evidence beyond this repository's own corpus asks for one; design-spec's doctrine carries the argument for why this cut and not a wider one.
The one kind
| Kind | Purpose | Shelf | Voice |
|---|---|---|---|
evaluation |
evidence |
docs/evaluations/** |
narrative |
The declaration adds one facet requirement to the one design-spec carried, and is otherwise unchanged: is_a: governed_document, homogeneous shelf, no doc_type (placement already states the kind, so a discriminator would restate it).
The addition is title, which headwater/standard declares in the name role from 4.0.0. An evaluation is the kind here that a reader reaches from a list rather than from the document that cites it, because a shelf index and a site navigation each render the whole shelf. Until 4.0.0 the facet stood in the decision-record entry, which this entry does not require and cannot require without the cycle the section below describes, so all nineteen evaluations of the publishing corpus rendered as HW-EVAL-adjacent-work (#427). The move to the base is what let this entry state the requirement without taking a dependency for a facet. What did not travel is the evidence-cited participation expectation design-spec's evaluation used to carry, which named decision_register as its to_kind. Declaring it here would have required this entry to require design-spec back, cycling against the edge design-spec now carries onto this entry. Design-spec's own finding 4 already recorded that the expectation was too narrow — an evaluation cited only by an obligation_register reported as absent under the same declaration — and the decision-record fixture measured that narrowness as unfixable for an adopter with no register. This entry does not close finding 4. It retires the one declaration finding 4 had already found wanting, and an abstract kind over the register kinds remains the general remedy, still open.
The two purposes, and why obligation_register did not follow purposes.obligation
A purpose is a reader intent, referenced by name from any kind whose bundle requires the bundle that declares it. It travels independently of any one kind that serves it. purposes.obligation moved here because decision-record's obligation_record needed it and nothing else design-spec declared; obligation_register, the kind that most visibly serves the same intent in design-spec, stayed there because it also requires doc_type and sequence. Both design-spec's obligation_register and decision-record's obligation_record now reach this entry's purposes.obligation through their own requires, and neither collides with the other: purpose: obligation is a reference, and criterion 6 forbids a second declaration of an address, not a second kind that names one.
purposes.evidence moved for the plainer reason: evaluation is the only kind that serves it, and evaluation moved.
The regime, and the edge it put on design-spec rather than on this entry
regimes.voice.narrative binds evaluation here, and it also binds design-spec's review_record, which stayed. A regime is declared once; the second binder requires the first. This entry declares regimes.voice.narrative and needs nothing back for it, so design-spec's requires: [evidence-and-obligation] carries this reference the same way it carries evaluation and purposes.obligation — three references over one edge, not three edges.
Why the edge could not run in reverse
Three declarations that stayed in design-spec name a kind or an address that this entry now owns: relations.cites_evidence's to: [evaluation], kinds.obligation_register's purpose: obligation, and kinds.review_record's voice: narrative. Each of those references needs requires, the same as any reference across a bundle boundary, and design-spec supplies it once for all three. Had this entry instead kept cites_evidence (whose from list still names design_spec and decision_register, both left in design-spec) or the evidence-cited expectation (to_kind: decision_register), this entry would have needed requires: [design-spec] at the same time design-spec requires this entry — two bundles on both ends of one edge, which the resolver has no reading for and which the confluence proof this library relies on does not admit. So the address stayed on whichever side already held the kinds it names, and this entry carries only what needed no such kind.
The core, declared
Criterion 5 of the library index asks each entry to state its relationship to the invariant core. This entry adds no core-bearing facet and removes none; evaluation inherits state, state_entered, freshness and scent from governed_document, the same as every kind in this library. It serves no core purpose (rationale, behavior) and claims none.
Findings
1. A capability split is not free even when it fixes the boundary it targets. Three declarations — one participation expectation and, in principle, one kind and one facet requirement list — did not survive the move intact, for the reason design-spec's doctrine states in full: a reference that named a kind on the wrong side of the new boundary cannot be declared without a cycle. Every one of the three was already a known narrowness (finding 4 of design-spec) or an unclaimed opportunity (the facet requirement list), never a clean severance. A capability split trades one entry's over-reach for a short, named list of casualties, and this entry's doctrine is where that list is kept rather than in the decision that authorized the trade.
2. This entry has no fixtures of its own yet. Decision-record's fixture already exercises evaluation through discharges, and design-spec's fixture exercises it through cites_evidence, both by assembling this entry alongside the one that needs it. A fixture that selects this entry alone, with nothing exercising evaluation beyond its own shelf, has not been written. This is a gap rather than a defect: nothing in the taxonomy needs it to resolve, and no adopter has asked for evaluation without one of the two entries that already reach it.