Set 7 Oracle Sibling Bundle

Oracle-sibling behavior is replayed from copied code

The Oracle mostly runs on live feeds and a bridge-backed reasoning engine, so this component asks which parts are pure and inspectable without any feed, provider, or reasoning call. The Oracle is a sibling system that reasons about market evidence. Most of it depends on live data feeds and on a bridge-backed reasoning engine, so it cannot be shown to a public reader directly. This component answers a narrower question. Which parts of the Oracle are pure, deterministic, and inspectable, and can those parts be run and checked without touching any feed, provider, or reasoning call?

The fixture separates advisory output from authority

The answer is the grounding and bookkeeping layer: four network-free tools that map evidence to targets, hydrate saved artifacts, diff timed feeds, and plan chain repair. The answer is the Oracle's grounding and bookkeeping layer. Before the Oracle reasons, it builds a map of which evidence supports which prediction target, it hydrates a saved artifact from a recorded run, it diffs two timed snapshots of the same economic feed, and it plans how to repair a missing artifact chain. None of that needs the network or the reasoning engine. This component imports the exact source for those four tools, exercises each against small in-memory runs, and re-runs the Oracle's own tests as an independent witness.

A passing oracle replay remains non-authoritative

The output stays metadata-only: a result record of counts, booleans, and digests, nothing more. Every run emits a result record of counts, booleans, and digests. Source bodies and test output never enter it.

Purpose

Why replay against the real source

A paraphrased or hand-tuned replay would be indistinguishable from theatre, so the component drives the real Oracle source against small readable fixtures and stops before any reasoning call. A loose replay would be easy to fake and hard to trust. If the bundle copied paraphrased logic, or ran the tools against inputs shaped to pass, a reader could not tell inspection from theatre. So the component imports the real Oracle source and drives it against fixtures small enough to read but specific enough to make the domain rules visible. It also stops at a hard line. The Oracle's repair planner can, if asked, call the bridge-backed GodModeEngine to fill a missing node by reasoning. This component walks the planner up to that point and no further. It builds the plan, copies one aliasable artifact, and records run_missing_quartet and GodModeEngine as excluded. The exclusion is part of the evidence, not a gap in it.

How it works

_evaluate orders the pipeline

_evaluate runs the pytest witness then five engines in fixed order, and a single engine that misses pass turns the whole result to blocked. _evaluate runs the pipeline in a fixed order. It first calls _run_original_pytest_witness, then the five engines listed below, then it collects findings from the source manifest check, the witness, and each engine. Any engine that does not reach pass becomes a structured finding, and one finding turns the whole result to blocked. run and run_batch7_oracle_sibling_bundle wrap _evaluate through the shared run_crown_jewel_organ runner, which handles input loading, the source-manifest gate, and result record writing.

Grounding a price prediction to admissible support

Only stock or ETF evidence (the S_ or E_ prefix) can anchor a price, so XOM and XLE ground while economic TLT is carried forward as an unmet gap. The subject-index engine seeds three pieces of evidence through _seed_subject_run: a stock (XOM, ledger id S_CAFEBABE), an ETF (XLE, ledger id E_DEADBEEF), and an economic instrument (TLT, ledger id M_FEEDBEEF). The Oracle's rule is that evidence grounds a price prediction only when its subject is a valid target and its ledger id marks it as stock or ETF support, the S_ or E_ prefix. So XOM and XLE land in admissible_evidence_by_subject, while TLT stays in contextual_evidence_by_subject even though it is a valid target, because its support is context that cannot anchor a price. The engine then checks that TLT appears in missing_admissible_support_targets. The Oracle does not silently drop a target it cannot ground, it carries the gap forward.

Provenance survives snapshot hydration

A hydrated artifact must still carry its source_artifact_id and subject_run_id, so a caller knows which run a payload came from, with no body copied. The subject-snapshot engine writes one lab_director artifact and hydrates it by id. The result must carry source_artifact_id equal to lab_director and subject_run_id equal to subject, so a downstream caller knows which run a prediction payload came from. No artifact body is copied into the result record.

Diffing two timed snapshots of a feed

