# The Orange Anchor Lexicon

**v2.7**

---

> **Core invariant.** Per-commitment production cost is positive and scales linearly with volume up to operational constants, under a stated, adversary-favourable threat model. The architectural contribution is cost preservation and attribution: production cost paid by a holder persists as attributable scarcity across every system that recognises the commitment. See *Orange Anchor White Paper v2.3* for the full argument.

---

## Core Terms at a Glance

| Term                    | Phase          | One-Sentence Definition |
|-------------------------|----------------|-------------------------|
| **Signed Claim**        | Base           | Any signed assertion or data package created by a user. Can exist independently of any proofing process. |
| **Orange Anchor**       | Proofed        | A signed claim that has gone through the burn (resource-bound proofing process), resulting in a cryptographic proof committed to the Bitcoin chain. |
| **Envelope**            | Proof          | The compact, cryptographically signed, Bitcoin-anchored artefact that proves resources were committed during the bracketed interval. Abstract; concrete serialisations are the *portable proof envelope* and the *verification package*. |
| **Witness Log**         | Evidence       | The chained record of witness evidence (sensors, memory, gossip, etc.) collected during the burn and folded into the envelope. |
| **Burn**                | Process        | The resource-bound proofing process bracketed by two Bitcoin anchors, during which the witness log is generated. Available at two duration tiers: lightweight (6-block) or heavyweight (144-block). |
| **Producer**            | Role           | The party who makes the commitment, performs the burn, produces the proof, and (typically) continues to hold and present it. |
| **Operator**            | Role           | A deployment-layer service implementing one or more of the four operator surfaces. Operators have no protocol privilege. |

*Use this table for quick reference. Full definitions appear in the sections below.*

---

## 1. Preamble

**Why this vocabulary exists:** The Orange Anchor construction is complex. It involves multiple phases, actors, cryptographic operations, and operator surfaces. Without a precise, shared vocabulary, different documents and teams will use different words for the same concepts, creating ambiguity, miscommunication, and drift. This lexicon eliminates that ambiguity by providing a single, bounded, canonical vocabulary anchored in the construction's actual structure.

This document is the Orange Anchor lexicon. It defines the vocabulary used across the document suite:

- the *Orange Anchor White Paper v2.3* (architecture — the complete system overview),
- *BACC v1.9* (the BACC pattern and Orange Anchor construction),
- the *Strategic Cost Calibration Model v1.3* (cost equations, calibration profiles, and the cost ratio κ),
- the *BAVAI Reference v1.0* (attribution index design and cryptographic structure),
- the *BAVAI Operator Specification v1.0* (protocol surface, wire formats, signatures),
- the *Orange Anchor Integration Brief v2.2* (platform value, integration paths, user experience),
- the *Orange Anchor Interaction Patterns v1.0* (check-in and cosign protocol specification),
- the *Orange Anchor Reference Implementation* (authoritative ground truth for construction internals),
- the *Orange Anchor Android Application SRS* (sovereign production tool requirements),
- the *Orange Pages Website SRS* (public verifier and commercial operator requirements),
- the *Orange Pages Audit Methodology v1.0* (one operator's audit scoring framework),
- supporting narrative companion pieces and the code itself.

Readers familiar with domain-driven design may recognise it as functionally equivalent to a **ubiquitous language** — a shared, bounded vocabulary that creates a consistent conceptual context for all work in the domain. Readers from a software-architecture background may recognise it as the conceptual layer from which logical and technical models derive. Readers from a humanities or general background can read it as a structured dictionary with rationale. The terms are the same in any reading; only the framing differs.

The vocabulary is anchored in the construction itself. *Production*, *establishment*, and *verification* are not naming choices but descriptions of structurally distinct phases of how an Orange Anchor proof comes into being and is used afterwards. Production itself decomposes into a chain of four functions — *commitment*, *witnessing*, *pricing*, *notarisation* — which name what the construction actually does at its conceptual core. The vocabulary derives from these functions.

**On framing.** Orange Anchor is a **cost-backed collateral primitive**. It can be used as an identity primitive, used alongside existing identity systems as a security layer, or used independent of identity entirely (for example, to attest that a piece of content was produced under demonstrable resource cost). The vocabulary does not privilege any single use case. Where the integration brief discusses Orange Anchor as security-layer collateral for existing platforms, and where the construction paper discusses it as a self-sovereign identity primitive, both framings are accurate and both rest on the same underlying construction.

This document is intended as the load-bearing reference for anyone reading, writing, or building on the Orange Anchor work. It is not a style guide and does not legislate tone, but it does specify a *demonstrative discipline* (§14) that governs how publishable material is structured. Different documents in the suite have different registers — declarative, narrative, philosophical, instructional, normative-technical. The vocabulary remains consistent; the voice changes.

**Register notes.** Some terms carry different connotations across communities (Bitcoin, SSI, humanities, technical). Where relevant, the lexicon includes brief notes on register-specific usage.

**Governance note:** This vocabulary is not static. New terms may be added and existing terms refined when the construction evolves. All changes must be justified by a clear improvement in precision, consistency, or defensibility. Soft or ambiguous language will be attacked and tightened.

Read it once at any depth that suits you. Return to it when a term in another document feels uncertain.

**Value for Different Audiences:**
- **Bitcoin builders:** This vocabulary makes the construction's security properties (pricing, witnessing, notarisation) explicit and auditable.
- **SSI practitioners and platform integrators:** It provides a precise language for cost-backed proof artefacts that complement existing identity infrastructure as a security layer rather than competing with it.
- **Business decision-makers:** It clarifies the economic asymmetry (sunk cost for honest users, high marginal cost for attackers) that makes the system scalable.
- **Technical implementers:** It defines the exact roles, phases, artefacts, and operator surfaces needed to build compatible systems.

---

## 2. The Three Phases

Every Orange Anchor proof passes through three structurally distinct phases. These are not arbitrary divisions; they correspond to three different kinds of operation, performed by three different kinds of actor, with three different temporal characters.

**Production** is the phase during which the proof is brought into existence. A producer, by initiating the burn, commits to producing a proof within a bracketed interval. The work is then performed on the device, witnessed by the device's physical sensors, and its physical cost prices the witnessing. Production has duration. It is private. It is performed once per proof.

**Establishment** is the moment at which the produced proof is fixed into the public record. The witnessed, priced result is committed to the Bitcoin chain through the second anchor transaction; the proof's existence and timing become observable to any third party. Establishment is the notarising act. It is instantaneous. It is public. It is performed once per proof.

**Verification** is the phase during which the established proof is examined by parties who wish to rely on it. Any verifier may verify any envelope at any time, without permission, without contact with the producer, and without contact with any issuer. Verification is on-demand. It is repeated arbitrarily often across the proof's useful life.

These three phases differ in temporal character and in actor. They demand different vocabularies and warrant separate treatment.

*Note on cost-phase framing.* The White Paper (§4) describes cost asymmetry between two phases — *commitment* (production together with establishment) and *verification*. This is a cost-asymmetry framing, not a competing structural one: production carries the resource expenditure; establishment is the near-instantaneous notarising transaction whose cost is dominated by the anchor fee; verification has near-zero cost. Where this lexicon distinguishes three structural phases, the White Paper's two cost phases group production and establishment together because their cost profile is dominated by the production component. The structural canon is three phases; the cost-asymmetry observation is two.

For readers familiar with command-query separation patterns in software architecture, the parallel is approximate but useful: production is structurally analogous to a long-running command, establishment to a commit, verification to a query. The analogy is imperfect — production has duration and is more than a single command, establishment involves a network rather than a local commit — but the underlying separation of operational kinds is the same. Each phase has its own intent, its own actor, and its own language.

---

## 3. The Conceptual Chain Within Production

Production decomposes into a chain of four functions. Each is performed by a distinct actor. Each links to the next. The chain is the conceptual core of what Orange Anchor does.

**Commitment.** The producer, by initiating the burn, commits to producing a proof within the bracketed interval. The commitment is made when the first anchor transaction is submitted. After commitment, the producer is bound to perform the work or produce no envelope at all; partial or aborted work yields nothing. The commitment is what the construction is fundamentally about. There is no Orange Anchor proof without a producer making a commitment.

**Witnessing.** The witness lattice — the device's coherent set of physical sensors — observes the commitment being honoured. The lattice samples temperature, motion, electromagnetic state, ambient conditions, and other physical signals throughout the work. Each sample is incorporated into the chained log. The lattice testifies; the log records the testimony. Witnessing is performed by physics, not by people. The credibility of the witnessing derives not from the witnesses' integrity (sensors have no integrity to compromise) but from the joint coherence of their output across modalities.

**Pricing.** The work imposes a real, non-recoverable cost on the witnessing. Memory must be held resident, time must elapse, energy must dissipate, on-chain anchor fees must be paid. The cost backs the witnessing — if witnessing were free, the testimony would be worthless, since anyone could fabricate it at no expense. The price is what makes the witnessing real. This is the central security property of the construction: fabricating priced witnessing costs at least as much as performing it honestly. *Cost-backed* is the term used across the suite to describe this property.

**Notarisation.** The chain fixes the priced witnessing into the public record. Bitcoin is the notary; the second anchor transaction is the notarising act. After notarisation, the witnessed and priced commitment exists permanently in a public, irreversible record observable by any third party. The notarisation is performed by the network, not by an authority. Truth, in this construction, is bound not by decree but by cost.

The chain reads in one direction: a producer *commits*, the lattice *witnesses* the commitment being honoured, the work *prices* the witnessing through real physical cost, and the chain *notarises* the priced witnessing as a permanent record. Each function depends on the previous. None can be removed without collapsing the construction.

This is what Orange Anchor is, conceptually, in one sentence:

> *Orange Anchor prices the witnessing of a commitment, notarised by Bitcoin.*

---

## 4. Production Vocabulary

Production is the phase in which the chain above is enacted on a specific device. The vocabulary describes what is being committed, what is being witnessed, what is being recorded, and what is being paid.

**Commitment.** The producer's act of initiating the burn, signalled by submitting the first anchor transaction. The commitment is the entry point into the construction. *Performative note:* Submitting the first anchor is a performative act — it changes the producer's position by binding them to the work that follows.

*Register note.* In cryptographic register and in the White Paper (§4, §5), *commitment* — or *collateral commitment* — also denotes the resulting artefact (the envelope as defined in §5), by the standard convention in which a *commitment* is the output of a commitment scheme. Both senses are sanctioned; context disambiguates. Inside this lexicon and in the operator specification, *envelope* is the canonical artefact term; in the White Paper and SCCM, *collateral commitment* (or simply *commitment*) is the canonical artefact term.

**Work.** The bracketed period of resource-bound computation performed by the device in honour of the commitment. The canonical term for the production phase. *Work* is performed, sustained, completed, witnessed. Not "task," not "process."

**Burn.** The resource-bound proofing process bracketed by two Bitcoin anchors. During the burn, the witness log is generated and folded into the envelope. *Burn* is the canonical term across the document suite, used in narrative, marketing, and most technical contexts. *Work* may be used where the technical emphasis is on the computation itself rather than the bracketed process. Burns are produced at one of two tiers — *lightweight* or *heavyweight* — defined below.

**Lightweight burn.** A 6-block (~1 hour) burn duration tier, suitable for early testing, demonstrations, and low-stakes use cases. Specified as a first-class capability in *Orange Anchor Android Application SRS* §6.2. Lightweight burns produce valid proofs but typically achieve lower audit scores than heavyweight burns under any audit operator's methodology.

**Heavyweight burn.** A 144-block (~24 hour) burn duration tier, providing maximum signal strength and the highest achievable audit scores. Specified as a first-class capability in *Orange Anchor Android Application SRS* §6.2. Heavyweight burns are the typical choice for proofs intended for directory listing or commercial use.

The producer chooses the tier based on their use case. Eligibility for downstream services such as audit-operator directory listing is determined by the audit operator's methodology (typically via a published BARU threshold), not by the burn tier directly. A heavyweight burn makes a high audit score *achievable*; a lightweight burn caps the achievable score lower.

**Producer.** The party who makes the commitment, performs the burn, produces the proof, and (typically) continues to hold and present it. *Producer* is the canonical role term across the operator specification, both SRS documents, and the integration brief. Not "user," not "creator," not "issuer" (the construction has none).

The term *holder* may appear in some texts as a synonym referring to the producer post-establishment — that is, the producer in their continuing role as the party in possession of the proof's signing key. At MVP, producer and holder are the same person; the lexicon does not treat *holder* as a separate canonical role. If multi-party key handling becomes a feature in Phase 2, the distinction may be reintroduced.

**Device.** The physical machine on which the work runs. In the first instantiation, a commodity Android smartphone. The device is the physical substrate of the work — the locus where computation, memory, sensors, and actuators come together.

**Witness lattice.** The set of physical sensors whose joint output testifies to the physical conditions under which the work was performed. The lattice *witnesses*, *attests*, *records*. Sensors do not "monitor" or "verify"; verification is downstream and performed by other parties. *Note on circularity:* Individual sensors are termed *witnesses* (see below); the lattice is the coherent collection of those witnesses.

**Witnesses.** Individual sensors, treated as participants in the lattice. A witness *testifies* to the physical state at sample time. The vocabulary deliberately echoes the language of evidence and testimony, because that is structurally what the sensors are doing.

**Spark.** The auxiliary computation executed at fine cadence and committed to the chained log, providing continuous proof of execution. The canonical name is *spark*. In narrative pieces this can be glossed as a heartbeat or a continuous signature, but the term itself is reserved.

**Spark debt.** The accumulated deficit produced when sparks miss their scheduled cadence windows. Debt accumulates in observable ways and is one of the construction's primary defences against memory substitution. *Necessary and sufficient condition:* Debt exists when the observed spark count at any checkpoint falls below the expected count derived from the verifiable delay function's cycle state and the elapsed bracketed interval.

**Chained log.** The cryptographically chained record of witness samples and spark commitments accumulated during the work. The log *records*. It does not "store" or "save" — both are too neutral and miss the cryptographic chaining that makes the log irreversible mid-stream.

**Witness Log.** The chained record of witness evidence (sensors, memory, gossip, etc.) collected during the burn and folded into the envelope. This is the primary term for the evidence chain.

**Verifiable Delay Function (VDF).** A cryptographic primitive that requires a prescribed amount of sequential computation to evaluate and produces an output that anyone can verify quickly. In the Orange Anchor construction (per *BACC v1.9* §3.2), the Wesolowski [2018] VDF over a group of unknown order (RSA-2048 in the reference instantiation; class-group alternative documented) binds the burn to real elapsed wall-clock time — a producer cannot accelerate the VDF evaluation by adding parallel hardware. The VDF's difficulty parameter `T` is calibrated to the bracketed window's wall-clock duration. The VDF's intermediate states are sampled at spark cadence and woven into the witness log; *spark debt* (defined above) is measured against the VDF's cycle state.

**Raiser.** *Deprecated.* The actor publishing an attribution event against a proof. The canonical term across v1.0 of the document suite is **flagger** (for flag events specifically) or **publisher** (for general attribution events). *Raiser* appears in earlier drafts of the BAVAI Reference and is retained here only to support cross-references to those drafts.

**Reseed / reseeding.** The incorporation of Bitcoin block confirmations into the running computation during the work. The work is *reseeded by* block confirmations; block confirmations are *reseeded into* the work.

**Block-triggered burst.** The higher-rate sampling of the witness lattice that occurs at each reseed event, accompanied by brief device actuation that creates a known-stimulus event observable across multiple sensors. *Burst* is the canonical term for the event itself.

**Pricing.** The economic and physical cost imposed by the work on the witnessing. Pricing is what makes fabrication of the witnessing prohibitive. Pricing is not a separate operation; it is an emergent property of the work being resource-bound, anchor-paid, and time-bound.

**Cost-backed.** The general property that an artefact carries the trace of demonstrable resource expenditure. Cost-backed proofs are the central primitive of Orange Anchor; *cost-backed* is preferred over softer phrasings such as "expensive to produce" or "resource-intensive" because it captures the structural property: the cost is *embedded in the proof itself* rather than incurred elsewhere.

**Sunk cost.** The non-recoverable component of pricing. The producer cannot reclaim the energy, the elapsed time, or the on-chain fees paid during the burn. The sunk-cost property is what allows a single device's commodity hardware to honest-produce proofs that would cost an adversary at scale far more per object. The asymmetry between honest sunk cost and adversarial marginal cost is the core economic property of the construction (see *Edge-Favouring Calibration*, §8).

**Precomputation prevention.** A mandatory mechanism (chain-randomness or live-entropy) that prevents the off-chain work from being produced before the first anchor confirms. Every instantiation must apply at least one precomputation-prevention mechanism.

**Commitment surface.** Bitcoin treated as the substrate on which commitments are recorded and later verified without trusting anyone to maintain or interpret them. The five substrate properties — global, neutral, permissionless, permanent, ordered — are what the construction uses; BTC the token is the access mechanism (write-fee allocation), separate from the substrate properties. The architecture uses Bitcoin only for what it already provides: no protocol changes, no new token, no novel script. *See also:* §5 (*Anchor, Notarisation*).

**Cost ratio (κ).** The ratio of adversary marginal cost per commitment to honest marginal cost per commitment, evaluated against an explicitly declared adversary class, honest class, calibration profile, hardware-cost snapshot, and fee-market snapshot. Defined in *SCCM* §1.1. *Note:* κ is an inspection metric, not a security parameter. The architectural defence is the positivity of the per-commitment cost floor (White Paper §4, §8); κ characterises the *magnitude* of asymmetry under stated conditions.

**Calibration profile.** A named, versioned bundle of lever values producing a documented qualitative characterisation of κ against a declared adversary class. Profiles defined in *SCCM* §5: **Light**, **Standard**, **Hardened**, **Maximum**. Profile selection is a deployment-tuning decision; the architectural cost-positivity claim holds across all profiles. Quantitative κ values against the reference adversary class are provided in the *Calibration Annex* (forthcoming).

**Reference Concurrent Adversary (RCA-2026).** The reference adversary class for the SCCM's current snapshot calibration: substantial capital, current best-bin general-purpose hardware plus available acceleration, virtualisation tooling, engineering depth sufficient to attempt sensor-coherence simulation. Defined in *SCCM* §1.2. All adversary classes in the SCCM are bounded below RCA-2026 in capability; more capable classes (state-level actor, cartelised operator, hardware-vendor insider) are deferred to the *Adversarial Scenario Analysis* (forthcoming).

**Association.** A signed binding produced by a producer that links a proof's anchor reference to an external identifier such as an email address, social handle, DID, URL, or public key. Always user-initiated and signed on-device per *Android SRS* §6.5.

**Dissociation.** A signed revocation of a previously created association. Producible at any time by the producer; itself a signed artefact.

**Binding.** General term for the signed link between a proof and an external identifier. Used interchangeably with *association* in most contexts; *association* emphasises the relationship, *binding* emphasises the cryptographic act of producing the signed link.

**Free association.** The principle that producers initiate and control every association involving their proofs. No background, automatic, or platform-initiated bindings exist at MVP. This is a load-bearing sovereignty property of the Android application; see *Android SRS* §6.5 (FR-A-501 through FR-A-508).

---

## 5. Establishment Vocabulary

Establishment is the moment at which the produced proof is fixed into the public record. The vocabulary describes what is being committed to the chain, what is being notarised, and what is being made publicly observable.

**Anchor / anchors / anchor transactions.** The two on-chain Bitcoin transactions that bracket the burn. The first anchor *commits* the start (and signals the producer's commitment); the second anchor *commits* the result. The pair *brackets* the interval. Anchors are not "checkpoints" or "markers" or "timestamps" — they are anchors, with the connotation of fixity.

**Bracketed interval.** The period between the two anchors. The work occurs *within* the bracketed interval. The interval has a *duration* observable in block confirmations (6 blocks for lightweight, 144 blocks for heavyweight).

**Envelope.** The compact, cryptographically signed, Bitcoin-anchored artefact produced at the conclusion of the burn and finalised at establishment. The envelope is the witnessed, priced, notarised record of the producer's commitment having been honoured.

*Envelope* is an abstract term denoting the artefact itself. Its concrete on-the-wire serialisations are the **portable proof envelope** (operator specification §7.3) and the **verification package** (operator specification §7.4), which are progressively richer encodings of the same underlying artefact. The portable proof envelope carries the data required for inclusion verification against the Bitcoin chain; the verification package additionally carries construction-internal data needed for full construction verification. Both serialisations are produced by the Android application per *Android SRS* §6.4.

The envelope is *produced*, *committed*, *published*, *transferred*, *verified*. It is not "issued" (no issuer), "minted" (avoid this register), or "generated" (too neutral).

*Cross-document note.* In the White Paper (§4–§5) and the SCCM, this artefact is referred to as the **collateral commitment** (or **commitment** in cryptographic-commitment register). The artefact is the same; the term differs by document. The operator specification, both SRSs, and this lexicon use **envelope**; the White Paper and SCCM use **collateral commitment**.

**Portable proof envelope.** The minimal canonical serialisation of an envelope, sufficient for inclusion verification against the Bitcoin chain. Defined in operator specification §7.3.

**Verification package.** The full canonical serialisation of an envelope, including construction-internal data needed for full construction verification. Defined in operator specification §7.4. The verification package contains everything in the portable proof envelope plus the construction internals required for audit-grade verification.

**Anchor reference.** The canonical identifier for a proof, derived deterministically from its anchor transaction data per operator specification §4. The anchor reference is independent of which operator (if any) was involved in producing the proof; it is a property of the proof itself, not of any operator's records.

**Notarisation.** The function performed by the Bitcoin chain in fixing the envelope's existence and timing into the public record. Bitcoin *notarises*. The chain is *the notary*. The term is load-bearing — the post-authoritative thesis depends on the chain performing notary functions without being a sovereign authority. *Physical grounding:* The notary function is made post-authoritative by the irreversible work (hashrate, energy expenditure) that secures the Bitcoin chain.

**Publication.** The act of writing an envelope's reference (or an operator's signed record about it) into a publicly readable index. Publication is the act; *reference* is the ongoing function the published index provides afterwards.

**Establishment.** The phase itself, as the verb. An envelope *is established* when the second anchor confirms and the chain has notarised it. After establishment, the envelope exists in the public record; before establishment, the work is in progress.

The verbs of establishment: *anchor, commit, notarise, publish, establish, fix, seal*. The nouns of establishment: *anchor, envelope, anchor reference, chain, notary, publisher, directory*. The adjective of establishment is *established*; the temporal sense is *at the moment of*.

---

## 5b. Operator Vocabulary

Operators are deployment-layer services that provide convenience or commercial value around envelopes, but have **no protocol privilege**. The protocol is the chain plus the construction; operators do not extend protocol authority. Verifiers may consume operator outputs, ignore them, or compose multiple operators' outputs under their own policy.

**Operator.** A service implementing one or more of the four operator surfaces defined in operator specification §2.1. Operators are deployment-layer roles; the protocol grants them no privilege. Every operator publishes a BIP340 keypair per operator specification §5 and signs every record they publish. The four canonical operator surfaces are *batching*, *indexing*, *audit*, and *flag publication*; an operator may implement one, several, or all four.

**Batching operator.** Operator surface that aggregates multiple producers' burns into shared anchor transactions, reducing per-proof on-chain cost. Defined in operator specification §6.1.

**Indexing operator.** Operator surface that publishes lookup indexes over known anchor references and signed records. Defined in operator specification §6.2.

**BAVAI.** Bitcoin-Anchored Verifiable Attribution Index. The cryptographic structure in which attribution events about commitments are recorded — sorted, Merkle-treed, root-anchored to Bitcoin — and the specification document defining it. Operators publishing attribution events do so within BAVAI; verifiers verify entries locally against the Bitcoin-anchored root. Defined at architectural level in the White Paper §6; full structure, key encoding, and operator coordination specified in the *BAVAI Reference v1.0*. *Scope:* construction-agnostic; applicable to any BACC construction. *See also:* §5b (*Indexing operator, Audit operator*).

**Audit operator.** Operator surface that scores proofs against a published methodology and issues signed audit records. Defined in operator specification §6.3. The Orange Pages website is an audit operator under the *Orange Pages Audit Methodology* document.

**Flag publisher.** Operator surface that publishes adverse signals against proofs (for example, evidence of compromise or methodology failure). Defined in operator specification §6.4. Flags are signed claims by the operator, not protocol-level revocations.

**Operator portable index.** The canonical signed publication format an operator uses to publish its outputs (audit feed, directory, flag feed). Defined in operator specification §6.1.4. The portable index format allows verifiers to consume an operator's outputs offline and to verify the operator's signature against the operator's published key.

**Methodology URI.** The published URI at which an operator hosts its scoring or evaluation methodology. Defined in operator specification §6.3.2; versioned per §6.3.3. An audit operator's methodology document is the authoritative ground truth for that operator's scoring algorithm, threshold values, refund policy, and audit pipeline behaviour.

**Signed record.** The unified record format used by operators for audit records, flag records, sign-in assertions, and co-signing assertions. Defined in operator specification §7.5. Every signed record is canonical JSON per RFC 8785, signed against an operator's published BIP340 keypair, and tagged with `record_type` to identify its purpose.

### 5b.1 Canonical JSON Field Names (Protocol Messages)

All JSON field names in Orange Anchor protocol messages — challenge objects, signed responses, attestation objects, signed records, portable proof envelopes, verification packages, audit records, flag records, sign-in assertions, and cosign records — use **snake_case**. Canonical JSON serialisation per RFC 8785 applies; field names are part of the signed byte sequence, so a receiver expecting a different casing fails signature verification. The following registry is normative for v1.0:

| Field name | Type | Context | Defining document |
|---|---|---|---|
| `action` | string | Challenge — "checkin" or "cosign" | Interaction Patterns §2.3, Widget §2.1 |
| `nonce` | hex string (32B) | Challenge — replay prevention | Interaction Patterns §2.3 |
| `verifier_id` | string | Challenge — verifier identifier | Interaction Patterns §2.3, Widget §2.1 |
| `timestamp` | RFC 3339 datetime | Challenge / record — issuance time | Interaction Patterns §2.3 |
| `expires` | RFC 3339 datetime | Challenge — expiry | Interaction Patterns §2.3 |
| `policy` | object | Challenge — verifier policy hints | Widget §2.1 |
| `require_attribution_check` | bool | Policy — query attribution index | Widget §2.1 |
| `minimum_baru_score` | number | Policy — minimum acceptable BARU | Widget §2.1 |
| `target_pubkey` | string | Cosign challenge — external identity to link | Widget §2.1 |
| `purpose` | string | Cosign challenge — free-text purpose | Widget §2.1 |
| `external_key_type` | string | Cosign — algorithm identifier | Interaction Patterns §3.2 |
| `commitment_pubkey` | hex string | Response / attestation — 33-byte compressed pubkey | Widget §2.2 |
| `signature` | hex string | Response — BIP340 signature over canonical challenge | Widget §2.2 |
| `external_signature` | hex string | Cosign response — external-key signature | Widget §2.2 |
| `external_pubkey` | string | Cosign response — external identity pubkey | Widget §2.2 |
| `commitment_signature` | hex string | Attestation — canonical BIP340 signature | Widget §2.3 |
| `challenge` | object | Attestation — verbatim copy of challenge | Widget §2.3 |
| `verified_at` | RFC 3339 datetime | Attestation — verification time | Widget §2.3 |
| `bitcoin_anchors` | object | Attestation — anchor reference data | Widget §2.3 |
| `start_block`, `end_block` | integer | Anchors — block heights | Widget §2.3 |
| `start_txid`, `end_txid` | hex string | Anchors — transaction IDs | Widget §2.3 |
| `anchor_reference` | hex string (32B) | Canonical envelope identity — `SHA256(start_txid ‖ end_txid)` | BAVAI Operator Spec §2, BAVAI Reference |
| `attribution` | object | Attestation — flag / endorsement summary | Widget §2.3 |
| `flags` | integer | Attribution summary — active flag count | Widget §2.3 |
| `last_checked` | RFC 3339 datetime | Attribution — cache freshness | Widget §2.3 |
| `operator` | string | Attribution — source operator identifier | Widget §2.3 |
| `cosign_linkage` | object | Cosign attestation — binding details | Widget §2.3 |
| `linkage_proof` | string | Cosign — cosign-record hash or merkle proof | Widget §2.3 |
| `record_type` | string | Signed record — type tag | BAVAI Operator Spec §7.5 |
| `flag_indicator` | hex byte | BAVAI key — attribution-event type byte | BAVAI Reference |
| `flagger_pubkey` | hex string | BAVAI flag value — publisher pubkey | BAVAI Reference |
| `flagger_signature` | hex string | BAVAI flag value — publisher signature | BAVAI Reference |
| `flagger_short_id` | hex string (6B) | Multi-flagger key extension | BAVAI Operator Spec §6.4.9 |

Extensions to this registry MUST be added by versioned revisions of this lexicon and the defining document. Field names not listed here are not part of v1.0's normative wire format; protocol implementers SHOULD treat unknown fields per the forward-compatibility rules in the defining document.

**BARU.** Bitcoin-Anchored Resource Unit. The numeric audit score expressed by audit operators. The scoring methodology is defined in the relevant operator's published methodology document; BARU is not a fixed unit across operators, and different audit operators may use the term with their own scoring rubrics. The Orange Pages BARU score is defined by the *Orange Pages Audit Methodology* document.

**Listing threshold.** The minimum BARU score required for inclusion in a given audit operator's directory listing. Operator-specific; published in the operator's methodology document. The Orange Pages listing threshold is published at the methodology URI per *Orange Pages Website SRS* §3.2.3.

**Listed entity.** A producer whose proof has been published in an audit operator's directory after passing audit and any required co-signing handshake. The listing is itself a signed record per operator specification §7.5; listings are revocable by the operator only via a signed revocation record published alongside the original entry.

**Cosigning assertion.** A signed record produced by an operator asserting a transitive trust relationship with a third-party platform's keypair. Defined as a protocol in *Orange Pages Website SRS* §6.8 series. Cosigning transfers no protocol authority; it expresses an operator's bounded trust assertion that verifiers may compose under their own policy. Both parties to a cosigning relationship sign their respective assertions; revocation by either party ends the relationship.

**Check-in.** Interaction pattern in which a producer presents a commitment as a credential to a system that recognises Orange Anchor proofs. The system issues a challenge — typically a random value combined with the system's identifier and a timestamp — and the producer signs it with the key associated with the commitment. The system verifies the signature against the commitment's public key and verifies the commitment itself against Bitcoin. No identity provider participates. Defined in White Paper §7; full specification in the *Orange Anchor Interaction Patterns v1.0*.

**Cosign.** Interaction pattern in which a producer links a commitment to an existing account, credential, or identity by signing a canonical linking message twice — once with the commitment key, once with the external identity key — and publishing the pair as an attribution event. The mechanism by which commitments compose with existing identity systems (DIDs, verifiable credentials, social-network keys). Defined in White Paper §7; full specification in the *Orange Anchor Interaction Patterns v1.0*; the operator-side *cosigning assertion* is defined separately above.

**Endpoint protection.** The mechanisms operators apply to public endpoints to absorb load and resist abuse, including hashcash-style proof-of-work challenges and rate limiting. Defined in operator specification §9.5. Concrete endpoint protection parameters live in operational deployment configuration, not in the operator specification itself.

**Orange Pages.** The audit-operator and commercial directory surface operated by us, specified in the *Orange Pages Website SRS*. Orange Pages is one specific audit operator and one specific listing publisher; the protocol does not privilege it. *Lexicographic note:* Treated as a proper noun when referring to our specific service; lowercase "orange pages" may refer informally to the general category of similar audit-operator directories.

The verbs of operator behaviour: *publish, sign, audit, attest, list, score, batch, index, flag, cosign, revoke*. The nouns of operator behaviour: *operator, audit record, directory entry, flag, cosigning assertion, methodology, methodology URI, signed record, portable index*. **Avoid sovereign vocabulary** (certify, authorise, grant, license, approve) — operators are not sovereign roles.

---

## 6. Verification Vocabulary

Verification is the phase during which the established proof is examined by parties who wish to rely on it. It is the highest-volume phase of the proof's lifetime: an envelope is produced once, established once, and verified arbitrarily often across years of use.

The vocabulary here distinguishes operations of different depth and intent.

**Verifier.** Any party who examines an envelope. The role is universal; there is no privileged verifier. A verifier *verifies*, *checks*, *audits*, *examines*, or *investigates*, depending on depth.

**Verification.** The general term for examining an envelope. Verification is performed *against* the Bitcoin chain (for anchor confirmation) and *against* the envelope's internal consistency (for the work's coherence). Verification *succeeds* or *fails*. It does not "approve" or "accept" — those are policy decisions made *after* verification by the application receiving the verified result.

