# Orange Pages Audit Methodology

**Version:** 1.0  
**Date:** May 2026  
**Status:** Released — Starter Rubric (Calibration-Pending Weights)

---

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

---

## 0. Document Control

**0.1 — This is v1.0 of the Orange Pages Audit Methodology.** It is the published methodology of the Orange Pages audit operator, hosted at the operator's methodology URI per *BAVAI Operator Specification v1.0* §6.3.2.

**0.2 — Form.** This document is **protocol-form with starter rubric**. It specifies the methodology structure, the publication and versioning protocol, the rubric structure, the listing threshold mechanism, and the audit pipeline behaviour. Concrete numeric weight values within the rubric are explicitly marked `CALIBRATION-PENDING` and will be filled in for v1.1 once real audit pipeline data and adversarial test data are available. The rubric structure itself is stable from v1.0.

**0.3 — Authoritative ground truth.** This document is the authoritative ground truth for BARU scoring, listing threshold, audit pipeline behaviour, and refund policy at the Orange Pages operator. Where any other document references "the methodology," they reference this document at a specific version.

**0.4 — Versioning.** Methodology versions follow `vMAJOR.MINOR` semantics. Major versions indicate rubric structure changes; minor versions indicate weight calibration or threshold adjustment. Audit records are signed against a specific methodology version per §10.

**0.5 — This is the methodology of one specific operator.** Other audit operators publish their own methodologies. The terms BARU and listing threshold are operator-defined per *Orange Anchor Lexicon v2.7* §5b; this document defines them for the Orange Pages operator.

---

## 1. Purpose and Scope

**1.1 —** This document is the published methodology of the Orange Pages audit operator. It satisfies the operator obligation under *BAVAI Operator Specification v1.0* §6.3.1 to publish a complete, versioned methodology at a stable URI.

**1.2 —** The Orange Pages audit operator is one of the operator surfaces specified in *Orange Pages Website SRS v1.1*. This document specifies *how* that operator scores proofs, *what* the score means, *which* proofs qualify for directory listing, and *how* the audit pipeline behaves.

**1.3 — In scope:**
- The structure of the BARU score and what it expresses
- The scoring rubric (dimensions, measurement, weighting structure)
- The listing threshold and listing protocol
- The audit pipeline (submission, processing, output)
- The refund policy
- The methodology versioning protocol
- The operator's signing obligations
- The dispute and resubmission protocol

**1.4 — Out of scope:**
- Concrete operational deployment configuration (turnaround budgets, fee values, refund processing windows, infrastructure parameters)
- Other operators' methodologies (each operator publishes its own)
- The cost-lever framework underlying scoring (specified in *Strategic Cost Calibration Model v1.3*)
- The construction itself (specified in the construction paper and reference implementation)
- Verifier-side policy on how to consume audit records

**1.5 — Companion documents.**

| Document | Relationship |
|---|---|
| *BAVAI Operator Specification v1.0* | Defines the operator obligations this document fulfils |
| *Orange Pages Website SRS v1.1* | The website that operates this methodology; defers to this document for ground truth |
| *Strategic Cost Calibration Model v1.3* | The structural framework of cost levers this rubric is organised around |
| *Orange Anchor Lexicon v2.7* | Defines BARU, audit operator, listing threshold, signed record |
| *BACC v1.9* | Defines the construction whose proofs we audit |

---

## 2. The Audit Operator's Role

**2.1 — We are an operator, not a sovereign authority.** Per *Orange Anchor Lexicon v2.7* §5b, audit operators have no protocol privilege. The protocol is the chain plus the construction; we provide a deployment-layer service that produces signed records expressing scores.

**2.2 — Audit produces a signed record.** Every audit run produces a signed record per *BAVAI Operator Specification v1.0* §7.5, expressing the BARU score and bound to the methodology version that produced it. We sign every record we publish.

**2.3 — Verifiers compose audit records under their own policy.** Our signature attests that *our methodology* produced *this score* against *this verification package* at *this time*. It does not transfer protocol authority. Verifiers may consume our records, ignore them, or compose them with other operators' outputs under their own policy.

