For auditors / third-party recipients / acceptance reviewers

Read SCU as a delivery-and-verification structure, not as formulasEvidence Pack / Verifier / Submission Bundle

This page is a public guide for understanding SCU by what is delivered, how it is checked, and what is handed to third parties. It is not the fixed-sample experience page and not the contracted client workspace. It exists only to align the reviewer’s reading order.

Not a formula pageAudit-facing readingAcceptance not guaranteed

1. What SCU is

SCU is an audit infrastructure that fixes observable inputs, issues fixed acceptance artifacts as an Evidence Pack, and makes acceptance possible through central-ledger verification. The value is not formula disclosure but the fact that the deliverable and verification procedure are fixed.

  • Public pages explain what arrives, how it is checked, and what is not claimed.
  • Internal formulas, internal implementation, and reproducible source materials are not disclosed.
  • Even if someone reproduces the same value independently, it is not treated as an SCU acceptance artifact without an SCU-issued Evidence Pack and central-ledger verification.

2. What arrives

The current-phase standard deliverable is the Evidence Pack (canonical JSON). The primary visible verification fields are limited to `opaque_ref / evidenceHash / pack_sha256 / fixed_at`; internal keys and formulas are excluded.

  • Evidence Pack (canonical JSON)
  • Public reference token `opaque_ref`
  • Primary verification digest `evidenceHash`
  • Pack-integrity digest `pack_sha256`
  • Fixed time `fixed_at`

3. Verification order

Standard acceptance matches the local Evidence Pack against the fixed record SCU keeps. Re-running C0/C1 formulas on the recipient side is not part of the current standard.

  1. Confirm `opaque_ref / evidenceHash / pack_sha256 / fixed_at` in the Evidence Pack.
  2. Run public verification (Verifier / `/api/scu/audit`) against `opaque_ref + evidenceHash`.
  3. Use `pack_sha256` to confirm that the local Evidence Pack itself was not altered.
  4. Confirm `status="MATCH"` and `fixedAt`, then close acceptance according to the SOW conditions.

Public `MISMATCH` does not prove tampering. It may still mean not-yet-anchored, reference mismatch, or environment differences.

4. What third parties should read

When third-party submission is required, read the Submission Bundle as the baseline. The bundle is not the formula; it is the minimum set that allows review using the submitted materials only.

  • `ledger_entry.json`
  • `evidence_pack.json`
  • `VERIFY_OFFLINE_1PAGE.md`
  • `audit_receipt.json` / external-anchor receipts only when they already exist

Third-party acceptance is not guaranteed. Whether/what to submit, including redaction, is fixed in the SOW before contract.

5. What this page does not claim

  • It does not claim business adoption, specific outcomes, legal acceptance, or regulatory passage.
  • It does not disclose SCU’s internal formulas, implementation, or internal runbooks.
  • It does not claim that `MATCH` alone satisfies every third-party requirement.
  • It does not allow additional audit requirements to be injected after the SOW if they were not agreed beforehand.

6. Which page to read next

See a fixed sample

Use the fixed sample to inspect the deliverable shape and the minimal verification flow.

C0 Demo

See public transaction scope

Review transaction scope, delivery, retention, and third-party submission assumptions.

Transaction info

Open a case

If third-party submission or extra audit conditions are required, fix them before contract.

Consult