**Inclusion verification.** Verification that the envelope's anchors are confirmed on the Bitcoin chain at the claimed heights with the claimed structure. Defined in operator specification §7.3.4. The portable proof envelope serialisation is sufficient for inclusion verification.

**Construction verification.** Verification that the envelope's internal data (witness log, spark log, sensor coherence) satisfies the construction's coherence requirements. Defined in operator specification §7.4.4. The verification package serialisation is required for construction verification.

**Check.** The lightweight version of verification. A check confirms the envelope's basic validity: the anchors exist at claimed heights, the verifiable delay function output is correct, the chained log is internally consistent, the spark debt is within threshold. A check completes quickly and is the appropriate operation for high-volume contexts where each envelope is presented once and the verifier needs a fast yes-or-no.

**Audit.** The deeper version of verification. An audit examines timing patterns, sensor coherence under load, propagation latency of reseeded blocks, edge cases in the spark log. An audit takes longer than a check and is the appropriate operation when the stakes are higher or when something in the envelope looks unusual. The vocabulary of *audit* deliberately echoes the financial and forensic register. Audit operators (§5b) perform audit at scale and produce signed audit records expressing scores.

**Investigation.** The adversarial version of verification. The verifier acts as forensic examiner, probing the envelope for evidence of attack — looking for traces of memory substitution, sensor fabrication, gossip-stream manipulation, or other adversarial paths. An *investigator* is the role; *investigation* is the act.