**2.4 — We cannot quietly retract.** Audit records published under our key are public facts. We may publish a contradicting record (a revision, a revocation), but the original record remains in the public log per *BAVAI Operator Specification v1.0* §6.1.4.

**2.5 — The methodology is the ground truth, not the result.** A score is what the methodology says it is, deterministically computed against the verification package. We do not adjust scores by hand. We do not negotiate scores. The rubric is reproducible by any party that has the methodology and the verification package.

---

## 3. The BARU Score

**3.1 — BARU as defined for the Orange Pages operator.** BARU (Bitcoin-Anchored Resource Unit) is a numeric audit score expressed by audit operators per *BAVAI Operator Specification v1.0* §6.3 and *Orange Anchor Lexicon v2.7* §5b. The Orange Pages BARU is defined by this document; other operators may use the term with their own rubrics.

**3.2 — Score range.** The Orange Pages BARU is expressed on the integer range **0 to 100**. A score of 0 indicates the proof produced no scoreable evidence; a score of 100 indicates the proof produced the maximum scoreable evidence under the current rubric. Scores between 0 and 100 reflect partial achievement across the rubric's scored dimensions per §4.

**3.3 — Score interpretation.** The Orange Pages BARU is interpreted in four bands aligned conceptually with the calibration profiles in *Strategic Cost Calibration Model v1.3* §5:

| BARU range | Band | Conceptual alignment |
|---|---|---|
| 0–25 | Minimal | Below practical assurance threshold |
| 26–50 | Standard | SCCM Standard Profile equivalent |
| 51–75 | Hardened | SCCM Hardened Profile equivalent |
| 76–100 | Maximum | SCCM Maximum Profile equivalent |

Bands are interpretive guidance; the underlying score is the precise numeric value.

**3.4 — Score is not a property of the proof itself.** It is *our methodology's evaluation* of the proof's verification package. The same proof scored under a different methodology version, or under a different operator's methodology, may receive a different score. Verifiers consuming a BARU score MUST reference the methodology version (per §10) to interpret the score correctly.

**3.5 — Scores are deterministic and reproducible.** Given the verification package and the methodology version, any party can recompute the BARU score and verify it matches our published audit record. This is a stronger property than authority; the score is checkable.

---

## 4. The Scoring Rubric (Starter Form)

This is the load-bearing section of the methodology. The rubric is structured around the cost-lever axes defined in *Strategic Cost Calibration Model v1.3* §3, providing a principled basis for scoring rather than arbitrary point allocations.

### 4.1 Rubric Structure

Each scored dimension has:

- **Source axis** — which cost-lever axis the dimension reflects (resource / time / witness / cryptographic / network / on-chain)
- **What is measured** — the specific property scored
- **How it is measured** — the operation performed against the verification package
- **Weight contribution** — the maximum points the dimension contributes to BARU (CALIBRATION-PENDING in v1.0)
- **Required or optional** — whether the dimension is required for any BARU score or contributes additively if present

### 4.2 Required Dimensions

These dimensions MUST be present and pass to receive any BARU score. A proof failing any required dimension receives BARU = 0.

| Dimension | Source axis | What is measured | Weight (CALIBRATION-PENDING) |
|---|---|---|---|
| **D-R-1 Burn duration** | time | Bracketed-interval block count matches declared burn tier (lightweight 6-block or heavyweight 144-block) | TBD |
| **D-R-2 Memory commitment honoured** | resource | Memory-hard checkpoint chain coherent across full burn; no evidence of substitution | TBD |
| **D-R-3 Spark cadence** | cryptographic | Spark debt within tolerance threshold across burn | TBD |
| **D-R-4 Anchor verification** | on-chain | Both anchors confirmed at claimed heights; anchor reference derives correctly per operator spec §4 | TBD |
| **D-R-5 Construction verification** | cryptographic | VDF output chain valid; chained log internally consistent; signature valid | TBD |

### 4.3 Scored Dimensions (Quality Signal)

