Trinity — SOST Discovery Engine | Reproducible Scientific Pipeline

// IN PLAIN ENGLISH

A One-Paragraph Read for Non-Engineers

Trinity takes a geographic area, turns the available evidence into a reviewed scientific dossier, identifies what deeper computation would be needed next, and seals the complete workflow into a cryptographic proof that can be timestamped on SOST.

Trinity does not claim that a mine has been discovered. It proves that a specific scientific workflow existed, with specific inputs, outputs and limitations, at a specific point in time.

// 00 — WHAT IS TRINITY

What Trinity Does

// CANONICAL OBJECTIVE

"Take a geographic AOI. Produce a council-reviewed scientific dossier. Plan the future heavy compute it would require. Bind everything into one cryptographic proof bundle. Anchor that bundle on SOST as a public, immutable timestamp."

Trinity is not "another AI tool" and not "another altcoin". It is a deterministic pipeline whose every artefact is byte-reproducible between machines and whose final output is a single SHA-256 the operator can register on chain in one transaction.

Once registered, the proof bundle is a public claim of priority and authorship for a specific scientific workflow at a specific block height — verifiable by anyone, with no permission required, with no trust in the author beyond the cryptography.

// WHAT TRINITY IS NOT

Not a mineral reserve claim. Trinity records cryptographic priority over a workflow output, not over a deposit.
Not an announcement of active Useful Compute rewards. The Useful Compute layer is dry-run by design; no rewards have been activated.
Not a published task list. The public Useful Compute API is unchanged.
Not an automated broadcaster. Every Trinity script prepares artefacts; the operator decides whether to broadcast.
Not a guarantee of geological or scientific content. Each dossier carries the source honesty matrix and the AI Council's explicit verdict, including holds and contradictions.

// 01 — TERMINOLOGY NOTE

What "Discovery Engine" Actually Means

Important. "Discovery Engine" does not mean Trinity claims to have discovered a mineral deposit, a reserve, a grade or any commercial mining target.

In Trinity, "discovery" refers to the reproducible discovery workflow itself: the evidence gathered, the hypotheses reviewed, the compute plan proposed, the limitations recorded and the final cryptographic bundle produced from them.

The proof Trinity produces is about the existence and integrity of the scientific process — not about ownership of land, reserves, grades or commercial viability. Anyone reading a Trinity bundle is reading a sealed scientific workflow, not an exploration claim.

// 02 — THE FIVE PILLARS

Architecture: Five Reproducible Subsystems

Each pillar is an existing SOST subsystem with its own validation, tests and public surface. Trinity adds the binding layer between them; it does not duplicate any of their internals. From v0.2 onwards SOST AI is invoked directly by both Earth Track and Materials Track — the reviews you see in any dossier come from the canonical multi_ai_review.AICouncil, not from a per-track mock.

PILLAR 1

GeaSpirit

Multi-source mineral prospectivity. Sentinel-1/2, Landsat, EMIT, DEM, geological maps, geophysics. Produces ranked AOI scorecards with explicit blind-spot disclosures (honesty matrix).

→ sost-geaspirit.html

PILLAR 2

Materials Engine

FastAPI engine (212 routes) with 76k+ materials, DFT/MLIP workflow scaffolding, scoring, novelty and frontier modules. Hosts the SOST AI Council code, the Hypothesis schema and the public-claim guard.

→ sost-materials-engine.html

PILLAR 3

SOST AI (council)

Evidence-first autonomous research engine. Trinity tracks invoke the free-tier AICouncil (validator + local_knowledge + mock_ai) per hypothesis. Deterministic, offline, no paid calls. Provides accept / hold / reject / contradicted with confidence and per-member rationale embedded in the dossier.

→ sost-ai-engine.html

PILLAR 4

Useful Compute (dry-run)

Heavy-task planner: MLIP relaxations, DFT input preparation, AOI tile scoring, spectral template scoring, cross-worker validation. Classifies each family as candidate_reward_worthy / deferred / not. No rewards active.

→ Phase 2 reference: useful-compute-trial.html

PILLAR 5

SOST Capsule Rail

Native PoW chain with the Capsule Protocol v1: OPEN_NOTE_INLINE (80 B short label) and DOC_REF_OPEN (URL + hash) modes anchor any digital artefact with the same audit guarantees as a coin transaction.

→ sost-protocol-spec.html

Why these five. Each pillar contributes evidence in a different domain — Earth (GeaSpirit), materials science (Materials Engine), council reasoning (SOST AI), future compute capacity (Useful Compute), and public timestamp (SOST Capsule Rail). Each one is independently verifiable. Trinity's job is to compose them into one document with one root SHA-256, not to invent new domains. The SOST AI council is the one that signs each per-hypothesis decision on every track from v0.2 onward.

// 03 — WHY SOST

Why Anchor Trinity on SOST?

A normal database can store a dossier. A website can publish it. A Git repository can version it. All three still depend on the operator who controls the server, the account or the repository.

SOST adds a property none of those have: a public, permissionless, Proof-of-Work timestamp that is independent from the Trinity operator once written on chain.

// WHAT THE CAPSULE ANCHOR GIVES TRINITY

The existence of the workflow can be verified without trusting the project website — anyone with a SOST node sees the capsule.
The timestamp cannot be silently rewritten by the author; the block height is fixed by Proof of Work.
The proof survives even if the original mirror server, repository or domain disappears.
Future reputation, ranking or reward systems can refer to the same immutable root across all bundles.
A third party can fork the public chain data and reproduce every Trinity claim from first principles.

Trinity gives SOST a concrete role beyond moving value: proving the existence of reproducible scientific work. The chain is no longer just a ledger of coins — it is also a ledger of verifiable workflows.

// 04 — THE PROOF PIPELINE

From AOI to Proof Bundle

Five deterministic steps. Every step writes a JSON file. Every JSON file has a SHA-256. Every SHA-256 is reproducible byte-for-byte across machines given the same inputs and pinned timestamps.