**Gating class.** The classification of how resource commitment is enforced in an instantiation: cryptographic, statistical, or mixed. Every instantiation must declare its gating class.

**Detection framework.** For statistically-gated instantiations, the mandated specification of observations that would falsify the security claim, the scale at which they would be gathered, and the confidence level. Statistically-gated instantiations must publish a detection framework.

**Policy.** The layer above check, audit, and investigation. A policy is the rule a verifying application uses to decide what depth of verification a particular use case requires, and what acceptance behaviour follows from the result. Policies are local to applications, not part of the construction. *Note:* "Policy" here refers to application-level decision rules, not construction-level rules.

**Acceptance.** The application's downstream decision to act on a verified envelope. An application *accepts* (or rejects) based on its policy, after verification has succeeded. Acceptance is not a property of the envelope; it is a property of the relationship between the envelope and the application.

The verbs of verification: *verify, check, audit, examine, investigate, probe, confirm, accept, reject*. The nouns of verification: *verifier, verification, check, audit, investigation, investigator, gating class, detection framework, policy, acceptance*. The temporal sense is *on demand*; the actor is *any party*.

The asymmetry across the three phases is part of the construction's design. Production takes hours, establishment takes minutes, verification takes milliseconds. One producer commits, witnesses, and pays; one network notarises; many verifiers verify, repeatedly, across the proof's lifetime.