These dimensions contribute additively to BARU based on the depth and quality of evidence in the verification package. A proof that meets all required dimensions but engages no scored dimensions receives a baseline BARU but not a high score.

| Dimension | Source axis | What is measured | Weight (CALIBRATION-PENDING) |
|---|---|---|---|
| **D-S-1 Sensor modality count** | witness | Distinct sensor modalities present in witness log (3 to 12 depending on platform) | TBD |
| **D-S-2 Sensor coherence** | witness | Cross-modality joint coherence under sustained load; physical plausibility checks | TBD |
| **D-S-3 Sensor sampling rate** | witness | Effective sampling rates across modalities; particularly in critical windows | TBD |
| **D-S-4 Block-triggered burst presence** | witness | Bursts at reseed events with cross-sensor response signature | TBD |
| **D-S-5 Final-window witness density** | witness | Sampling rate and coherence in final hour of burn (highest weight per dimension at MVP) | TBD |
| **D-S-6 Anchor schedule density** | time | Total anchor count and distribution shape (uniform / front-loaded / tapered with dense final window) | TBD |

### 4.4 Opt-In Dimensions (Producer-Volunteered)

These dimensions are entirely opt-in. The producer chooses whether to engage them. Engaging them contributes additively to BARU and reflects the producer's volunteered commitment to public verifiability per *Strategic Cost Calibration Model v1.3* §3.5 and §6.3.

| Dimension | Source axis | What is measured | Weight (CALIBRATION-PENDING) |
|---|---|---|---|
| **D-O-1 Gossip-network witnessing** | network | High-fee Bitcoin PSBTs broadcast and confirmed during burn, referenced in verification package | TBD |
| **D-O-2 Real-time Nostr publication** | network | Signed real-time messages published to Nostr relays during burn, with relay timestamps | TBD |
| **D-O-3 Independent watcher confirmations** | network | Confirmations from independent watcher subscriptions of burn cadence | TBD |

### 4.5 Calibration-Pending Discipline

Each weight in §4.2, §4.3, and §4.4 carries an explicit `CALIBRATION-PENDING` (TBD) marker in v1.0. v1.1 will fill these in once we have:

- Real audit pipeline running on real proofs at scale
- A small adversarial test set to calibrate against
- Implementer feedback on which dimensions matter most for which use cases
- Sufficient operational experience to defend the weights with evidence rather than estimates

The rubric *structure* — what we measure and how we measure it — is stable from v1.0. Only the *weights* mature in v1.1. Scores assigned under v1.0 should be understood as preliminary; v1.1 may rescore proofs against the calibrated weights, but the v1.0 records remain published and remain reproducible against the v1.0 methodology.

This is honest uncertainty, not vagueness. The framework is principled; the calibration is acknowledged as not yet measured.

### 4.6 Compositional Formula

Total BARU is the weighted sum of dimension scores, normalised to the 0–100 range:

```
For each scored dimension D:
    D_raw_score = methodology evaluation of dimension D against verification package
                  (typically 0.0 to 1.0 representing fraction of dimension's max evidence)
    D_contribution = D_raw_score × D_weight

For required dimensions (§4.2):
    If any required dimension fails (D_raw_score = 0):
        BARU = 0
        Audit record indicates which required dimension failed
        Stop.

BARU = round(sum of all D_contribution values, normalised to [0, 100])
```

The total weight allocation across all scored and opt-in dimensions is fixed at a value that produces 100 under maximum achievement. The exact weight distribution among dimensions is the calibration-pending element.

This formula is stated explicitly so verifiers can recompute BARU from a verification package and the published rubric, without trusting our pipeline to have computed it correctly. Reproducibility is the methodology's accountability mechanism.

### 4.7 Methodology-Required vs Methodology-Optional Discipline

The split between required (§4.2), scored (§4.3), and opt-in (§4.4) dimensions is deliberate:

- **Required** dimensions ensure structural validity. Without them, no audit score is meaningful.
- **Scored** dimensions reflect the quality of evidence the proof naturally contains. Producers using more sensors, longer burns, denser anchoring receive higher scores because their proofs are intrinsically harder to fake.
- **Opt-in** dimensions reflect the producer's voluntary commitment to additional public verifiability. Honest producers volunteer cost; adversaries pay it as a tax to match the score.