Step	Artefact	Anchor SHA-256
1. Scan	GeaSpirit produces `scorecard_<aoi>.json` with feature availability, honesty matrix and optional ranked targets.	scorecard_sha256
2. Review	`aoi_to_dossier.py` emits per-target Hypotheses, runs each through the AI Council (validator + local-knowledge + mock), records decisions and council opinions in a `TRINITY_DEMO_DOSSIER_<aoi>.json`.	dossier_sha256
3. Plan	`useful_compute_plan.py` proposes candidate Heavy Task families derived from the dossier reviews, classifies each as candidate_reward_worthy / deferred / not, and simulates a queue. Dry-run, no rewards.	useful_compute_plan_sha256
4. Campaign	`trinity_campaign.py` binds the dossier and plan into a Campaign Manifest with 11-entry evidence-gap inventory, 6-bucket next-actions taxonomy (immediate / UC candidate / external data / operator review / blocked / unsafe-or-forbidden), and ready-to-register flags.	campaign_sha256
5. Bundle	`trinity_proof_bundle.py` emits the single root artefact: `TRINITY_PROOF_BUNDLE_<name>.json`. Combines the four anchor SHAs into a binary Merkle root and a top-level `proof_bundle_sha256`.	proof_bundle_sha256

// MERKLE BINDING — FIXED ORDER, 4 LEAVES

leaf0 = bytes.fromhex(scorecard_sha256)
leaf1 = bytes.fromhex(dossier_sha256)
leaf2 = bytes.fromhex(useful_compute_plan_sha256)
leaf3 = bytes.fromhex(campaign_sha256)

node01 = SHA256(leaf0 || leaf1)
node23 = SHA256(leaf2 || leaf3)

merkle_root = SHA256(node01 || node23)

Algorithm is documented inside every Proof Bundle JSON as a free-text field, so a third party can reproduce the root without reading the script.

// 05 — FIRST PROOF BUNDLE

Kalgoorlie Phase 1 — Live On Chain

Important. This bundle is a cryptographic timestamp, not a mineral reserve claim. The Kalgoorlie scorecard ran with features_available = 0, so the dossier explicitly operated in fallback mode and the AI Council returned a hold decision. The bundle records that honesty in full.

// ON-CHAIN ANCHOR

AOIKalgoorlie Phase 1 Block height#8085 TXIDd68678b5d15ca8a60b70a7aa17647bfa12271d342eef066e1b4a832f4624f3db Capsule modeOPEN_NOTE_INLINE (Capsule Protocol v1) Capsule texttrinity-proof kalgoorlie_phase1 3a28a4b112fe95df Self-sendsost1ca9097d830b74495b95db9d779ad63c90579bc18 → itself (0.01 SOST)

// THE FOUR ANCHORS BOUND BY THE BUNDLE

Anchor	SHA-256
scorecard	836b677c14a73ee3f44b3cf066c82bd5e933c692eaf359c468674d9b48ba8246
dossier	d0bbc47e62f3d51baa5c535cbf4cf20e9e3d1395003588c9b8b53e43e3d22fdf
useful_compute_plan	1e7ab30aa1595c8f19114382710536ed8faf0b6122ae16f441a34b55a2647b49
campaign	7253cf30cf2f45e6dc5979fd8c2ea058397fa7d35356b7a2a2f28bb7ca4d85df
merkle_root	a818a1e4799ec34fd5a65b17d180a9534f791d4cd49f54c97b21c11d7b0e28b4
proof_bundle_sha256	3a28a4b112fe95df85ab2ab91deb7698ebeb1d9182297f06635fd12fd4053a02

How to read the on-chain capsule. The OPEN_NOTE_INLINE body is 47 ASCII bytes (under the 80-byte cap). It carries three space-separated fields: trinity-proof is the namespace, kalgoorlie_phase1 is the bundle name, and 3a28a4b112fe95df is the first 16 hex of the proof_bundle_sha256. The full 64 hex lives in the published JSON; anyone with that file can run sha256sum on it and confirm the on-chain prefix matches.

// PUBLIC REGISTRY ENTRY

This proof bundle has a corresponding entry in the canonical Trinity Proof Registry. The registry is a single JSON file that lists every Trinity bundle anchored on the SOST chain, alongside its txid, block height, capsule text and recomputable hashes.

Registry statusregistered Registration methodmanual-cli Registry idkalgoorlie_phase1 Block height#8085 TXIDd68678b5d15ca8a60b70a7aa17647bfa12271d342eef066e1b4a832f4624f3db Capsule texttrinity-proof kalgoorlie_phase1 3a28a4b112fe95df proof_bundle_sha2563a28a4b112fe95df85ab2ab91deb7698ebeb1d9182297f06635fd12fd4053a02 Merkle roota818a1e4799ec34fd5a65b17d180a9534f791d4cd49f54c97b21c11d7b0e28b4 Registry JSONTRINITY_PROOF_REGISTRY.json · TRINITY_PROOF_REGISTRY.md Registry verifierverify_trinity_registry.py

What the registry entry proves. The entry records the timestamped existence of one specific Trinity proof bundle on chain at block #8085. It does not prove mineral reserves, geological conclusions, or the activation of Useful Compute rewards. The registry is dry-run by design: the verifier never opens a network connection, never calls SOST RPC, never touches a wallet.

// VERIFY THE REGISTRY ENTRY LOCALLY

git clone https://github.com/Neob1844/sost-core.git
cd sost-core
python3 scripts/trinity/verify_trinity_registry.py TRINITY_PROOF_REGISTRY.json

Closed list of 13 checks (R1–R13). Expected output: every check ends in [PASS], with [verify] OK and exit code 0. The verifier additionally re-hashes the proof bundle and reuses verify_trinity_bundle.py for an offline cross-check.

// 05B — USEFUL COMPUTE STACK (SPRINTS 5.6 – 5.18d)

Post-Kalgoorlie Discovery → Reward Pipeline

Block #8085 anchored the first proof bundle. Everything in this section is what was built after that anchor — a deterministic, offline, consensus-isolated pipeline that turns the Heavy Tasks proposed by Trinity into reviewable, signable-later payment drafts. v0.1 of this stack never signs and never broadcasts. Every artefact is a JSON file you can diff, replay and discard before any chain operation happens.

// THE ELEVEN SPRINTS