---

## 7. The Five-Role Framework

The vocabulary above derives from a structural observation about the construction. Orange Anchor does, in digital form, what humans have been doing in non-digital form for as long as we have produced reliable claims about the past: gather testimony from witnesses, accumulate evidence into a record, fix the record through a notarising act, and make the result available for examination by any interested party.

This is not a metaphor. It is the structural description.

The five-role framework — *witnesses, collectors, depository, notary, investigator* — applies to medieval courts, modern forensics, modern science, Bitcoin, and Orange Anchor. The names of the roles change between domains; the functions are stable. Orange Anchor's witness lattice is the witness role. The chained log is the collector role. The envelope and the operator portable indexes are the depository role. The Bitcoin anchors are the notary role. The verifier in adversarial mode is the investigator role.

The vocabulary in sections 4 through 6 is therefore not borrowed from the legal or forensic register for atmospheric effect. The legal and forensic register is the register of *producing reliable claims about the past through testimony and evidence*. Orange Anchor does this. The vocabulary fits because the operation is the same.

The principal consequence of this framing is that Orange Anchor does not require a sovereign authority to make its claims binding. In medieval courts, the court was both *recorder* and *binder* — the record was made and the seal was applied by the same authority. In Orange Anchor, recording (the chained log) and binding (the Bitcoin anchors) are separated. Each is performed by a distinct mechanism. The notarising function is performed not by an authority but by physics — by the irreversible work behind the Bitcoin chain. Truth, in this construction, is bound not by decree but by cost.

This is the disambiguation that makes Orange Anchor post-authoritative.

The architectural separation at the heart of Orange Anchor is between the *act of witnessing* (which can run anywhere, on any device with the right physical substrate) and the *notarising of that act* (which happens on a single shared chain). Anyone can witness. Only one chain notarises. The portability of witnessing means Orange Anchor is not tied to any particular device class, jurisdiction, or platform; new witness substrates (PCs, dedicated hardware, future hardware) can be added without changing the notarisation layer. The shared notary means that all witnessing across the world, regardless of substrate, lives on one common timeline of irrefutable record.

---

## 8. Edge-Favouring Calibration

**Definition 1 (Edge-Favouring Calibration).** An instantiation is said to be *edge-favouring-calibrated* against an adversary class if there exists a non-empty class of honest participants such that all three of the following hold simultaneously at the instantiation's published parameters:

(i) **Sunk-cost feasibility.** The resource commitment is achievable by honest participants using hardware whose capital cost has already been paid for unrelated reasons.

(ii) **Non-amortisable adversarial engineering.** Adversaries producing indistinguishable objects must incur per-device-model engineering cost that does not amortise across hardware generations.

(iii) **Per-object marginal inequality at scale.** There exists a declared separation constant κ ≥ 10 such that the per-object marginal cost ratio satisfies c_A / c_H ≥ κ as the number of produced objects N → ∞.

An instantiation claiming Definition 1 must publish its κ, its adversary class, its revenue bound, and the cost accounting under which κ is computed.

---

## 9. Performativity and Reference

Several terms in the lexicon are not merely descriptive; they are performative. Submitting the first anchor does not describe a commitment — it *enacts* one. The producer's economic position changes at the moment the transaction confirms. Similarly, "notarisation" is not a label for a passive record; it is the act that *makes* the envelope's existence and timing irrefutable. The chain's irreversible work (hashrate, energy) is what gives that act its binding force.

The lexicon marks performative terms explicitly in their entries. Writers using the lexicon should be alert to the distinction between descriptive and performative language, especially when translating concepts into narrative or policy contexts.

Operator publication is also performative in a bounded way. When an audit operator publishes a signed audit record, the record's existence becomes a public fact verifiable against the operator's key — the operator has, by publication, made an attestation that they cannot quietly retract. They may publish a contradicting record later (a revocation, a correction); they cannot make the original disappear. The signature plus publication is the operator's commitment.

---

## 10. Reserved Terms

