9b19085674
Rank 4 on the docket. The L10 always-on lane has passed a 5000-beat soak since
2026-07-19. That result lived as PROSE IN A CONTRACT FILE — no machine-readable
artifact, no run SHA, no rerun path, and a deterministic_digest that report.py
computed and nothing pinned. The contract's own closing line asked for the pin
("Pin it once the lane is trusted so a regression flips it") and it was never
added. A recorded prose result with no re-derivable artifact is testimony, not
evidence, and that file is exactly where the distinction was meant to be
enforced.
R-2 first, before the run — as the plan required, so the soak measured a
decided question rather than deciding one by accident.
R-2 was ruled B (beats govern cognition; wall-clock permitted in telemetry
only). Measured: this lane carries NO WALL-CLOCK AT ALL — runner.py,
predicates.py and report.py contain no time, datetime, or timestamp of any
kind. That is stronger than B requires, and it is KEPT rather than "completed",
for three reasons now recorded in the contract:
1. B's permissive half is a permission, not an obligation. Adding a field so
the code matches a ruling's letter, then adding a pin to guard the field,
is a mechanism whose only purpose is to be guarded.
2. "When was this last run?" is already the artifact's COMMIT DATE —
immutable, verifiable, stated once. A generated_at inside the report would
be a second copy of one fact, drifting the moment a report is regenerated
and not committed. That is G-23's defect class, registered this same week.
3. It keeps the digest honestly deterministic. A timestamp would have to be
excluded from it — a value in the artifact that the artifact's own
integrity check ignores.
The contract also records what WOULD change this: a predicate whose claim is
about duration rather than sequence (H5's resource-cost leg is the live
candidate). B is already ruled, so that needs no new decision — only the
predicate that requires it.
The re-run: 5000 beats, reboot at 2500, under the POST-R-3 profile. All four
predicates pass. Committed as
evals/l10_always_on/results/report-5000-6c67e88d.json, digest f814fd97….
The most useful result was not the pass. Every DETERMINISTIC fact reproduced
exactly — vault bounded at 6, convergence at beat 1 with a 4999-beat tail,
clean reboot with derived learning intact — while the machine-variant float
moved from the prose's 1.389e-07 to a worst of 6.177e-08. That is the first
real evidence that excluding versor_condition from the digest was correct
rather than convenient: a digest covering it would have flipped on a machine
change and taught every reader to ignore it. The prose figure is superseded,
not contradicted — it was never a reproducible quantity.
tests/test_l10_soak_evidence.py, on the gate, guarding two DIFFERENT failure
modes that are easy to conflate:
REGRESSION — the digest is pinned, plus the horizon (a 24-beat report pinned
as though it were the 5000-beat one would pass everything else), the four
predicates by name (all_gates_pass alone is satisfied by an empty predicate
list), and a vacuity guard on the attested set.
STALENESS — the mode nothing guarded, and the one that had ALREADY FIRED.
R-9 ruled the cadence change-triggered, not clock-triggered: local-first
doctrine makes "nightly" a ruling rather than a cron line, and a nightly that
does not run is green for the wrong reason (H-9). So instead of "when did we
last run it?", the pin asks the question that matters — DOES THIS EVIDENCE
STILL DESCRIBE THE CODE THAT SHIPS? — by holding the SHA-256 of every source
the soak attests: chat/always_on.py, chat/always_on_daemon.py, and the three
harness modules.
That is not hypothetical. It had already fired silently for six weeks: the
2026-07-19 soak ran with accrue_realized_knowledge absent from
CONTINUOUS_LIFE_CONFIG_FLAGS, so from R-3 (PR-5, this same day) onward the
recorded result attested a process that no longer existed — and nothing in the
repository could notice. HAD THIS PIN EXISTED, PR-5 WOULD HAVE FAILED IT. That
is precisely the intended behaviour, and it is verified by sabotage: touching
always_on_daemon.py turns it red.
The failure message says RE-RUN THE SOAK — DO NOT EDIT THE HASHES, because
updating a hash to match changed source without re-running converts the pin
into a record asserting evidence that does not exist. That is the failure this
whole arc is about, committed inside its own remedy.
Three sabotages observed red: a touched daemon (the staleness mode), a
regressed verdict in the artifact, and a shorter horizon pinned as if it were
5000 beats.
H1-H4 promoted onto the gate, and the cheap option was deliberately refused.
Measured 20.95s for the four real-soak "holds" and 0.46s for the eight mutation
"bites" — 98% of the cost is the holds. Shipping only the bites, or parking the
file in a curated-but-unreachable suite, would have satisfied R-9's letter and
bought nothing; a suite nobody runs is the non-guarantee this arc spent PR-4
closing. Those four holds are the ONLY tests on any gate that run
chat/always_on's run_continuous end-to-end, and that loop just shipped a
six-week silent divergence. 21s per push to actually run the process that broke
is the most defensible time on this gate. Removed from full_only_baseline.txt
in the same edit; the baseline shrank 746 -> 745.
Closes G-5. Proof-of-life has moved from prose to committed, pinned,
change-guarded evidence.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wcw2pnMBwyvmNyQg4uPEt4
|
||
|---|---|---|
| .. | ||
| adr | ||
| agents/grok | ||
| analysis | ||
| architecture | ||
| assessment | ||
| audit | ||
| benchmarks | ||
| briefs | ||
| curriculum | ||
| decisions | ||
| evals | ||
| examples | ||
| handoff | ||
| handoffs | ||
| implementation | ||
| issues | ||
| lab | ||
| outreach | ||
| paradigm-archive | ||
| plans | ||
| research | ||
| sessions | ||
| specs | ||
| workbench | ||
| zig | ||
| 3lang-depth-pr-plan.md | ||
| admissibility-exemplars.md | ||
| ci-optimization.md | ||
| conceptualizing_engineering_mastery.md | ||
| core-rd-base-prompts.md | ||
| ethics_packs.md | ||
| EVAL_AUDIT_2026-05-20.md | ||
| eval_methodology.md | ||
| frontier_baselines.md | ||
| gaps.md | ||
| handoff_template.md | ||
| hitl-backpressure.md | ||
| holdout_recipients.txt | ||
| identity_packs.md | ||
| master-plan-post-substrate-audit.md | ||
| memo.html | ||
| model_dependency_size_tally.md | ||
| pack_inventory_2026-05-21.md | ||
| position_paper.md | ||
| PROGRESS.md | ||
| README.md | ||
| recognizer-registry.md | ||
| refusal-taxonomy.md | ||
| reviewers.yaml | ||
| RUST.md | ||
| safety_packs.md | ||
| sponsors.md | ||
| teaching_order.md | ||
| test-debt-quarantine.md | ||
| testing-lanes.md | ||
| Whitepaper.md | ||
| Yellowpaper.md | ||
CORE Documentation Index
This is the central index for all documentation in the CORE project.
Canonical Root Documents
- Whitepaper.md - The CORE architectural and philosophical whitepaper.
- Yellowpaper.md - Technical specifications and mathematical formulation of the CORE engine.
- PROGRESS.md - High-level project progress tracking.
- specs/runtime_contracts.md - Critical invariants and bounds for the runtime execution flow.
Directories
Architecture & Design
- adr/ - Architecture Decision Records (ADRs). The canonical history of all ratified engineering choices.
- architecture/ - High-level architectural documents (e.g., pipelines, schemas).
- analysis/ - Deep dives and master plans for structural changes.
- specs/ - Detailed technical specifications and invariants.
Planning & Progress
- plans/ - Capability roadmaps and implementation plans.
- briefs/ - Project briefs and scoping documents for upcoming work.
- issues/ - Detailed issue analyses and technical reproductions (not standard trackers).
- audit/ - Audit reports and claims ledgers.
Operations & Usage
- examples/ - Usage examples and reference integrations.
- workbench/ - Documentation for the CORE workbench UI and related tooling.
- agents/ - Agent-specific operational guides.
Note regarding
agents/grok/: Operational guide for using Grok 4.3 + Grok Build with CORE. This is not architecture documentation.
Learning & Evaluation
- curriculum/ - Documentation on the teaching/learning order and knowledge progression.
- evals/ - Evaluation methodology and performance criteria documentation.
- benchmarks/ - Benchmark evidence and performance tracking logs.
Historical & Experimental
- sessions/ - Chronological session logs documenting the "decision trail" and intellectual history of major choices.
- handoffs/ - Legacy brief, audit, and investigation notes (historical; the formal HANDOFF mechanism is retired — see AGENTS.md for the current lightweight
session-break-summary-<DATETIME>.mdconvention). - research/ - Raw research notes and preliminary findings.
- lab/ - Experimental content (Warning: Not ratified; must not be referenced as authoritative in production PRs).