Sprint	Layer	What it ships	Schema / Artefact
5.6	Foundations	Task builder, reward model, orchestrator, error memory. The deterministic seed of the entire pipeline + the Sprint 5.6 strict static safety harness used by every later sprint.	`useful_compute_request` v0.1, `useful_compute_result` v0.1
5.7	Workers	Worker executor with placeholder backend. Pure-Python, deterministic, no network, no GPU — just enough to prove the schema and the replay path.	`useful_compute_result` v0.2
5.8	Validation	Replay validator. Re-executes worker results independently and flags any divergence as `mismatch`; tampered or non-determinstic results never reach reward eligibility.	`useful_compute_validation` v0.1
5.9	Governance	Governance gate. Per-request decision of `accepted` / `rejected` across a batch of validations, with explicit reason codes (no quorum → rejected, replay mismatch → rejected, etc.).	`useful_compute_governance_batch` v0.1
5.10	Daemon	Background daemon. Loops the pipeline locally on the miner. No network, no privileged file access, writes a tick state file so the operator can audit every iteration.	`trinity_background_state` v0.1
5.11	UI	Web Miner Compute Console (`website/trinity-useful-compute.html`). Read-only viewer for every artefact in this section. Loads files from disk; no `fetch()`, no inputs, no signing button.	HTML page, schema-tagged renderers
5.12	Backends	Real backend adapter contract — three kinds: `placeholder`, `sandbox_toy`, `real_backend` (reserved, not wired). Hard sandbox: no network, no shell, no FS escape.	`useful_compute_result` v0.4 with `backend_kind`
5.13	Benchmark	Deterministic micro-benchmarks (`worker_id_hash`, `machine_fingerprint_hash` via `sha16`). Lets the network compare claimed capacity to actual capacity without leaking machine identity.	`useful_compute_benchmark` v0.1
5.14	Policy	Reward budget policy with conservative caps. Defaults: 1 SOST/day, 10 SOST/epoch, 0.05 SOST/job, 0.02 SOST/worker. Reward split 70/20/10 (workers / replay / governance reserve).	`useful_compute_reward_budget` v0.1
5.15	Proposal	Payment proposal. Consolidates accepted governance batches under the active budget into a single capsule summary (`useful_compute_reward_batch_v1`) ready for review. Worker-address map is local-only.	`useful_compute_payment_proposal` v0.1
5.16	Draft	Signed payment draft. Two modes: `unsigned-only` (default, no wallet touched) and `dry-sign` (wallet path verified, signed tx is a placeholder — real bytes deferred). Pre-argparse scan rejects any `--broadcast` / `--send` / `--payout-now` / `--auto-pay` / `--sendrawtransaction` / `--export-private-key` argv with exit code 2.	`useful_compute_payment_draft` v0.1
5.17	Real Signing	New `--real-sign` mode delegates to `sost-cli createtx` via a strict `subprocess.run` allowlist (`shell=False`, only the `createtx` subcommand). Multi-output guard refuses to produce conflicting txs; `--only-worker-id-hash` selector picks exactly one payable item from multi-worker proposals.	`useful_compute_payment_draft` v0.2 + `useful_compute_real_signer`
5.18	Human Broadcast	New `sost-cli sendrawtransaction` subcommand + Python `useful_compute_broadcast_guard`. Two modes: `local-dry-run` (default, no subprocess) and `human-broadcast` (requires the exact token `I_UNDERSTAND_THIS_WILL_BROADCAST_A_SIGNED_TRANSACTION`). Receipt always written; status enum `dry_run` / `broadcasted` / `cli_rejected` / `node_rejected` / `txid_mismatch` / `parse_error`.	`useful_compute_broadcast_receipt` v0.2
5.18b	Hardening	C++ subcommand validates its own input (empty / odd / non-hex / extra args). `--help` path fixed so subcommand prints specific usage. Receipt always written on failure (`broadcast_attempted`, `node_txid_observed`, stdout/stderr sha256).	same schema, hardened
5.18c	Address Format	Trinity address validator aligned with canonical encoding `sost1 + 40 lowercase hex` defined in `include/sost/address.h`. The earlier bech32-shaped regex rejected real `sost-cli getnewaddress` output; now accepted.	`SOST_ADDRESS_PATTERN` centralised
5.18d	Wallet-free Broadcast	The `sendrawtransaction` CLI handler now runs before the global wallet load, so broadcasting a pre-signed hex no longer requires a wallet file. New `cli_rejected` receipt status distinguishes CLI-side failures (wallet, hex, RPC auth) from node-side failures (fee, double spend).	`broadcast_result_status` enum + receipt v0.2

// THE PIPELINE END-TO-END

1. Task Builder — deterministic useful_compute_request seeded from Trinity's NextAction queue.

2. Worker — executes the request in the requested backend, emits useful_compute_result with backend_kind stamped.

3. Replay Validator — re-runs the same input independently; produces useful_compute_validation with match / mismatch.

4. Governance Gate — turns the validation set into useful_compute_governance_batch with per-request accepted / rejected.

5. Benchmark Ledger — correlates result claims with deterministic micro-benchmarks per worker / machine fingerprint.

6. Budget Policy — enforces the daily / epoch / job / worker caps and produces useful_compute_reward_budget.

7. Payment Proposal — consolidates accepted batches under the budget into a reviewable proposal capsule.

8. Signed Payment Draft — produces a real signed_tx_hex + txid_if_signed via sost-cli createtx for exactly one selected payable item. Operator reviews; NO broadcast yet.

9. Human Broadcast Guard — on operator command, invokes sost-cli sendrawtransaction with the signed hex. Audit receipt records every attempt (dry_run / broadcasted / cli_rejected / node_rejected / txid_mismatch / parse_error).

10. On-chain confirmed — the broadcast txid is mined into a block. First Trinity Useful Compute payment confirmed in block #8512 on 2026-05-13.

Same invariant as Trinity v0: the pipeline designs and proves, it never acts. The path from a Heavy-Task hypothesis to a reward payment is fully reviewable, and the chain stays untouched until a human signs and broadcasts in a separate sprint that does not exist yet.