This split is the cleanest expression of the construction's economic logic: cost is not a tax on honest producers; it is a *signal of quality*. Producers choose how much they want to signal.

---

## 5. Listing Threshold

**5.1 — Listing threshold defined.** The minimum BARU score required for inclusion in the Orange Pages directory listing per *Orange Pages Website SRS v1.1* §3.2.3.

**5.2 — Starter threshold.** `CALIBRATION-PENDING`. The proposed initial listing threshold is at the boundary between Standard and Hardened bands per §3.3 (i.e., approximately BARU 50). The exact threshold is finalised in v1.1 once the rubric weights are calibrated.

**5.3 — Threshold revision protocol.** The threshold is published at the methodology URI as part of this document. Threshold changes are versioned per §8. When the threshold changes:

- Producers whose proofs were listed under an older threshold do **not** lose listing status retroactively. The original audit record stands at its original score under its original methodology version.
- New listing applications are evaluated against the current threshold.
- Producers may resubmit older proofs for re-audit under newer methodology if they wish to be evaluated against the updated criteria.

**5.4 — Single-tier listing at MVP.** v1.0 specifies single-tier listing: a proof either qualifies for inclusion in the Orange Pages directory or it does not. Multi-tier listing (e.g., separate Standard and Premium directory tiers) is deferred to v1.1+ pending operational evidence on whether tiering improves the directory's utility.

**5.5 — Listing as a signed record.** Inclusion in the directory is itself a signed record per *BAVAI Operator Specification v1.0* §7.5. Directory entries are revocable only via signed revocation records published alongside the original entry.

---

## 6. The Audit Pipeline

**6.1 — Submission.** Producers submit verification packages via the Orange Pages website per *Orange Pages Website SRS v1.1* UC-W3. Submission requires the full verification package (per *BAVAI Operator Specification v1.0* §7.4), not the portable proof envelope alone. Construction verification per §4.2 D-R-5 requires the full package.

**6.2 — Payment.** Audit fee is paid prior to processing. Concrete fee values, accepted payment methods, and fee tier structure are specified in operational deployment configuration and are outside the normative scope of this methodology.

**6.3 — Processing.** The audit pipeline runs the rubric (§4) against the submitted verification package. The pipeline is **deterministic** given a methodology version: the same package audited against the same version produces the same score. This is a load-bearing property of the methodology — without determinism, scores cannot be reproduced or disputed by reference to evidence.

**6.4 — Turnaround commitment.** The Orange Pages operator publishes a target turnaround commitment for audit completion in operational deployment configuration. The methodology requires that the operator publish *some* committed turnaround budget; the specific value is operational. The proposed initial commitment is on the order of 24 hours from payment confirmation, with a ceiling for queue-spike conditions.

**6.5 — Output.** Each completed audit produces a signed audit record per *BAVAI Operator Specification v1.0* §7.5, published to the operator's portable index per §6.1.4. The audit record includes:

- The proof's anchor reference per *BAVAI Operator Specification v1.0* §4
- The methodology version used (per §10)
- The audit timestamp
- The dimension-level breakdown (which dimensions contributed what to the score)
- The operator's BIP340 signature

The dimension-level breakdown is included so verifiers can recompute the score and verify it matches.

**6.6 — Failed audits.** Audits can fail in three categories, each producing a different signed record type:

- **Structural failure** — the proof does not verify (a required dimension per §4.2 fails). Audit record indicates which required dimension failed. BARU = 0.
- **Submission failure** — the verification package is incomplete, malformed, or unparseable. The pipeline cannot evaluate the rubric. Refund applies per §7.
- **Methodology violation** — the proof shows evidence of attempted fabrication or other adversarial markers that go beyond a simple structural failure. Flag record published per *BAVAI Operator Specification v1.0* §6.4.