Diffing a 14:00 and 22:00 snapshot names the changed series by absolute delta (US10Y 4.10 to 4.35), the newly appeared CPI, and the dropped OIL. The truth-diff engine writes two snapshots of the same economic feed, a subject snapshot at 14:00 and a truth snapshot at 22:00. It confirms the diff names the changed series ranked by strongest absolute delta, here US10Y moving from 4.10 to 4.35, a newly appeared series CPI, and a dropped series OIL. This is the difference between a number changing and the system knowing which number changed, by how much, and whether the set of series itself shifted.

Planning repair up to the reasoning boundary

The repair planner reports BLOCKED, names the deepest missing node, and writes one alias, but stops short of ever constructing the reasoning-backed GodModeEngine. The quartet engine exercises the repair planner against a truth run missing most of its node chain. The plan must report readiness BLOCKED, name the deepest missing target oracle_cp2_emitter, and list prediction_reconciliation as aliasable. The engine materialises that one alias and reads the written file back to confirm its artifact_alias_of records oracle_truth_diff_equity. It asserts run_missing_quartet_excluded and that GodModeEngine was never constructed.

flowchart TD input["Fixture input exercise manifest"] witness["_run_original_pytest_witness focused Oracle tests, >=7 passed"] index["_subject_index_engine admissible vs contextual grounding"] snap["_subject_snapshot_engine provenance survives hydration"] diff["_truth_diff_macro_engine changed / new / dropped series"] quartet["_quartet_repair_engine plan BLOCKED, one alias written"] stop["excluded: run_missing_quartet / private orchestration engine"] record["Result record counts, booleans, digests; no bodies"] input --> witness witness --> index index --> snap snap --> diff diff --> quartet quartet --> stop quartet --> record

Negative cases

Five malformed inputs, one error code each

Five negative inputs are declared in EXPECTED_NEGATIVE_CASES, each mapped to a stable error code and run through evaluate_negative_case. The component declares five negative cases in EXPECTED_NEGATIVE_CASES, each mapped to a stable error code, and evaluated through evaluate_negative_case.

What each rejection code guards

Missing run, artifact-id, or truth directories each reject with a named code, the excluded quartet node is enforced, and observations record only the exception type, never its body. A subject-index run with no run directory rejects with BATCH7_ORACLE_SUBJECT_RUN_REQUIRED. A snapshot run with no artifact id rejects with BATCH7_ORACLE_ARTIFACT_ID_REQUIRED. A truth-diff run with no truth directory rejects with BATCH7_ORACLE_TRUTH_RUN_REQUIRED. The quartet planner must both refuse to run the missing node and confirm the manifest lists run_missing_quartet as excluded, tracked as BATCH7_ORACLE_RUN_MISSING_EXCLUDED. If the Oracle's own tests do not pass as a witness, the case BATCH7_ORACLE_ORIGINAL_PYTEST_WITNESS_REQUIRED fires. Each observation records only the exception type and whether the expected message fragment appeared, never the exception body.

Prior Art Grounding

Test-oracle and provenance lineage

The design reuses two known ideas, the test oracle that decides whether an output is acceptable and W3C PROV data provenance, for deterministic replay, not for semantic truth. The component draws on two established practices. A test oracle is the part of a test that decides whether an observed output is acceptable, surveyed in the test oracle problem literature. Data provenance records where an artifact came from and how it was derived, modelled by the W3C PROV family of entities, activities, and agents. The subject index and snapshot tools apply the provenance idea, the truth-diff and quartet checks apply the oracle idea. This component reuses those patterns for deterministic replay. It does not turn a local check into semantic truth.

Validation Result record Path

Run from microcosm-substrate/:

What a result record writes and proves

The run writes result, board, and validation-result record files, and a pass means the five engines met their contracts and the record held no bodies, nothing more. The run writes batch7_oracle_sibling_capsule_result.json, batch7_oracle_sibling_capsule_board.json, and batch7_oracle_sibling_capsule_validation_receipt.json under the output directory, plus the sign-off file. The focused test suite is tests/test_batch7_oracle_sibling_capsule.py. A pass means the five engines met their contracts, the negative cases rejected as declared, and the result record held no bodies. It means nothing beyond that run.