// Hard safety invariants enforced by schema and static checks
Every artefact's safety_status locks no_broadcast = const true, human_review_required = const true, private_keys_exported = const false, requires_separate_broadcast = const true. The 5.16 script bans subprocess, os.system, every common HTTP / socket import, and every private-key token (private_key, privkey, seed_phrase, mnemonic, passphrase) at the static-source level. The console page bans fetch(), XMLHttpRequest, WebSocket, EventSource and navigator.sendBeacon, and refuses any <input> field whose attributes look like a wallet prompt.

// STILL DEFERRED (NOT IN THIS STACK)

Real signing: signed_tx_hex is a placeholder in v0.1; a future human-driven wallet sprint replaces it with real bytes.
Real broadcast: no script in this stack ever calls sendrawtransaction or anything equivalent. Broadcast is a separate, manual step.
Real backend adapters: real_backend is reserved in the schema but no real backend is wired. Today the network only runs placeholder and sandbox_toy.
On-chain Proof Registry: the Sprint 5.x stack produces drafts but does not yet write its capsules into a dedicated on-chain Useful Compute Proof Registry.
Sharding / mass parallelism: the daemon runs one pipeline per miner; cross-miner aggregation, sharding and cluster-level scheduling are out of scope here.
Useful Compute rewards remain POSTPONED. The infrastructure above is live for dry-run testing only; block #7100 does not activate rewards. A future B+D redesign is required before any rewarded phase.