**6.7 — Multiple submissions.** A producer may submit the same proof multiple times. Each submission is a new audit with a new fee. Each produces a separate signed record. The records do not invalidate each other; both remain published and verifiable.

---

## 7. Refund Policy

**7.1 — When refunds apply.**

| Situation | Refund |
|---|---|
| Pipeline failure (our infrastructure cannot process submission) | Full refund |
| Submission failure per §6.6 (verification package incomplete or malformed) | Partial refund (we did pre-processing work) |
| Structural failure per §6.6 (proof legitimately doesn't verify) | No refund (we performed full audit and produced a definite-no) |
| Successful audit producing low score | No refund (audit was completed as paid for) |
| Successful audit producing high score | No refund (audit was completed as paid for) |

**7.2 — Refund mechanism.** Refund processing details (Bitcoin refund address handling, processing window, currency) live in operational deployment configuration. The methodology requires that refunds are processed; the mechanism is operational.

**7.3 — Disputes about scoring.** A score is the deterministic output of the rubric against the verification package. If a producer believes the verification package was misinterpreted, they may resubmit (with a new fee) for a fresh audit. Resubmission is the primary dispute mechanism for scoring complaints.

**7.4 — Disputes about methodology.** A producer who believes the rubric itself is wrong may contribute to methodology version proposals through the methodology change protocol per §8. This is not a per-audit dispute mechanism; it is a methodology-level concern handled through versioned revision.

**7.5 — Disputes about pipeline correctness.** A producer who believes the pipeline incorrectly computed the score (i.e., the pipeline does not match the published rubric) may publish a counter-computation referencing the methodology version. Any party can recompute the BARU score from the verification package and the published rubric and verify which computation is correct. The methodology's reproducibility (§3.5) is the producer's accountability mechanism against us.

---

## 8. Methodology Versioning

**8.1 — Version identification.** Methodology versions follow `vMAJOR.MINOR` semantics:

- **MAJOR** versions indicate rubric structure changes — adding or removing dimensions, restructuring required vs scored vs opt-in groupings, changing the compositional formula.
- **MINOR** versions indicate weight calibration, threshold adjustment, or non-structural refinements.

Both major and minor versions are signed and published.

**8.2 — URI structure.** Per *BAVAI Operator Specification v1.0* §6.3.3:

- Canonical URI for any specific version: `https://[operator-domain]/methodology/vMAJOR.MINOR`
- Latest published version: `https://[operator-domain]/methodology/latest`

Audit records always reference the specific version, never `latest`. The `latest` alias is for human-readable convenience; it is not used in signed records.

**8.3 — Backwards compatibility.** Older methodology versions remain published indefinitely. Audit records signed under v1.0 remain verifiable against v1.0 forever, even after vN.M is published.

**8.4 — Re-audit under new versions.** Producers may resubmit (with a new audit fee) for re-audit under a newer methodology version if they believe their score will improve. The previous audit record is not invalidated; both records remain published and both remain verifiable against their respective methodology versions.

**8.5 — Methodology change protocol.** Changes to the methodology are proposed, reviewed, and published under the operator's standard governance. The proposed change is published at a candidate URI (e.g., `/methodology/v1.1-rc1`) for community review prior to becoming the active version. The transition from candidate to active is itself a signed publication event.

**8.6 — Operator identity continuity.** Methodology versions are published under the same operator BIP340 keypair (per §10). Key rotation is a separate operational event handled per *BAVAI Operator Specification v1.0* §5.

---

## 9. Time-Decay of Scores

**9.1 — Per *Strategic Cost Calibration Model v1.3* §7.3.** A proof's BARU score reflects the methodology's evaluation at the time of audit against the cost landscape at the time of audit. As adversary hardware improves over time, the cost asymmetry that justified a given score may shift, even though the proof itself remains structurally valid forever.

**9.2 — Methodology stance on decay (v1.0).** v1.0 does **not** apply automatic time-decay to scores. Audit records remain at their assigned BARU values indefinitely. The score reflects the proof's evaluation at the time of audit, and that historical evaluation is permanently published.

**9.3 — Verifier-side decay policy.** Verifiers consuming BARU scores may apply their own time-decay policy when evaluating older audit records. This is a policy concern, not a methodology concern. The methodology does not specify a canonical decay function; verifiers compose their own.

**9.4 — Optional refresh.** Producers may resubmit older proofs for re-audit under newer methodology to obtain a current score reflecting current calibration. This is the producer-side mechanism for keeping a proof's score current.

**9.5 — Future automated decay (deferred).** A future methodology version may introduce a published time-decay function that adjusts BARU values for proofs older than a threshold. This is not in scope for v1.0. If introduced in a future major version, the decay function would be published as part of the methodology and would apply only to records produced after the function's introduction (no retroactive decay of v1.0 records).

---

## 10. Operator Identity and Signing

**10.1 — Our keypair.** The Orange Pages operator publishes a BIP340 signing keypair per *BAVAI Operator Specification v1.0* §5. The public key is referenced in the operator's identity record at the operator's well-known URI. Key rotation follows the protocol in *BAVAI Operator Specification v1.0* §5.

**10.2 — What we sign.** Every artefact we publish:

- Audit records per §6.5
- Flag records per §6.6
- Directory listing entries and revocations per §5.5
- Methodology versions themselves (the published methodology document at each version is signed)
- Operator portable index publications per *BAVAI Operator Specification v1.0* §6.1.4

**10.3 — What our signature means.** Our signature attests that:

- Our methodology (at the version referenced in the signed record) produced this output
- Against the verification package referenced (by anchor reference per *BAVAI Operator Specification v1.0* §4)
- At the timestamp recorded
- And we accept accountability for the output as a public, non-retractable fact

Our signature does **not** transfer protocol authority. It does not certify the proof, authorise its use, or grant any privilege. It is an attestation that our methodology produced a specific score against a specific package — verifiable by any party that has the methodology version and the package.

**10.4 — Signed record format.** Audit records use the unified signed record format per *BAVAI Operator Specification v1.0* §7.5: canonical JSON per RFC 8785, BIP340-signed, tagged with `record_type`. The Orange Pages audit record `record_type` is `orangepages.audit.v1` (and equivalently `orangepages.audit.v1.1` for v1.1, etc.).

---

## 11. Constraints and Policies

**11.1 — Methodology is the ground truth, not the result.** A score is what the methodology says it is, deterministically computed against the verification package. We do not adjust scores by hand. We do not negotiate scores. The rubric is reproducible by any party with the methodology and the verification package.

**11.2 — Methodology changes cannot be retroactive.** If we change the rubric, existing audit records remain at their original scores under their original methodology versions. Producers may resubmit for re-audit under newer methodology if they wish a current score.

**11.3 — No private methodology layer.** The published methodology is *complete*. We do not have a private scoring layer that adjusts the published rubric's output. Anything that affects a score is documented in this document at the appropriate version.

**11.4 — Sovereign-vocabulary discipline.** Per *Orange Anchor Lexicon v2.7* editorial rules: we publish, sign, attest, score, audit, list, revoke. We do not certify, authorise, grant, license, or approve. The methodology's outputs are signed records that verifiers may choose to compose; they are not authorisations.

**11.5 — Determinism is load-bearing.** The methodology must remain deterministic at any version. Any pipeline component introducing non-determinism (model-based scoring, randomised sampling within the rubric) must either be excluded from the methodology or its randomness must be derivable from the verification package itself so that the score remains reproducible.

**11.6 — Adversarial submissions.** A submission that appears designed to attack the methodology itself (rather than legitimately seeking an audit) may result in a flag record per §6.6 and *BAVAI Operator Specification v1.0* §6.4 in addition to or in place of an audit record. Determination of adversarial intent is made by the methodology's evidence-based criteria, not by operator discretion.

---

## 12. Out of Scope (MVP)

The following are explicitly out of scope for v1.0:

- **Multi-tier listing.** v1.0 is single-tier (per §5.4). Multi-tier listing (e.g., Standard at BARU 50+, Premium at BARU 75+) is deferred to v1.1+ pending operational evidence.
- **Automated time-decay function.** v1.0 does not apply automatic decay (per §9.2). Decay is a verifier-side policy concern at MVP.
- **Methodology federation.** Inter-operator methodology federation (cross-operator BARU comparability, federated trust) is not part of this methodology. Each operator publishes its own.
- **White-label methodology.** This methodology is specific to the Orange Pages operator. It is published openly and may be referenced or adapted by others, but white-label productisation is not part of v1.0.
- **Subscription pricing tiers.** Audit fees at MVP are per-submission. Subscription tiering for high-volume producers or integrators is deferred.
- **ML-based fraud detection.** The methodology is fully deterministic and rubric-based at MVP. ML-based heuristics layered on top of the deterministic score are excluded from v1.0 to preserve reproducibility (per §11.5).
- **Cross-methodology score translation.** A v2.0 methodology may produce scores on a different scale, range, or structure. v1.0 does not specify a translation function from v1.0 BARU to future-version BARU; verifiers consuming records across methodology versions must reference each version's specification independently.

---

## 13. Open Items / v1.1 Targets

- **Calibration-pending weights filled in** (§4.2, §4.3, §4.4) from real audit pipeline data and adversarial test set
- **Listing threshold finalised** (§5.2) based on calibrated weights and operational experience
- **Listing tier structure decision** (§5.4) — single-tier vs multi-tier based on operational evidence
- **Concrete turnaround commitment finalised** in operational deployment configuration
- **Time-decay function decision** (§9.5) — whether to introduce automated decay and on what schedule
- **Dispute resolution refinements** (§7.3, §7.4, §7.5) based on real dispute volume and pattern
- **Adversarial test set integration** — formalisation of the adversarial submissions used to validate weight calibration
- **Methodology change governance protocol** (§8.5) — formalisation of community review and versioning governance

These are not blockers for v1.0 publication. The methodology is deployable at v1.0 with explicit calibration-pending markers, and matures into v1.1 as the listed inputs become available.

---

## Appendix A — Cross-Document Mapping

How this document satisfies its references:

| Reference | Source document | Satisfied by |
|---|---|---|
| Operators must publish methodology | *Operator Spec* §6.3.1 | §1, §3 |
| Methodology URI | *Operator Spec* §6.3.2 | §8.2 |
| Methodology versioning | *Operator Spec* §6.3.3 | §8 |
| Signed records format | *Operator Spec* §7.5 | §10.4 |
| Operator BIP340 keypair | *Operator Spec* §5 | §10.1 |
| Flag records | *Operator Spec* §6.4 | §6.6, §11.6 |
| Operator portable index | *Operator Spec* §6.1.4 | §6.5, §10.2 |
| Anchor reference | *Operator Spec* §4 | §6.5, §10.3 |
| Verification package format | *Operator Spec* §7.4 | §6.1 |
| Deference to methodology | *Orange Pages SRS v1.1* §3.2.2 | entire document |
| Audit produces signed record per methodology | *Orange Pages SRS v1.1* FR-W-305 | §6.5 |
| Listing threshold mechanism | *Orange Pages SRS v1.1* §3.2.3 | §5 |
| BARU operator-defined | *Lexicon v2.7* §5b | §3 |
| Cost-lever framework | *SCCM v1.3* §3 | §4 (rubric organisation) |
| Calibration profiles alignment | *SCCM v1.3* §5 | §3.3 (band interpretation) |
| Opt-in cost layering | *SCCM v1.3* §3.5, §6.3 | §4.4 |
| Time-decay as policy concern | *SCCM v1.3* §7.3 | §9 |

---

## Appendix B — On the Calibration-Pending Discipline

A short note on why v1.0 ships with explicit `CALIBRATION-PENDING` markers rather than placeholder numbers.

**Honest uncertainty is better than confident handwaving.** We do not have real audit pipeline data yet. We do not have an adversarial test set. Filling in numbers we cannot defend would create the impression of calibration where none exists. The discipline of marking weights pending is the methodology's commitment to honest claims.

**Methodology versioning is designed for this.** v1.1 is a normal artefact, not an emergency patch. The minor-version mechanism (§8.1) exists precisely so that calibration values can mature without disturbing the rubric structure or invalidating prior records.

**The rubric structure is stable.** What is pending is the *weights*, not *what we measure* or *how we measure it*. The structural decisions — required vs scored vs opt-in dimensions, the cost-lever axis grouping, the deterministic compositional formula — are locked in v1.0. Anyone implementing the methodology at v1.0 can trust the structure to remain stable into v1.1.

**The framework is principled.** The rubric is organised around the cost-lever framework of *Strategic Cost Calibration Model v1.3*. Even before the weights are calibrated, the rubric is *structurally* defensible: it measures things that the cost-asymmetry model says matter. Weight calibration in v1.1 will refine the proportions; it will not change what is measured or why.

**Reproducibility holds even with pending weights.** The compositional formula (§4.6) is stated explicitly. v1.0 audit records include the dimension-level breakdown (§6.5). Any party can recompute v1.0 scores from v1.0 verification packages and the v1.0 rubric — including the v1.0 weight values once they are filled in for v1.1. There is no hidden state.

**This is the same discipline the SCCM uses.** The *SCCM v1.3* also carries TBD markers on lever values pending implementation feedback. The pattern is consistent across the analytical layer of the suite: principled structure now, calibrated values as evidence accumulates.

---

## Appendix C — Worked Audit Record Example

For implementer reference. A representative audit record produced by this methodology at v1.0 would have the following shape (canonical JSON per RFC 8785, signed per *BAVAI Operator Specification v1.0* §7.5):

```json
{
  "record_type": "orangepages.audit.v1",
  "methodology_version": "v1.0",
  "anchor_reference": "<canonical anchor reference per Operator Spec §4>",
  "audit_timestamp_utc": "2026-05-15T14:30:00Z",
  "baru_score": 67,
  "baru_band": "Hardened",
  "dimensions": {
    "required": {
      "D-R-1": { "passed": true, "evidence": "144-block heavyweight burn confirmed" },
      "D-R-2": { "passed": true, "evidence": "memory-hard checkpoint chain coherent" },
      "D-R-3": { "passed": true, "evidence": "spark debt within tolerance" },
      "D-R-4": { "passed": true, "evidence": "anchors confirmed at heights N and N+144" },
      "D-R-5": { "passed": true, "evidence": "VDF chain valid; signature valid" }
    },
    "scored": {
      "D-S-1": { "score": 0.85, "evidence": "7 modalities present" },
      "D-S-2": { "score": 0.78, "evidence": "joint coherence within tolerance under load" },
      "D-S-3": { "score": 0.62, "evidence": "sampling rates per modality summary" },
      "D-S-4": { "score": 0.55, "evidence": "bursts present at reseed events" },
      "D-S-5": { "score": 0.91, "evidence": "high-density witness in final hour" },
      "D-S-6": { "score": 0.30, "evidence": "uniform 2-anchor schedule" }
    },
    "opt_in": {
      "D-O-1": { "score": 0.0, "evidence": "no gossip witnessing" },
      "D-O-2": { "score": 0.0, "evidence": "no Nostr publication" },
      "D-O-3": { "score": 0.0, "evidence": "no watcher confirmations" }
    }
  },
  "operator_identity": "<operator BIP340 public key reference>",
  "signature": "<BIP340 signature over canonical JSON of all preceding fields>"
}
```

This format is illustrative for v1.0. The exact field names and structure are finalised in coordination with the operator portable index format per *BAVAI Operator Specification v1.0* §6.1.4.

The dimension-level breakdown is included so any verifier can recompute the BARU score from the verification package and the rubric weights at the methodology version, and verify that the published score matches their independent computation.

---

*Orange Pages Audit Methodology v1.0 — Released as the published methodology of the Orange Pages audit operator. Protocol-form with starter rubric. Concrete weight values are CALIBRATION-PENDING and will be filled in for v1.1 once real audit pipeline data and adversarial test data are available. The rubric structure is stable from v1.0.*