A small set of terms in the broader Orange Anchor work carry significant conceptual weight. They are useful in places where they do real work and harmful in places where they are merely decorative. The following terms are reserved.

**Thermodynamic.** Reserved. Used in narrative or humanities pieces where the broader frame is invoked. Not used in the white paper, technical specifications, or operator/SRS documents, where the canonical term is *physical* or *cost-backed*.

**Post-authoritative.** Reserved. Names the property of records being fixed without sovereign authority. Bitcoin is post-authoritative; Orange Anchor extends post-authoritative truth from monetary to attestation objects.

**Species-distinction.** Reserved. The framing that Orange Anchor's deepest function in the post-AGI economy may be distinguishing humans from artificial systems at scale. *Note:* This term is intentionally provocative rather than technically precise. It is intended to provoke thought in narrative and philosophical work rather than serve as a formal technical primitive.

**Aura.** Reserved. The Walter Benjamin reference; the property of a digital object carrying the irreproducible trace of its own creation event.

**Markov blanket.** Reserved. The Friston-derived structural framing of identity boundaries.

**Lattice.** Retired from load-bearing use. The term was used in earlier drafts as the working name for the construction. It may appear informally in future writing to refer to a distributed network of operators or composable indexes — for example, *"a lattice of operators"* — but is not a load-bearing term in any current document, and the construction itself is now named Orange Anchor.

The discipline around reserved terms is calibration, not gatekeeping. A reserved term used where it does real work carries weight that pulls the reader's attention; the same term used decoratively trivialises both the term and the writing.

**Cost-backed and sunk cost** were previously narrative-only and have moved into the main vocabulary (§4). They appear throughout the *Orange Anchor White Paper v2.3*, *BACC v1.9*, the *Orange Anchor Integration Brief v2.2*, and the *BAVAI Operator Specification v1.0*, and are no longer reserved.

---

## 11. What the Lexicon Is Not

The lexicon is not a marketing document. It does not advocate for Orange Anchor; it describes vocabulary.

It is not a style guide. It does not legislate tone, sentence length, or rhetorical posture.

It is not a constitution. The lexicon is amendable. New terms can be added when they begin doing real work in the body of work. Existing terms can be revised when the construction evolves.

It is not a technical specification. The white paper, the construction paper, the operator specification, and the SRS pair carry the technical detail. The lexicon names the entities and operations; the technical documents specify how they behave.

It is not a glossary. A glossary lists terms with definitions; this document organises the vocabulary around the construction's structural axes and explains why the chosen terms are chosen.

It is not foreign to the reader. Most of the vocabulary will already be familiar from existing fields — testimony from law, evidence from forensics, notarisation from legal practice, envelope from logistics, anchor from networking, audit from finance, commitment from contract law and ordinary speech. The lexicon's contribution is consistency of usage, not invention of terminology.

---

## 12. Worked Examples: How Vocabulary Propagates

The following examples show how core terms appear at different layers of the body of work.

**Term: *Signed Claim***

*Lexicon definition.* Any signed assertion or data package created by a user. Can exist independently of any proofing process.

*White paper expression.* "The participant creates a file containing their personal details and signs it with their derived key. This signed file is the starting point before any proofing occurs."

*Code construct.* A `SignedClaim` data structure containing typed fields for user assertions and a signature.

*Narrative expression.* "Before anything else, the user fills in their details and signs the file. This signed claim is theirs alone — no proof yet, just their word."

**Term: *Envelope* (abstract)**

*Lexicon definition.* The compact, cryptographically signed, Bitcoin-anchored artefact produced at the conclusion of the burn. Abstract; its concrete serialisations are the portable proof envelope and the verification package.

*White paper expression.* "The proof envelope is the compact, verifiable record produced at the conclusion of the work…"

*Operator specification expression.* "The portable proof envelope (§7.3) carries the data sufficient for inclusion verification; the verification package (§7.4) carries the additional construction-internal data sufficient for full construction verification."

*Code construct.* An `Envelope` data structure with two serialisation methods: `serializePortable()` producing the portable proof envelope, and `serializeFull()` producing the verification package.

*Narrative expression.* "What comes out at the end is a small cryptographic record — an envelope. It is the digital equivalent of a temper line. Depending on what the recipient needs to verify, the producer can hand over the lightweight version or the full one."

**Term: *Witness Log***

*Lexicon definition.* The chained record of witness evidence (sensors, memory, gossip, etc.) collected during the burn.

*White paper expression.* "The construction samples this physical state through the device's available sensors at frequent intervals throughout the work, and incorporates each sample into a chained log bound to the verifiable delay function's intermediate states."

*Code construct.* A `WitnessLog` interface exposing `sample()` operations on each constituent witness, with the joint sample written to the chained log.

*Narrative expression.* "The phone watches itself work. It samples its own temperature, listens through its own microphone, feels its own micro-vibrations, and records it all in a chained log."

**Term: *Burn***

*Lexicon definition.* The resource-bound proofing process bracketed by two Bitcoin anchors, available at lightweight (6-block) or heavyweight (144-block) tiers.

*White paper expression.* "The participant initiates the burn — a bracketed interval during which their device performs resource-bound work witnessed by its sensors."

*Android SRS expression.* "FR-A-201. The application MUST support both lightweight (6-block) and heavyweight (144-block) burn tiers as first-class user-selectable options."

*Code construct.* A `Burn` object managing the interval, witness sampling, and log chaining; constructed with a `BurnTier` enum value (`Lightweight` or `Heavyweight`).

*Narrative expression.* "They start the burn. Depending on the choice — quick lightweight burn or full heavyweight one — their phone works for the next hour or the next day, watched by its own sensors, proving that real resources were spent."

---

## 13. Sanctioned Narrative Metaphors

The lexicon is the load-bearing vocabulary across the body of work. Narrative companion pieces may import additional metaphors to bring readers into the conceptual frame. The metaphor is local to the piece; the lexicon remains global.

A narrative piece adopting a metaphor must, somewhere within the piece, bridge back to the lexicon. The metaphor is an entry point; the lexicon is what the reader carries forward.

**Example of successful bridging (from *The Digital Forge*):**

> "The phone watches itself work. It samples its own temperature, listens through its own microphone, feels its own micro-vibrations. This is the witness lattice — the same lattice that will later be notarised by Bitcoin and verified by anyone who cares to look. Once that bridge is made, the metaphor can be set aside; the precise term 'witness lattice' carries the meaning forward."

The bridging sentence explicitly names the lexicon term ("witness lattice") and connects the metaphor (phone watching itself) back to the construction's vocabulary. The final sentence demonstrates how the metaphor is *abandoned* after the bridge — it is a temporary scaffold, not a permanent replacement.

The following metaphors are sanctioned for narrative use.

**Metallurgy / forge / temper / strike.** Strong on production. Use for pieces emphasising the physical labour of creation. Bridge: "the forge prices the witnessing; the chain notarises it."

**Baking / proofing.** A baker *proofs* dough during a bracketed period of slow physical change, and the result is an artefact whose existence is the trace of the process. Strong on the production phase. Cosier register; suited to reflective audiences.

**Biology / arrival / coming-into-being.** Strong on irreversibility and on the moment of arrival. Carries some baggage in the gendered register; use carefully.

**Construction / building.** Available but flat. Acceptable for pieces aimed at practical audiences.

**Court / forensics / laboratory.** Not narrative-only; also part of the load-bearing frame. Pieces leaning on the courtroom or forensic register are using the lexicon directly in dramatised form, not importing a separate metaphor.

The following are unsanctioned without explicit justification: *minting* (NFT contamination), *generation* (too neutral), *issuance* (imports an issuer), *burning* outside narrative (cryptocurrency-burn semantics — note: *burn* in the Orange Anchor sense is well-established within the suite and is fine; the warning is about the cryptocurrency-token-burn register).

New metaphors may be proposed and added to the sanctioned list when they meet three criteria: structurally accurate, bridgeable to the lexicon, free of contradicting baggage.

---

## 14. Demonstrative Discipline