Status as of Sprint 5.40: the on-chain narrative was closed at Sprint 5.18d (16 sprints, first end-to-end on-chain payment confirmed in block #8512, 2026-05-13). Twenty-two further sprints (5.19 → 5.40) extended Trinity off-chain in three tracks: operational autonomy + scientific intake + first real_backend (5.19 → 5.32), result surfacing + materials cache + worker onboarding + dashboard surfacing (5.33 → 5.36), and external worker trial pack + queue autopilot + daily report + sprint release runner (5.37 → 5.40). Combined footprint as of Sprint 5.40: 48 trinity scripts · 27 strict schemas · 32 docs · 1518 trinity tests PASS, plus the C++ T_FEE_SIZE_* suite that pins the consensus fee/size invariant. Every on-chain event still requires an explicit operator token and never auto-loops; zero new on-chain capability has been added since 5.18d.

// FIRST PAYMENT MILESTONE · 2026-05-13 · BLOCK #8512

Sprint 5.18d closed the chain. A Trinity Useful Compute reward for one accepted worker result was real-signed locally via sost-cli createtx, broadcast through the human broadcast guard, accepted by the local node and mined into block #8512.

txid	`787cda89dec3d31f40b6281e10ba1b711685e4a713d4117a4e44dccd616f2d82`
block	#8512 mainnet, 2026-05-13
payment	31,500 stocks = 0.000315 SOST
fee	202 stocks (1 stock/byte at S8 floor)
shape	1 input, 2 outputs, no payload — 202 bytes serialised
source / destination	both `sost10a262c66d8fdcb45bd21b073b7d8674dac542542` (self-send test)
signing	Sprint 5.17 real-signed draft (`signing_mode = real_sign_local`)
broadcast	Sprint 5.18 human broadcast guard (`broadcast_result_status = broadcasted`)
proof bundle	`TRINITY_FIRST_USEFUL_COMPUTE_PAYMENT_PROOF_20260513T190442Z/`

Self-send note. Source and destination addresses resolved to the same wallet for this test. Block explorers may label the outputs as “change” / “payment sent 0.0000 SOST” because of that. The reward output exists in vout[0] for 31,500 stocks and is recorded across the entire proof trail (Sprint 5.15 proposal · Sprint 5.17 real-signed draft · Sprint 5.18 broadcast receipt · on-chain RPC getrawtransaction).

Fee/size note. The explorer displays roughly 226 bytes for this tx while consensus measured 202 bytes; both numbers are correct in their layer and consensus rule S8 was satisfied exactly at the floor. See docs/SOST_TX_FEE_SIZE_METRIC.md for the math and the new T_FEE_SIZE_* tests that pin Transaction::Serialize().size() == EstimateTxSerializedSize().

// 06 — WHEN REAL FEATURES ARE PRESENT

What a Mature Trinity Campaign Will Produce

Kalgoorlie Phase 1 proves the pipeline works end to end with features_available = 0. A fully populated campaign — one with real processed Earth-evidence features — goes further.

// EXPECTED OUTPUTS, NON-FALLBACK MODE

Ranked mineral targets with explicit coordinates and confidence intervals.
Deposit-type hypotheses tied to the local geological context (orogenic Au, VMS, IOCG, porphyry, etc.).
Council-reviewed accept / hold / reject decisions per target, with the validator's veto power preserved.
Explicit evidence gaps attached to each hypothesis — what data, scan or experiment would shrink the uncertainty.
Candidate heavy-compute tasks mapped directly to the gaps, classified as candidate_reward_worthy / deferred / not.
A proof bundle anchoring the complete chain of reasoning on SOST as one root SHA-256.

v0 proves the machine. Future non-fallback campaigns are designed to prove useful scientific output.

// 07 — CRYPTOGRAPHIC GUARANTEES

What the Bundle Actually Proves

Property	Guarantee	Enforced by
Reproducibility	Two machines with the same scorecard and same pinned timestamps produce byte-identical JSON for every step of the pipeline. The dossier records the scorecard by content (SHA-256) and basename, never by absolute path.	3 explicit reproducibility tests in `tests/trinity/`
Tamper detection	Changing any of the four anchors (or the Merkle root, or any safety flag) makes the local verifier exit non-zero. Six tampering classes covered.	`scripts/trinity/verify_trinity_bundle.py`
No host-path leak	The bundle's canonical JSON contains no `/home/`, `/opt/`, `/Users/` prefix. Filenames are basename-only.	Verifier check `C8` + test `test_no_absolute_paths_in_json`
No automatic broadcast	The capsule_preview field carries `execution_status = "NOT_EXECUTED — …"`. The script never invokes `sost-cli`, never opens an RPC connection, never touches a wallet. Registration is a manual operator step.	Verifier check `C9` + static-surface test on both modules
Dry-run watermark	Every public dataclass in the engine carries `dry_run = true`. Every output document re-states `no_rewards_active = true` and `registered = false` until the operator inscribes a confirming on-chain reference.	Verifier checks `C4 / C5 / C6 / C7`
Cross-repo test coverage	129 tests pass without any network access. 67 in `materials-engine-private` (council bridge + planner + campaign engine), 62 in `sost-core` (entrypoints, env-var resolvers, verifier, anti-leak).	`pytest -q`

// 08 — VERIFY IT YOURSELF

Local Verification Recipe

Anyone with the proof bundle JSON can reproduce every check the published bundle claims. No SOST node required; no wallet; no network.

// 1. CLONE AND CHECKOUT

git clone https://github.com/Neob1844/sost-core.git
cd sost-core
git checkout trinity/proof-bundle-v0

// 2. VERIFY THE BUNDLE

python3 scripts/trinity/verify_trinity_bundle.py \
    TRINITY_PROOF_BUNDLE_kalgoorlie_phase1.json

Twelve closed checks (C1–C10). Expected output: every line starts with [PASS], ending with [verify] OK and exit code 0.

// 3. INDEPENDENTLY CONFIRM EACH ANCHOR

sha256sum TRINITY_DEMO_DOSSIER_kalgoorlie.json
# expected: d0bbc47e62f3d51baa5c535cbf4cf20e9e3d1395003588c9b8b53e43e3d22fdf

sha256sum TRINITY_USEFUL_COMPUTE_PLAN_kalgoorlie.json
# expected: 1e7ab30aa1595c8f19114382710536ed8faf0b6122ae16f441a34b55a2647b49

sha256sum TRINITY_CAMPAIGN_kalgoorlie_phase1.json
# expected: 7253cf30cf2f45e6dc5979fd8c2ea058397fa7d35356b7a2a2f28bb7ca4d85df

sha256sum TRINITY_PROOF_BUNDLE_kalgoorlie_phase1.json
# expected: 3a28a4b112fe95df85ab2ab91deb7698ebeb1d9182297f06635fd12fd4053a02

// 4. CONFIRM THE ON-CHAIN CAPSULE

curl -s -u USER:PASS \
    -d '{"method":"gettransaction","params":["d68678b5d15ca8a60b70a7aa17647bfa12271d342eef066e1b4a832f4624f3db"]}' \
    http://127.0.0.1:18232/ | jq '.result.capsule'

The capsule.text field on a synced SOST node must equal trinity-proof kalgoorlie_phase1 3a28a4b112fe95df. The 16-hex tail is the prefix of the bundle SHA computed in step 3.

No step above requires a SOST account, an exchange, or any third-party service. The whole verification runs on public chain data plus public source code.

// 09 — SAFETY MODEL

What Trinity Refuses to Do

The campaign engine's unsafe_or_forbidden bucket is a hard veto layer above every heuristic in the system. Any candidate action whose title or description matches a closed list of forbidden substrings is routed to that bucket with the matching substring recorded as the reason. The bucket is always present in the output, with five anchor entries that document what Trinity will never automate.

Class	Concrete example
Activate rewards	`act_no_activate_rewards` — Useful Compute rewards stay dry-run until a separate consensus / governance procedure ships. The engine never flips that switch.
Publish reward-bearing tasks	`act_no_publish_reward_tasks` — The public Useful Compute worker / API is unchanged. The engine never enqueues to it.
Register hash on chain	`act_no_register_on_chain` — Capsule registration is the operator's manual decision. The engine prepares a ready-to-register bundle and stops.
Move funds	`act_no_move_funds` — The engine touches no wallet, no key, no transaction broadcast path.
Modify consensus	`act_no_modify_consensus` — Consensus rules, miner code, node code and the RPC schema are strictly out of scope. No Trinity script can touch them.

If the engine emits an action with safety=safe, by construction that action cannot be in the unsafe bucket. This invariant is enforced by the test test_no_executable_action_is_forbidden in materials-engine-private/tests/test_campaign_engine.py.

// 10 — WHY THIS MATTERS

Why Trinity Matters

Most blockchains can timestamp a file. Trinity is different because the file is not the product — the reproducible scientific workflow is.

Trinity turns SOST from a chain that records data into a chain that can prove the existence of useful, structured and reviewable work:

// FOUR DOMAINS UNDER ONE AUDITABLE SYSTEM

Domain	Contribution
Earth evidence	GeaSpirit honesty matrix, ranked AOI scorecards, blind-spot disclosures.
Scientific interpretation	Materials Engine + multi-AI Council review with validator-veto and budget gating.
Future compute demand	Useful Compute heavy-task planner, classifier and queue simulation (dry-run, no rewards).
Public priority & integrity	SOST Capsule Protocol v1: open-note or doc-ref anchoring on a permissionless PoW chain.

Trinity is the bridge between mining, materials science, useful computation and blockchain verification under one audit trail. Each domain remains independently verifiable; Trinity composes them into a single root.

// 11 — AUTONOMOUS DISCOVERY FLOW

Six Stages, One Verifiable Bundle

Trinity is not a chain feature. It is a six-stage pipeline that turns a pinned seed into a public, reviewable scientific dossier. Every stage is deterministic; every output is auditable; the final SHA is what gets timestamped on SOST.

// THE SIX STAGES

#	Stage	What it does
1	Generate hypotheses	Earth: candidate AOIs across mineral belts. Materials: candidate compositions across spinel / perovskite / layered-oxide / oxide-interface families.
2	Filter	Drop obvious noise. Penalise toxicity, criticality, low evidence, charge-balance violations, known-demo formulas, and protected geographies.
3	Review	Build a dossier per candidate. Run it through an AI Council (validator + domain expert + novelty judge). Decide hold / accept / reject with strictest-member-wins veto.
4	Plan heavy work	Propose the compute or fieldwork that would actually reduce the remaining uncertainty: DFT, MLIP, phonon screening, satellite reprocessing, geophysics fusion. Dry-run only.
5	Package	Bind scorecard + dossier + plan + campaign manifest into a single proof bundle. Merkle root over four SHA-256 anchors. Canonical JSON. Byte-identical cross-machine.
6	Seal on SOST	Operator-driven manual capsule registration. One TXID, one block height, one immutable timestamp. Not automated; not consensus-affecting.

// MATERIALS TRACK — CONCRETE NUMBERS (oxide_frontier_v01)

seed: trinity-v0.1
  → generate 50 oxide candidates (spinel / perovskite / layered / interface mix)
  → chemistry filter: 42 rejected (charge balance, toxicity, known-demo)
  → 8 candidates survive
  → score on 7 industrial axes (abundance, criticality, structure, hypotheses,
                                  feasibility, novelty uncertainty, toxicity/cost)
  → AI Council reviews each: 0 accept / 8 hold / 0 reject  (honesty: thin evidence)
  → propose 16 heavy tasks: 8 candidate_reward_worthy (MLIP relax) + 8 deferred
                            (DFT input prep)
  → seal:
       proof_bundle_sha256 = 3d2c8dc3c8f280e93ae3fec59a2538a39de7d1d36352f3dfd51c618595a69cd1
       status              = ready_to_register · registered=false
       rewards             = NOT active

// EARTH TRACK — SAME PATTERN (preview of v0.1)

seed: trinity-geo-v0.1               (planned)
  → scan global commodity belts (offline curated regions in v0.1)
  → filter zones too close to known demo AOIs and obviously unsuitable coords
  → score on proxy axes (tectonic belt, aridity, ruggedness, data availability)
  → AI Council reviews each AOI: accept / hold / reject
  → propose satellite tile preprocessing, spectral anomaly scoring, geophysics fusion
  → seal: TRINITY_GEO_PROOF_BUNDLE_global_phase1.json
       status              = ready_to_register · registered=false
       claim               = "candidate AOI proposal" — NOT a deposit confirmation

Trinity never registers automatically. Stage 6 is the operator's manual decision. Useful Compute rewards stay inactive in every track; the planner emits proposals only.

// 12 — TRINITY WITHIN SOST

A Vertical Inside the Stack, Not a Replacement for It

Trinity is not a fork, not a sidechain and not an alternative consensus. It sits on top of SOST as one official scientific vertical. The blockchain core stays exactly what Bitcoin-class PoW chains do: blocks, transactions, wallets, RPC, consensus. Trinity adds the discovery + proof + reputation layer above that.

// STACK LAYERING

SOST
├── Core blockchain          consensus, PoW, blocks, mempool, wallet
├── Explorer / wallet        public read surface
├── Trinity Discovery Engine the scientific vertical
│   ├── Earth Track          GeaSpirit-driven AOI proposals
│   ├── Materials Track      autonomous candidate materials
│   ├── Proof Registry       canonical index of anchored bundles
│   └── Useful Compute       dry-run heavy-task planner
└── Rewards / reputation     future layer; off by default

Separation rules. Trinity scripts cannot touch consensus, miner code, node code, RPC schema or wallet logic. The four bundle anchors are JSON files; the on-chain artefact is one capsule per registered bundle. If you remove Trinity from this repo, SOST as a chain still works. If you remove the chain, Trinity is just a set of reproducible dossiers — which is, on its own, still useful.

// 13 — TRINITY RULES

Six Hard Constraints

Operator-enforced rules. Every sprint and every artefact respects these; the test suite checks several of them statically and the verifier checks the rest at runtime.

#	Rule
1	Trinity never touches consensus. No script in the Trinity tree can modify miner code, node code, RPC schema or the wire format. Pure userspace artefact production.
2	Trinity never promises validated discoveries. Every candidate is labeled `novelty_status=unknown_not_validated` and every dossier carries explicit not experimentally validated · not DFT validated · not a patent claim · not a commercial performance claim wording.
3	Trinity always produces verifiable bundles. Every output is canonical JSON. Every bundle is hash-bound. The verifier runs offline in seconds and refuses any deviation.
4	Trinity registers only milestones. Not every demo; not every iteration. On-chain anchors are operator-driven manual events reserved for genuine milestones (e.g. Kalgoorlie Phase 1 was the pipeline's birth certificate; the next anchor target is a combined materials + geo Genesis Discovery Batch).
5	Useful Compute rewards stay off until validation. The planner emits `candidate_reward_worthy` proposals but no reward path is wired to consensus. Rewards activation is a future, separate governance event.
6	Public framing is utility-first. The web copy leads with what the engines produce (scientific intelligence), not with the proof rail. SOST is the trust layer around the work, not the product itself.

One-line summary. Trinity is SOST's first strong use case: turning autonomous digital research into publicly verifiable proof.

// 14 — ROADMAP

What Comes After v0

Sprint	Scope	State
v0	Dossier bridge + entrypoint + Council integration. Per-AOI reviews with explicit honesty matrix.	SHIPPED · trinity/option-b-v0
v0.1	Env-var portability so the entrypoint runs on the VPS without WSL-specific paths. `TRINITY_GEASPIRIT_OUTPUTS_PATH`, `TRINITY_MATERIALS_ENGINE_PATH`.	SHIPPED
hotfix	Dossier reproducibility: `source.scorecard_path` replaced by `source.scorecard_sha256` + basename. Byte-identical dossier JSON cross-machine.	SHIPPED · trinity/dossier-reproducibility-hotfix
v0.2	Useful Compute Planner: candidate Heavy Task families, classifier wrapper, queue simulation. DRY-RUN only.	SHIPPED · trinity/useful-compute-planner-v0
v0.3	Campaign Engine: evidence-gap detector, 6-bucket NextAction ranking, manifest with ready_to_register / registered / dry_run flags.	SHIPPED · trinity/campaign-engine-v0
v0.4	Proof Bundle + local verifier. Single root SHA-256, Merkle binding, 12 closed verification checks. First on-chain anchor at block #8085.	SHIPPED · trinity/proof-bundle-v0
5.6 – 5.10	Useful Compute pipeline foundations: task builder, reward model, orchestrator, error memory, worker (placeholder), replay validator, governance gate, background daemon. See section 05B.	SHIPPED
5.11	Web Miner Compute Console (`website/trinity-useful-compute.html`) — read-only viewer for every Useful Compute artefact, no network primitives.	SHIPPED
5.12	Real backend adapter contract with sandboxed kinds (`placeholder`, `sandbox_toy`, `real_backend` reserved). `useful_compute_result` bumped to v0.4 with `backend_kind`.	SHIPPED
5.13	Benchmark ledger — deterministic micro-benchmarks (`sha16` worker / machine fingerprints) for capacity claims without identity leakage.	SHIPPED
5.14	Reward budget policy: 1 SOST/day, 10 SOST/epoch, 0.05 SOST/job, 0.02 SOST/worker. Reward split 70/20/10 (workers / replay / governance reserve).	SHIPPED
5.15	Payment proposal: consolidates accepted governance batches into a single capsule (`useful_compute_reward_batch_v1`). Worker-address map is local-only.	SHIPPED
5.16	Signed payment draft v0.1: unsigned-only / dry-sign modes, no real signing, no broadcast. Pre-argparse argv scan rejects every broadcast-style flag with exit code 2.	SHIPPED · 1518 trinity tests PASS (as of Sprint 5.40)
5.17	Real Local Signing: new `--real-sign` mode delegates to `sost-cli createtx` via a strict subprocess allowlist (`shell=False`, only the `createtx` subcommand). Multi-output guard + `--only-worker-id-hash` selector. Schema bumped to `useful_compute_payment_draft` v0.2.	SHIPPED · sprint-5.17
5.18	Human Broadcast Guard v0.1: new `sost-cli sendrawtransaction` subcommand + Python guard. Two modes (`local-dry-run` / `human-broadcast`), exact token required, one tx per invocation, audit receipt always written.	SHIPPED · sprint-5.18
5.18b	Hardening: C++ subcommand validates its own input; `--help` path fixed; audit-trail receipt v0.2 with `broadcast_attempted`, `broadcast_result_status`, `node_txid_observed`, stdout/stderr sha256.	SHIPPED · sprint-5.18b
5.18c	Address format hotfix: Trinity payment path aligned with canonical `sost1 + 40 lowercase hex` as defined in `include/sost/address.h`. The old bech32-shaped regex rejected real `sost-cli getnewaddress` output; now accepted across schemas, scripts and tests.	SHIPPED · sprint-5.18c
5.18d	Wallet-free `sendrawtransaction`: CLI handler now runs before the global wallet load. Broadcast a pre-signed hex no longer requires a wallet file. Receipt status enum gains `cli_rejected`. First end-to-end Trinity Useful Compute payment confirmed in block #8512 on 2026-05-13.	SHIPPED · sprint-5.18d · first on-chain payment
// AUTONOMY + SCIENTIFIC INTAKE + FIRST REAL_BACKEND · SPRINTS 5.19 - 5.32
5.19	Operator Loop: single-binary orchestrator `task_builder → worker → replay → gate → budget → proposal → payment_draft` with checkpoints, resume, SHA256SUMS manifest. Local-dry-run only; never signs, never broadcasts.	SHIPPED · sprint-5.19
5.20	Scientific Prompt Intake: local ingest of a scientific prompt + reference documents (`.txt` / `.md` / `.json`). Hashes every input, bounded previews, no LLM, no network.	SHIPPED · sprint-5.20
5.21 - 5.22	Intake → Task Builder bridge: `--from-scientific-intake` consumes an intake artifact and writes a Useful Compute request with `metadata.scientific_intake`. Hotfixes 5.22a-d hardened the wallet-free `sendrawtransaction` path.	SHIPPED · sprint-5.22d
5.23	Autonomy Governor: constitutional layer evaluating every proposed autonomous action against a SHA256-pinned policy. Locked to `mode=observe` and `autonomous_sost_stocks=0` in v0.1. Halt-file kill switch. Threat refs map to `SECURITY.md` T01-T20.	SHIPPED · sprint-5.23
5.24	Operator Loop × Governor: operator loop fires the Governor before each pipeline step. Hard-block on halt or policy mutation; observe-only otherwise. Audit-only trail: 7 decisions per run.	SHIPPED · sprint-5.24
5.25	Governor Watchdog: external read-only scanner of the audit trail. `safety_status` rollup `critical > warning > stale > ok`. Webhook double-gated and not yet wired.	SHIPPED · sprint-5.25
5.26	Task Queue: deterministic local queue with `init` / `enqueue` / `list` / `run-once` / `inspect` / `validate` commands. Fail-closed on governor hard-block + watchdog critical.	SHIPPED · sprint-5.26
5.27	Task Queue Runner: bounded `run-batch` wrapper. Max 50 items per invocation. `--stop-on-failure` for fail-fast. Explicitly NOT a daemon.	SHIPPED · sprint-5.27
5.28	Queue Dashboard: read-only JSON + static HTML pane over the queue + batches. XSS-escaped, no JS, no external assets, `noindex` meta.	SHIPPED · sprint-5.28
5.29	Scientific Intake Readers: pluggable readers for `.tex` / `.csv` / `.pdf` alongside `.txt` / `.md` / `.json`. Graceful PDF missing-dep (`pypdf` / `PyPDF2` dynamic import). Per-doc `reader_kind` / `reader_status` / `extracted_text_sha256` / `structured_summary`.	SHIPPED · sprint-5.29
5.30	Reader Metadata in Request: task builder carries the reader manifest (counts + per-doc subset) into `metadata.scientific_reader_manifest` in the request. No raw text leak. `input_bundle_sha256` already reader-sensitive via 5.29 mix-in.	SHIPPED · sprint-5.30
5.31	Scientific Task Classifier: deterministic no-LLM classifier (substring + regex heuristics over bounded previews). Emits `task_kind` / `candidate_materials` / `candidate_metrics` / `proposed_source_tool` / `proposed_difficulty`. Sentinel-poison privacy test enforced.	SHIPPED · sprint-5.31
5.32	Materials Engine Backend: first `real_backend` kind. Auto-routes when `source_tool=materials_engine` + classifier metadata. Curated 6×6 properties table (CeO2 / PrOx / Sm2O3 / Y2O3 / ZrO2 / TiO2). Deterministic ranking. NOT DFT. NOT measured data.	SHIPPED · sprint-5.32
// RESULT SURFACING + MATERIALS CACHE + WORKER ONBOARDING · SPRINTS 5.33 - 5.36
5.33	Materials Engine Result Surfacing: compact `materials_engine_summary` projected at three audit-friendly layers (worker result · operator_run roll-up · queue dashboard). Lives OUTSIDE the hashed bytes — cross-worker `compute_output_sha256` byte-identical with or without the summary.	SHIPPED · sprint-5.33
5.34	Materials Project-style Cache: local hand-curated reference dataset (CeO2 + PrOx records) with per-record `record_sha256`, per-property-block `property_hash_sha256` and file-level `cache_sha256`. NO live fetch. Cache fields ride INSIDE the hashed `output_obj`; cross-worker equality holds because the file is byte-identical on every host.	SHIPPED · sprint-5.34
5.35	Friendly Worker Onboarding: read-only deterministic JSON bundle for any operator-supplied `worker_id`. Payout-address pattern `<PAYOUT_ADDRESS_FOR_*>` — schema REJECTS real `sost1+40hex`. Six const-true safety flags. No keys, no mnemonics, no real addresses, no broadcast surface.	SHIPPED · sprint-5.35
5.36	Dashboard Surfacing: queue dashboard gains two columns per item: `materials_cache` ("N hits (M misses)") and `workers` ("N (worker-A, worker-B)"). Sprint 5.28 privacy contracts preserved (no JS, no external assets, no absolute paths, `html.escape` on every text insertion).	SHIPPED · sprint-5.36
// EXTERNAL WORKER TRIAL + AUTOPILOT + DAILY REPORT + RELEASE RUNNER · SPRINTS 5.37 - 5.40
5.37	External Worker Trial Pack: portable read-only deterministic directory a friendly second worker can run to prove cross-host replay equality. Ships `PACK_MANIFEST.json`, `README_WORKER_TRIAL.md`, `worker_config.json`, `sample_request.json`, `expected_result_hashes.json`. Six const-true safety flags. Pack carries NO secrets.	SHIPPED · sprint-5.37
5.38	Queue Autopilot: single-shot bounded driver over 5.27 `run_batch` + 5.28 dashboard. HARD CAP `--max-batches ≤ 24`; `--max-batches 25` refused at argv parse. Calls in-process — no subprocess, no shell, no network, no `while True`. Seven const-true safety flags.	SHIPPED · sprint-5.38
5.39	Daily Report: reads an existing Sprint 5.28 dashboard JSON (+ optional queue-dir) and emits a JSON + Markdown daily summary. Pure consumer of on-disk JSON: imports NO sibling Trinity module. Emits NO HTML, NO JS, NO inline CSS — Markdown only. Six const-true safety flags.	SHIPPED · sprint-5.39
5.40	Sprint Release Runner: local preflight verifier. Inspects branch / HEAD / base-ref / tracked-dirty / untracked / diff vs base / pytest, walks an optional demo dir for Trinity artifacts identified by schema content, not filename. READ-ONLY observer: NEVER pushes, NEVER merges, NEVER tags, NEVER touches a wallet, NEVER signs, NEVER broadcasts, NEVER uses GitHub API. Only seven read-only git verbs allowed; destructive git argv literals forbidden at lint time. Seven const-true safety flags.	SHIPPED · sprint-5.40 · closing the off-chain v1.0 stack
// FUTURE PROOF-BUNDLE LAYER IMPROVEMENTS (separate track, not in the 5.19-5.40 off-chain scope)
v0.5 (proposed)	`--register-preview` flag: prepares (never executes) the exact `sost-cli send` command for OPEN_NOTE_INLINE or DOC_REF_OPEN.	PLANNED
v0.6 (proposed)	Multi-bundle index: meta-bundle anchoring N proof bundles via the same Merkle algorithm at the next layer up. Lets the operator inscribe one root for an entire campaign batch.	PLANNED
v0.7 (proposed)	Optional ECDSA signature over `proof_bundle_sha256` using the operator's mining key — authenticated authorship even before chain registration.	PLANNED
v0.8 (proposed)	Live Materials Engine API call for deposit-type context (replaces the hardcoded map in `geo_target_council`). `canonical_memory` persistence of campaign manifests.	PLANNED
v1.0 (proposed)	First non-fallback campaign: Pilbara or Zambia with real processed features. Real mineral_target reviews with coordinates, deposit types and council accepts — not just AOI-level priority.	DEPENDENT ON DATA

None of the planned sprints involve activating rewards, opening a public API, modifying consensus, or auto-broadcasting. Trinity's core invariant — design and prove, never act unilaterally on chain — is preserved across the entire roadmap. The 5.19 - 5.40 stack is OFF-CHAIN tooling that wraps the on-chain 5.6 - 5.18d core; it adds zero new on-chain capability beyond what Sprint 5.18d already shipped.

// 15 — SOURCE & CONTACT

Read the Code

// REPOSITORY ANCHORS

Engine + verifier source on the public mirror:

scripts/trinity/ — aoi_to_dossier, useful_compute_plan, trinity_campaign, trinity_proof_bundle, verify_trinity_bundle
TRINITY_PROOF_BUNDLE.md — design document for the bundle layer
TRINITY_CAMPAIGN_ENGINE.md — campaign engine spec
TRINITY_USEFUL_COMPUTE_EXTENSION.md — Useful Compute Planner spec
TRINITY_OPTION_B_REVIEW.md — original architecture review (v0)
TRINITY_PROOF_BUNDLE_kalgoorlie_phase1.json — the live bundle as inscribed on chain

// SCIENTIFIC INTAKE

Trinity's pipeline accepts external scientific input through the Materials Engine's scientific intake module (free-only sources: arxiv, OpenAlex, Crossref, PubChem, Materials Project, JARVIS). Custom AOIs and custom hypothesis types are added by extending the Geaspirit feature pipeline and the closed taxonomies in hypothesis_schema.py and campaign_engine.py. Both layers are designed to grow without touching consensus.

The pipeline is permissionless. Anyone with a scorecard JSON, a SOST node and the Trinity scripts can produce a proof bundle for any AOI and register it on chain — with no approval, no listing, no foundation gating. The cryptography is the credential.

SOST Trinity — reproducible scientific proofs, anchored on chain