Positioning Authorship Follows Evidence-ADR Sovereignty — A Subject Is Authored Where Its Anchoring ADRs Are Accepted; Peers Reference It by Role, Never Duplicate
Accepted
Context
ADR-035 established positioning as a queryable protocol surface and ADR-043 modelled it as four elements (WHAT / FOR WHOM / HOW bound by the Proof seam), governed by the five coherence rules of `ontoref positioning audit` — the first of which, AnchorDrift, requires that every `evidence_adr` cited by a Differentiator or Proof resolves to an Accepted ADR. Both ADRs were authored when the positioning surface had exactly one occupant: ontoref itself. In a single-project surface, "Accepted" silently meant "Accepted in this project", and the question of WHOSE ADR set AnchorDrift resolves against never had to be asked.
That assumption broke the moment a second subject appeared. The rustelo framework is positioned two ways at once: (1) inside ontoref's own positioning it is a REFERENCED ROLE — "the publishing vehicle" at the content-vehicle-convergence membrane (vp-009, audience-authoring-knowledge, ADR-064) — and (2) as a framework with its own market position against Cot / Axum / Leptos it is a SUBJECT with its own Differentiator, Competitor, Audience and ValueProp. The subject's differential value is anchored by rustelo's ADRs (adr-001 build-time codegen, adr-002 custom routing, adr-003 layered override, adr-006 rendering profile) — which are Accepted only in rustelo's ADR catalogue, not ontoref's.
Working the placement through surfaced the load-bearing fact: a rustelo Differentiator authored inside ontoref's `.ontoref/positioning/` would FAIL AnchorDrift, because ontoref does not own those ADRs. Authored inside rustelo's own `.ontoref/positioning/`, the same subject passes — verified: `ontoref positioning audit` run from rustelo reports `adr-drift: none`. The audit already resolves `evidence_adrs` against the AUTHORING project's ADR set; the framework simply never named where that places a subject. This is the same authority-upstream / reference-not-duplicate principle ADR-028 established for the ontology layer (a project consumes ontologies by reference and cannot mutate them) and that the `.rustelo.ontoref/` domain marker and the rustelo publishing-contract already manifest — now made explicit for the positioning surface.
Decision
Positioning authorship follows evidence-ADR sovereignty. State it as a protocol rule over the ADR-043 surface:
A positioning SUBJECT — a Differentiator, Competitor, ValueProp, or Proof whose admissibility depends on `evidence_adrs` — is authored in the `.ontoref/ positioning/` of the project whose ADR catalogue Accepts those ADRs. AnchorDrift resolves `evidence_adrs` against the AUTHORING project's ADR set; therefore the authoring project is fixed by ADR sovereignty, not by editorial convenience.
A peer project may REFERENCE that subject only by ROLE — a prose mention or an id in one of its own authored records (e.g. ontoref's vp-009 naming rustelo as "the publishing vehicle") — and MUST NOT re-author the peer's typed subject in its own tree. The reference carries the relationship; the subject stays sovereign.
This generalises the single-project AnchorDrift assumption of ADR-043 to a multi-project positioning surface without adding a kind or a schema field. It is additive and opt-in (ADR-029): a project with no `positioning/` directory, or one that references no peer, pays zero adoption cost, and every existing positioning file validates unchanged. The shared `make_*` helpers are imported by the authoring project (rustelo imports ontoref's `code/ontology/defaults/positioning.ncl` via its declared `nickel_import_paths`), so the schema is authored once in ontoref and consumed by every positioning surface — the same producer/consumer split as the rustelo publishing-contract.
Constraints
- Hard A positioning subject that cites `evidence_adrs` MUST be authored in the `.ontoref/positioning/` of the project whose ADR catalogue Accepts those ADRs. `ontoref positioning audit`, run from that project, MUST report no AnchorDrift for the subject. Placing such a subject in a project that does not Accept its evidence ADRs is a drift finding, not a stylistic choice.
- Soft A project MUST reference a peer's positioning subject only by ROLE — a prose mention or an id in its OWN authored record — and MUST NOT re-author the peer's typed subject in its own tree. Cross-references between subjects are by id (competitor_ids, differentiator_ids), never by copied record.
- Soft The sovereignty rule MUST stay additive and opt-in: a project with no `positioning/` directory, or one that references no peer subject, MUST validate unchanged and pay zero adoption cost. The rule adds no kind, folder, or required field to ADR-043's surface.
Alternatives considered
- Author rustelo's positioning subject inside ontoref's positioning layer (single-layer, all subjects in one place) — rejected: Chosen first for expedience, then rejected on a mechanical basis: the subject's evidence_adrs (rustelo's adr-001/002/003/006) are not Accepted in ontoref's catalogue, so AnchorDrift fails. Placing the subject where its ADRs are not sovereign is not a style choice the audit tolerates — it is a hard drift finding.
- Duplicate the subject in both projects (nivel-0 and nivel-1 copies kept in sync) — rejected: Unsound, not merely redundant. The ontoref copy would have to strip evidence_adrs (unanchored, rejected by _diff_requires_anchor) or cite rustelo ADRs it cannot Accept (AnchorDrift failure). Duplication also reintroduces the drift the AnchorDrift rule exists to prevent — two records that can diverge with no single sovereign truth.
- Add a cross-project evidence_adr resolver so a subject in project A can cite Accepted ADRs from project B — rejected: Would let a host author a peer's subject by reaching into the peer's ADR catalogue — dissolving sovereignty rather than respecting it, and coupling the audit to a cross-project fetch it does not need. The reference-by-role rule achieves the same visibility (the relationship is expressed) without importing the peer's evidence, and stays faithful to ADR-028's consume-by-reference-cannot-mutate model.
Anti-patterns
- Authoring a Peer's Positioning Subject in the Host's Tree — A contributor places project B's Differentiator/ValueProp inside project A's `.ontoref/positioning/` to 'own the story in one place'. Its evidence_adrs are Accepted in B, not A, so `ontoref positioning audit` from A reports AnchorDrift — the subject is homeless, not centralised.
- Duplicating a Subject Across Projects and Syncing by Hand — The same Differentiator is copied into both the sovereign project and a peer to keep each surface 'complete'. The copies drift, and the peer copy must either strip its anchor (unanchored, rejected) or cite un-Acceptable ADRs (AnchorDrift). Two records, no single sovereign truth — the exact drift AnchorDrift exists to prevent.
- Reaching Into a Peer's ADR Catalogue to Anchor a Local Subject — To author a peer's subject locally, a contributor adds a resolver so evidence_adrs can cite a peer project's Accepted ADRs. This dissolves ADR sovereignty — the host now anchors claims on decisions it did not make and cannot govern — the opposite of ADR-028's consume-by-reference-cannot-mutate model.