The lexicon governs *what* is said. This section governs *how*. Together they constitute the editorial infrastructure of the body of work.

The discipline has a name: **demonstrative**. Claims are demonstrated, not asserted. The reader is shown rather than told. Strong claims are made; they are made in a form that brings their supporting structure with them. Lecturing is forbidden.

The discipline has five observable properties of strong prose. These are not commandments imposed on the reader; they are diagnostic tests a writer can apply to their own sentences.

**Property 1: The sentence carries its supporting structure.** A demonstrative sentence either contains its justification or earns it in the prior sentence. *"The cost of producing one identity has a physical lower bound consisting of the device's capacity to sustain the memory-hard work over the interval, the on-chain cost of the two anchor transactions, and the energy consumed by the device during the work"* demonstrates. *"Orange Anchor is the most secure identity system ever built"* asserts. The first survives scrutiny because the structure is visible. The second invites pushback because the claim arrives without ground.

**Property 2: The sentence does not lecture.** Lecturing is the register of unearned authority — telling the reader what they should think, what is important, or what they will come to understand. The reader resents lecturing because it pre-empts their reasoning. *"You will see that this changes everything about identity"* lectures. *"The construction requires no issuer; verification depends only on Bitcoin's block history and the envelope itself"* does not. The first tells the reader what to think. The second describes what is and lets the reader think it.

**Property 3: Claims are linked rather than stacked.** A linked sequence is one in which each claim sets up the conditions under which the next becomes available. The reader walks the structure, anticipating the next step. A stacked sequence is a list of independent assertions, none of which prepares the reader for the next. The Satoshi white paper is almost entirely linked; weaker work tends toward the stacked form.

**Property 4: The reader can partly anticipate what comes next.** When prose is well-grounded and well-positioned, a careful reader feels the argument's momentum and partly anticipates the next sentence before reading it. This is the signature of fluent claim-making — the reader feels they are co-constructing the argument rather than receiving it. If the next sentence is unanticipatable, either the argument has surprised the reader (which sometimes is the right move and sometimes is a defect) or the claim chain has broken. The reader's predictive sense is the writer's most reliable diagnostic.

**Property 5: Hedging has not substituted for grounding.** *"We believe that Orange Anchor may potentially provide a useful primitive for…"* is hedging without grounding — the reader gets neither the claim nor the structure that would back it. *"Orange Anchor produces a witness-attested proof of physical creation cost, verifiable offline against Bitcoin's chain"* is a strong claim, made because the structure is there to back it. Hedging does not make claims more defensible; it just makes them duller. Grounding is the alternative — make the claim, and bring its structure with it.

The discipline applies in full to load-bearing public material: the white paper, the construction paper, the integration brief, the operator specification, the SRS pair, and the audience-targeted narratives where strong claims are made.

The discipline applies in lighter form to narrative and educational material: pieces like *The Digital Forge* and future story-shaped explainers may use metaphor, may be playful, may be more personal. The underlying claims still derive from the lexicon and still demonstrate rather than assert. The narrative piece can use a sword-forging metaphor but cannot lecture; it can be evocative but cannot make ungrounded claims about what the construction means.

The discipline does not apply to private writing, to internal documents, or to exploratory conversations where speculation and hunches are the point. Those documents serve different purposes and have different epistemic shapes.

The simplest version of the discipline, for a writer in the middle of a draft: *if you cannot rewrite the sentence so the reader could anticipate it from what came before, the sentence is either wrong, premature, or lecturing. Find which.*

---

## 15. Editorial Rules

These rules apply across the body of work and govern the disciplined use of the lexicon.

**One vocabulary, one meaning.** A term means the same thing in the white paper, in a light paper, in a narrative piece, and in code. Local deviations require local definition.

**Phase-appropriate verbs.** Production verbs (*commit, perform, witness, sample, record, accumulate, burn*) are not establishment verbs (*anchor, commit-to-chain, notarise, publish*) are not verification verbs (*verify, check, audit, examine, investigate*) are not operator verbs (*publish, sign, audit, attest, list, score, batch, index, flag, cosign, revoke*). Mixing the registers misrepresents what is happening.

**Avoid sovereign vocabulary.** No *certify*, *authorise*, *grant*, *license*, *approve* in the load-bearing register. The construction is post-authoritative; the language must reflect this. **This applies to operator behaviour as well as to the construction itself.** Operators publish, sign, attest, score; they do not certify or authorise.

**Narrative metaphors bridge back.** Pieces adopting a metaphor must connect that metaphor to the lexicon at least once, as demonstrated in §13.

**Reserved terms stay reserved.** Heavy artillery is loaded for specific use.

**When in doubt, revert to function.** If a metaphor strains or a term is ambiguous, write the functional description. The white paper is the model.

**Demonstrative discipline applies to load-bearing material.** §14 governs how claims are made in any document where strong claims appear.

---

## 16. Cross-Document Mapping

*Scope of this table.* This table maps lexicon terms to their occurrences across documents in the Orange Anchor ecosystem. The columns for **Android SRS v1.3** and **Orange Pages SRS v1.1** reference internal implementation specifications that are **not part of the published Orange Anchor document suite** at v1.0. Those SRS documents constrain the reference implementations of the Android producer application and the Orange Pages directory respectively; they are listed here to maintain internal vocabulary consistency for the implementation teams. Readers of the published suite need only the documents in the first column and the WP / SCCM / Operator Spec / BAVAI Reference / Interaction Patterns / Integration Brief / Widget Specification / Top Level Introduction / Audit Methodology columns of related tables; rows referencing the SRS documents are provided for internal navigation and consistency only.

This section provides a quick reference showing how lexicon terms map to terms in the major suite documents. Use it when reading across documents to confirm that a term in one document refers to the same concept in another.

| Lexicon term | BAVAI Operator Spec | Android SRS v1.3 | Orange Pages SRS v1.1 | WP v2.2 | SCCM v1.3 |
|---|---|---|---|---|---|
| Producer | §2.1 producer | §2.1 producer | §2.2 producer | §1, §4, §7, §8 | §1.2 |
| Burn | §4 (referenced) | §3.2.1 burn | (referenced) | §5 (as “work”) | §2.2 |
| Lightweight burn | (not specified) | §3.2.2 burn tier (lightweight) | (referenced via FR-W-303) | (—) | (—) |
| Heavyweight burn | (not specified) | §3.2.2 burn tier (heavyweight) | (referenced via FR-W-303) | (—) | (—) |
| Envelope (abstract) | §7.3, §7.4 | §6.4 (export FRs) | §6.1, §6.3 (consume FRs) | §4, §5 (as “collateral commitment”) | (—) |
| Portable proof envelope | §7.3 | FR-A-401 | FR-W-101 | (—) | (—) |
| Verification package | §7.4 | FR-A-402 | FR-W-303 | (—) | (—) |
| Anchor reference | §4 | FR-A-305 | FR-W-103 | §4, §5 | §2.6 |
| Signed record | §7.5 | (consume) | FR-W-306, FR-W-405, FR-W-804 | (—) | (—) |
| Operator | §2.1, §6 | FR-A-801 to FR-A-805 | §2.5 (we are an operator) | §6, §7 | (—) |
| Batching operator | §6.1 | FR-A-801 | (not directly relevant) | §6 | §4 |
| Indexing operator | §6.2 | FR-A-802 | FR-W-501 (we publish the index we maintain) | §6 | (—) |
| Audit operator | §6.3 | (referenced via FR-A-806) | UC-W3 (we are one) | §7 | (—) |
| Flag publisher | §6.4 | (referenced) | (referenced) | §7 | (—) |
| Methodology URI | §6.3.2 | (referenced) | FR-W-701 | (—) | (—) |
| BARU | (not specified; operator-defined) | (referenced) | §3.2.2 | (—) | (—) |
| Listing threshold | (not specified; operator-defined) | (not encoded; eligibility lives at audit operator) | §3.2.3 | (—) | (—) |
| Listed entity | (not specified) | (referenced) | §2.4 | (—) | (—) |
| Association | (not specified) | UC-A4, FR-A-501 to FR-A-508 | FR-W-404 (consume) | §7 | (—) |
| Dissociation | (not specified) | FR-A-504 | FR-W-408 (operator-side analogue: delisting) | (—) | (—) |
| Free association | (not specified) | UC-A4, §6.5 (load-bearing) | (consumed) | (—) | (—) |
| Cosigning assertion | (not specified) | (signs counterpart) | §6.8 (FR-W-800 series) | §7 | (—) |
| Endpoint protection | §9.5 | (referenced) | FR-W-105, §9.3 | (—) | (—) |
| Operator portable index | §6.1.4 | (consumed via lookup) | FR-W-405, FR-W-806 | §6 | (—) |
| Reseed / reseeding | (—) | (—) | (—) | §5 (described) | §2.2 |
| BAVAI | §5–§8 (primary) | (—) | FR-W-501 | §6 | (—) |
| Check-in | (—) | (—) | (—) | §7 | (—) |
| Cosign | (—) | (—) | (—) | §7 | (—) |
| Commitment surface | (—) | (—) | (—) | §3 | (—) |
| Cost ratio (κ) | (—) | (—) | (—) | §8 | §1.1 (primary) |
| Calibration profile | (—) | (—) | (—) | §8 | §5 (primary) |
| RCA-2026 | (—) | (—) | (—) | §8 | §1.2 (primary) |
| Collateral commitment (artefact) | (—) | (—) | (—) | §4, §5 | (—) |

When a row shows “(not specified)” against a document, that document does not define the term — typically because the term is the responsibility of a different layer of the suite. For example, *BARU* is operator-defined and lives in each audit operator’s methodology document, not in the operator specification itself. Rows showing “(—)” indicate the term is not yet mapped to that document; this table will be extended as the suite matures.

---

## 17. Status

This is v2.7 of the Orange Anchor Lexicon. Changes from v2.6:

- §1 document suite list updated: *Orange Anchor White Paper v2.3*, *BACC v1.9*, *SCCM v1.3*, *BAVAI Reference v1.0*, *BAVAI Operator Specification v1.0*, *Orange Anchor Interaction Patterns v1.0* named; *Audit Methodology* versioned.
- §2 cost-phase framing note added, reconciling the White Paper’s two cost-phase framing with the lexicon’s three structural phases.
- §4 *Commitment* entry: *Register note* added acknowledging *collateral commitment* as the White Paper / SCCM artefact usage.
- §4 *Commitment surface*, *Cost ratio (κ)*, *Calibration profile*, *Reference Concurrent Adversary (RCA-2026)* entries added.
- §5 *Envelope* entry: *Cross-document note* added citing *collateral commitment* as the White Paper / SCCM artefact term.
- §5b *BAVAI* entry added, cross-referencing the now-published *BAVAI Reference v1.0*.
- §5b *Check-in* and *Cosign* interaction pattern entries added.
- *Cosigning* replaces *co-signing* throughout (alignment with White Paper usage).
- §16 cross-document mapping: two new columns (WP v2.2, SCCM v1.3) added; column renamed to BAVAI Operator Spec; eight new term rows added (Reseed, BAVAI, Check-in, Cosign, Commitment surface, Cost ratio, Calibration profile, RCA-2026, Collateral commitment); WP and SCCM references populated for existing rows where known.
- §17 version and changelog updated.
- Alphabetical index updated for all new and renamed terms.

---

Changes from v2.5:

- Document renamed from *The Lattice Lexicon* to *The Orange Anchor Lexicon*; "Lattice" retired from load-bearing use and noted as informal-only in §10.
- Construction-name references throughout updated from *Lattice* to *Orange Anchor*.
- *Producer* established as the canonical role term; *Holder* removed as a separate canonical role and noted in §4 as an occasional synonym for the producer post-establishment.
- *Envelope* reframed as abstract; *portable proof envelope* and *verification package* added as concrete serialisations (§5).
- *Lightweight burn* and *heavyweight burn* added (§4) reflecting the burn tiering established in *Android SRS v1.3*.
- *Association*, *dissociation*, *binding*, and *free association* added (§4) reflecting the sovereignty vocabulary in *Android SRS v1.3*.
- *Cost-backed* and *sunk cost* moved from reserved/narrative to main vocabulary (§4).
- New section **§5b. Operator Vocabulary** added with ~14 entries covering operator surfaces, audit, BARU, signed records, listing, co-signing, endpoint protection, and Orange Pages.
- *Inclusion verification* and *construction verification* added (§6) to reflect the operator specification's verification structure.
- New section **§16. Cross-Document Mapping** added providing a reference table across the lexicon, operator specification, and SRS pair.
- Preamble updated to reference the actual current document suite and to soften identity-only framing in favour of *cost-backed collateral primitive* framing that accommodates identity, security-layer, and standalone use cases.
- Editorial rules (§15) updated to add operator verbs to the phase-appropriate verbs rule and to clarify that sovereign-vocabulary avoidance applies to operator behaviour as well as protocol behaviour.
- Worked examples (§12) updated to reflect the abstract-vs-concrete envelope distinction and burn tier choice.
- Reserved terms (§10) refreshed: *Lattice* added as retired; *cost-backed* and *sunk cost* removed (now main vocabulary).
- Index updated for new terms, removed terms, and shifted section references.

The lexicon is amendable. New terms emerge when they begin doing real work; existing terms refine when the construction evolves. Amendments are versioned, dated, and noted. The lexicon is a working artefact — stable enough to anchor the body of work, open enough to grow with it.

Use it accordingly.

---

## Alphabetical Index

**A**
Acceptance (§6), Anchor (§5), Anchor reference (§5), Association (§4), Audit (§6), Audit operator (§5b)

**B**
BARU (§5b), Batching operator (§5b), BAVAI (§5b), Binding (§4), Block-triggered burst (§4), Bracketed interval (§5), Burn (§4)

**C**
Calibration profile (§4), Chained log (§4), Check (§6), Check-in (§5b), Commitment (§3, §4), Commitment surface (§4), Construction verification (§6), Core Terms at a Glance (front matter), Cosign (§5b), Cosigning assertion (§5b), Cost-backed (§4), Cost ratio κ (§4)

**D**
Demonstrative discipline (§14), Detection framework (§6), Device (§4), Dissociation (§4)

**E**
Edge-Favouring Calibration (§8), Editorial Rules (§15), Endpoint protection (§5b), Envelope (§5), Establishment (§2, §5)

**F**
Five-role framework (§7), Flag publisher (§5b), Free association (§4)

**G**
Gating class (§6)

**H**
Heavyweight burn (§4), Holder (§4 — noted as occasional synonym for producer post-establishment, not separately canonical at MVP)

**I**
Inclusion verification (§6), Indexing operator (§5b), Investigation (§6), Investigator (§6)

**L**
Lexicon (preamble), Lightweight burn (§4), Listed entity (§5b), Listing threshold (§5b), Lattice (§10 — retired)

**M**
Markov blanket (§10), Methodology URI (§5b)

**N**
Notarisation (§3, §5), Notary (§7)

**O**
Operator (§5b), Operator portable index (§5b), Orange Anchor (front matter, §3), Orange Pages (§5b)

**P**
Performativity (§9), Phases (§2), Policy (§6), Portable proof envelope (§5), Post-authoritative (§10), Precomputation prevention (§4), Pricing (§3, §4), Producer (§4), Production (§2, §4), Public record (§6), Publication (§5)

**R**
Reference Concurrent Adversary / RCA-2026 (§4), Reseed / reseeding (§4), Reserved terms (§10), Resource-bound (§4)

**S**
Sanctioned metaphors (§13), Signed Claim (§4), Signed record (§5b), Spark (§4), Spark debt (§4), Species-distinction (§10), Sunk cost (§4)

**T**
Thermodynamic (§10 — reserved), Three Phases (§2)

**V**
Verification (§2, §6), Verification package (§5), Verifier (§6)

**W**
Witness (§4), Witness lattice (§4), Witness Log (§4), Work (§4)

---

*Discipline first. The pattern improves through structured pressure.*