The theory corpus behind the instruments. Each page says what the paper is, what it means, how it functions, and its exact status. Status words are the document's own; none is upgraded here.
The working version of the protocol, PROPOSED and under owner review. Five guarantees, each with what it does and does not cover. STP v1.1 remains the formal baseline.
The formal baseline and the source of the five STP figures. One consequence path, from PROPOSE to CORRECT, with a separate receipt for each control function.
The plain-language blueprint. Keep only what is currently true, check new information against reality, and set aside what cannot be verified. Start here if you are new.
+
+
+
+
+
+
Figures
+
Select a figure to enlarge it. Every caption states what the figure shows and what it does not prove.
+
+
+
STP v1.1, Figure 1: One consequence path, separate receipts. The ten-stage consequence path, from PROPOSE to CORRECT, in which each control function emits its own receipt and a failed gate records a refusal and preserves the prior accepted projection. The diagram draws the forward path only; it does not show that any implementation follows it.
+
+
STP v1.1, Figure 2: State layers with distinct authority. World state is reached only through witness observations; observations, candidate state, and the accepted projection are kept as separate records. Reality is accessed through fallible witnesses, and the accepted projection remains scope-bound: it is not a claim about external truth.
+
+
STP v1.1, Figure 3: Causal order, commutative merge, explicit conflict. Disjoint writes may merge. Competing writes produce an explicit conflict: one write wins, and the other is rechecked against the new base. The figure illustrates the protocol's conflict rule; it does not show that any implementation loses no updates.
+
+
STP v1.1, Figure 4: Hysteresis and dwell time reduce mode chattering. Separate enter and exit thresholds, with a declared dwell time, reduce rapid switching between operating modes. The curve is illustrative and unitless, not measured data. It shows a smooth signal and does not show chattering being prevented on a noisy one.
+
+
STP v1.1, Figure 5: Zero trust applies to every role and adapter. No role, including the ledger operator and the authority service itself, bypasses the commit boundary. This is a design requirement drawn as a diagram; it does not show that any deployment enforces it.
+
+
V=IR: The alignment crosswalk (final, accepted 2026-09-14). V is authority, I is the flow of effects, and R is the gate, across five regimes from short circuit to open circuit. A crosswalk with a stated claim frame, read correspondence by correspondence, not an empirically validated law.
+
+
BespokeNode framework diagram. The permission-to-accepted-work lifecycle and its two safety states, HOLD and TRIP, each with a distinct recovery path. By the diagram's own notes, core features were tested with fixed workers; multi-node scenarios, parallel chains, and join gates are not yet validated.
+
+
Thetabase, page 1 of 5: Reuse useful work. Recheck access. Adapt between runs. The system flow: access check, compute or reuse, recheck, output, with offline profiling setting a fixed configuration for later runs. A design illustration from a design brief, not production evidence.
+
+
Thetabase, page 2 of 5: What gets optimized. Whole-job reuse by default, stage reuse only where measurements justify it, shown with a synthetic two-order example. The example shows the mechanism, not a performance result.
+
+
Thetabase, page 3 of 5: Adaptation is a measured decision. Replay, Compare, Configure: the configuration changes only offline, from recorded runs, and is then fixed for later requests. A design brief page, not production evidence. An optional research swarm is shown as extension design; it is not required and not evaluated here.
+
+
Thetabase, page 4 of 5: Reuse pays when preparation dominates. Local end-to-end timings on two workloads: whole-job caching was fastest on simple JSON reports, and hybrid stage reuse was fastest on repeated queries over one pinned HTML document. Local measurements, not production evidence; no general crossover point is claimed.
+
+
Thetabase, page 5 of 5: Use it. Measure it. Keep the receipts. Two reproduce commands and a five-line integration example in which the host supplies the access check. The kit the commands refer to is not published on this site, and the page states that its design influences do not establish novelty or production validation.
STP v1.1, Figure 1: One consequence path, separate receipts. The ten-stage consequence path, from PROPOSE to CORRECT, in which each control function emits its own receipt and a failed gate records a refusal and preserves the prior accepted projection. The diagram draws the forward path only; it does not show that any implementation follows it.
STP v1.1, Figure 2: State layers with distinct authority. World state is reached only through witness observations; observations, candidate state, and the accepted projection are kept as separate records. Reality is accessed through fallible witnesses, and the accepted projection remains scope-bound: it is not a claim about external truth.
STP v1.1, Figure 3: Causal order, commutative merge, explicit conflict. Disjoint writes may merge. Competing writes produce an explicit conflict: one write wins, and the other is rechecked against the new base. The figure illustrates the protocol's conflict rule; it does not show that any implementation loses no updates.
STP v1.1, Figure 4: Hysteresis and dwell time reduce mode chattering. Separate enter and exit thresholds, with a declared dwell time, reduce rapid switching between operating modes. The curve is illustrative and unitless, not measured data. It shows a smooth signal and does not show chattering being prevented on a noisy one.
STP v1.1, Figure 5: Zero trust applies to every role and adapter. No role, including the ledger operator and the authority service itself, bypasses the commit boundary. This is a design requirement drawn as a diagram; it does not show that any deployment enforces it.
V=IR: The alignment crosswalk (final, accepted 2026-09-14). V is authority, I is the flow of effects, and R is the gate, across five regimes from short circuit to open circuit. A crosswalk with a stated claim frame, read correspondence by correspondence, not an empirically validated law.
BespokeNode framework diagram. The permission-to-accepted-work lifecycle and its two safety states, HOLD and TRIP, each with a distinct recovery path. By the diagram's own notes, core features were tested with fixed workers; multi-node scenarios, parallel chains, and join gates are not yet validated.
Thetabase, page 1 of 5: Reuse useful work. Recheck access. Adapt between runs. The system flow: access check, compute or reuse, recheck, output, with offline profiling setting a fixed configuration for later runs. A design illustration from a design brief, not production evidence.
Thetabase, page 2 of 5: What gets optimized. Whole-job reuse by default, stage reuse only where measurements justify it, shown with a synthetic two-order example. The example shows the mechanism, not a performance result.
Thetabase, page 3 of 5: Adaptation is a measured decision. Replay, Compare, Configure: the configuration changes only offline, from recorded runs, and is then fixed for later requests. A design brief page, not production evidence. An optional research swarm is shown as extension design; it is not required and not evaluated here.
Thetabase, page 4 of 5: Reuse pays when preparation dominates. Local end-to-end timings on two workloads: whole-job caching was fastest on simple JSON reports, and hybrid stage reuse was fastest on repeated queries over one pinned HTML document. Local measurements, not production evidence; no general crossover point is claimed.
Thetabase, page 5 of 5: Use it. Measure it. Keep the receipts. Two reproduce commands and a five-line integration example in which the host supplies the access check. The kit the commands refer to is not published on this site, and the page states that its design influences do not establish novelty or production validation.
+
+
+
+
Find and understand
diff --git a/Paper-AI-Assisted-Work.html b/Paper-AI-Assisted-Work.html
new file mode 100644
index 0000000..4317000
--- /dev/null
+++ b/Paper-AI-Assisted-Work.html
@@ -0,0 +1,86 @@
+
+
+
+
+
+Delta Atlas - AI Assisted Work and Accepted State
+
+
+
+
+
+
+
+
+Skip to the paper
+
+
+
+
Protocols and papers
+
AI Assisted Work and Accepted State
+
The evidence review: what each part of the program has shown, what it has not, and the negative results kept.
+
Evidence review · 5 September 2026
+
+
Printed subtitle
Theory, evidence, limitations, and the next phase
Format
PDF, 14 pages
Date
5 September 2026
Preparation
Synthesis prepared with OpenAI Codex, as stated in the document
The review describes the work as an applied systems-engineering research program with working reference implementations, finite tests, and useful negative results, and as more developed than an idea alone.
+
Its strongest recurring contribution, in its own words, is explicit separation: proposal, permission, execution, effect, observation, acceptance, and later outcome have different meanings.
+
Their results should remain separate so a pass in one component cannot silently validate another.
Page 2
No claim here certifies universal safety, originality, or a positive return on spending.
Page 1
+
+
+
How it functions
+
Start here to check how mature each part is. A component table gives each part its own evidence boundary. An evidence table labels each result REPRODUCED (an existing offline check rerun for this review) or SOURCE CHECKED (a record inspected, the original experiment not rerun). A failures table lists recorded problems, what each teaches, and the response or next step, some still proposed.
+
+
+
Status and claim boundary
+
A targeted evidence review. Two items are REPRODUCED; the rest are SOURCE CHECKED. The results are finite local checks: for example, the State Runner result is one local single-writer run with no power-loss, concurrency, or production guarantee. The full Calibration Ledger lifecycle remains proposed.
+
In the review's own words, general cyber-defense effectiveness, physical stability, and economic superiority remain unestablished. The review made no paid provider calls and created no new model-efficacy result, and it notes that reviews by several AI agents are coordinated checks, not independent replication.
The work began as an efficiency hypothesis: pass compact context cards between model phases instead of full history. The experiments rejected that story.
+
The ledger records how that failure redirected the work toward a control plane in which a model output is only a proposal, and accepted state advances only after current evidence, exact lineage, verification, and human acceptance.
+
An unverified attempt can add evidence. It cannot silently replace the last accepted result.
Page 1
A local pass remains valuable at L1-L2 and must not be narrated as L4-L5.
Page 18
+
+
+
How it functions
+
Each claim area carries a status label (IMPLEMENTED, TESTED, PROPOSED, or UNKNOWN) and cites its source artifacts. The ledger maps five layers: Delta Atlas, Calibration Ledger plus STP, Clutch, BespokeNode, and State Runner. It grades evidence on claim levels from L0, a declared design, to L5, production assurance.
+
Use the review order on page 23: reproduce the local gate, inspect the finite predicate and its counterexamples, read the Clutch studies in order, and treat any claim above its cited ceiling as unestablished. The document calls itself an orientation and evidence map, not a substitute for the source artifacts or an independent reproduction.
+
+
+
Status and claim boundary
+
Cover-marked RESEARCH LEDGER | PRE-PUBLICATION | NOT PEER REVIEWED. Evidence reaches L1 (local conformance) and L2 (reproduction on one Windows host); L3 to L5 are UNKNOWN. The control-plane results come from declared fixtures, one local State Runner run, and one Windows clean-room attestation. The Clutch studies used synthetic tasks with billed provider calls.
+
The full ten-stage STP lifecycle remains PROPOSED. The ledger does not establish product efficacy, production safety, useful delivery on real projects, independent-team replication, cross-platform behavior, or general cost savings.
+
+
+
+
+
+
diff --git a/Paper-From-Model-Output.html b/Paper-From-Model-Output.html
new file mode 100644
index 0000000..6760649
--- /dev/null
+++ b/Paper-From-Model-Output.html
@@ -0,0 +1,87 @@
+
+
+
+
+
+Delta Atlas - From Model Output to Accepted State
+
+
+
+
+
+
+
+
+Skip to the paper
+
+
+
+
Protocols and papers
+
From Model Output to Accepted State
+
The working paper that proposes the State Transition Protocol as a typed boundary between model proposals and accepted state.
+
Working paper · owner-review draft v4
+
+
Printed subtitle
A typed state boundary for AI-assisted operations
Format
PDF, 36 pages
Date
15 August 2026
License
Intended for release under CC BY 4.0, as stated in the draft
A language model's output is a proposal. It is not an authorization, a completed action, an observation, or an accepted record of state.
+
The paper proposes keeping those records separate through a conceptual ten-stage lifecycle in which only a valid acceptance record advances governed state. It reports a reference implementation, contracts, reducers, and test harnesses that keep the records separate within the evaluated boundary, and that, used on one public software project, found real defects, including defects in the system itself.
+
A proposal is not an authorization, a completed action, an observation, or an accepted record of state.
Page 1
This is cross-language replay parity, not independent reproduction.
Page 1
+
+
+
How it functions
+
Each result-bearing claim carries one of four markers. TESTED means exact behavior over a named finite corpus, reproducible by a stated command. OBSERVED means a bounded inspection at a recorded time. PROPOSED means specified beyond the tested boundary, not a result. OPEN marks where the evidence stops.
+
Public case-study claims are bound to commit 275d0b3e7474 of this repository, and Appendix C lists full digests, exact locators, and the verification boundary for each artifact: public rows can be rehashed at that commit, while retained-source rows are not public inputs and cannot be checked from the repository. Section 11 states in one place what the work does not establish. The PDF here is the 15 August build of draft v4, 36 pages. A later 37-page build of the same draft, with an added related-work section, is under review in pull request 15.
+
+
+
Status and claim boundary
+
Working paper, owner-review draft v4, dated 15 August 2026. The draft states that it has no completed publication commitment. The ten-stage lifecycle is conceptual and PROPOSED; the public packet implements a narrower seven-event profile over synthetic fixtures and is not a complete implementation of that lifecycle.
+
Cross-language replay parity between JavaScript and Python ports is not independent reproduction. The 34 runner-reported numbered holds across twelve suites are a diagnostic inventory, not a coverage measure. The paper does not establish causation, lawful authority, regulatory compliance, statistical reliability, general safety, or independent validation.
+
+
+
+
+
+
diff --git a/Paper-STP-v1-1.html b/Paper-STP-v1-1.html
new file mode 100644
index 0000000..aaa2e2f
--- /dev/null
+++ b/Paper-STP-v1-1.html
@@ -0,0 +1,92 @@
+
+
+
+
+
+Delta Atlas - State Transition Protocol v1.1
+
+
+
+
+
+
+
+
+Skip to the paper
+
+
+
+
Protocols and papers
+
State Transition Protocol v1.1
+
The earlier version of the State Transition Protocol, the source of the five STP figures, and the formal baseline that the v1.2 candidate proposes to change.
+
Open source independent research · CC BY 4.0
+
+
Printed title
State Transition Protocol: a framework architecture for controlled state transitions in agentic systems
Format
PDF, 28 pages
Date
10 August 2026
Structure
14 numbered sections, Appendices A to C, Figures 1 to 5
A model can propose a change and a tool can apply it, but accepted state advances only through a declared projection rule after the required evidence, authority, observation, and conflict checks.
+
The protocol keeps world, observed, candidate, accepted, and desired state as separate records and gives each control function its own receipt. Its deterministic claim is narrow: identical valid events, ordering rules, schemas, and policy versions produce the same accepted projection.
+
Accepted state advances only through a declared projection rule after the required evidence, authority, observation, and conflict checks.
Page 1
Candidate synthesis. Literature convergence supports relevance. Evaluation and independent review remain required.
Page 2
+
+
+
How it functions
+
A consequential change is written as a typed delta and moves along one consequence path (Figure 1): PROPOSE, NORMALIZE, CHECK, AUTHORIZE, PREPARE, EXECUTE, OBSERVE, ACCEPT, OUTCOME, CORRECT. A failed gate records a refusal and preserves the prior accepted projection.
+
To check the design, use its 15 deterministic fixtures (F01 to F15), its falsification conditions, its enforcement levels from a review card to independent witnessing, and the 12 architecture decisions in Appendix C. The document's own fast path is Sections 2, 3, 4, 7, and 11.
+
+
+
Status and claim boundary
+
The printed status is Open source independent research, released for independent review and reproducible testing under CC BY 4.0. Appendix C marks its 12 architecture decisions (D01 to D12) as approved for version 1.1. The document calls its contribution a candidate synthesis that still needs evaluation and independent review.
+
It provides a control model, fixtures, and design targets. It reports no fixture results from an implementation, and it does not establish external truth, safe outcomes, witness quality, or legitimate authority; a deployment must supply those.
+
Version history: a v1.2 candidate (PROPOSED, owner review required) is the working version under owner review. STP v1.1 remains the current baseline until an owner receipt records a decision on v1.2.
Probabilistic systems may explore broadly. Deterministic, versioned gates control consequences. Independent observation records what happened, and append-only receipts preserve attempts and outcomes.
+
Consequential autonomy increases only when observation, settlement, and recovery capacity are measured in the same unit and remain within bound.
+
This is a proposal and research instrument, not a certification, deployment authorization, or accepted replacement for STP v1.1.
Candidate thesis
This proves agreement for those bytes and implementations. It does not prove schedule equivalence or semantic truth.
Section 6.1, Deterministic replay
+
+
+
How it functions
+
Read it to see exactly what each guarantee covers and where it stops. Section 6 states five separate guarantees: deterministic replay, schedule equivalence, invariant safety, effect safety, and liveness and fairness. Each one says what it establishes and what it does not.
+
The other sections set out the authority and claim boundary, a plain technical statement, formal objects and notation, the consequence path with a separate receipt for each phase, causal order and canonical replay, the pair and triple gate, exploration pressure against effect pressure with a per-lane backlog recurrence, a deterministic drift vector, neutral confidence, the optimizer and model authority ceiling, non-alias rules for adjacent systems, harness-neutral adapters, conformance evidence, the change record from v1.1, and the acceptance gates.
+
Appendix B lists each verification lane with what it establishes and what remains outside the claim. The public reproduction packet in this repository is a separate, minimized executable release from the same v1.2 research: it runs synthetic cases in JavaScript and Python, overlaps this document on concurrency and effect finality, adds profiles this document does not contain, and is not the complete draft.
+
+
+
Status and claim boundary
+
Working version, under owner review. The document's own control block reads PROPOSED; owner review required, and its baseline line reads STP v1.1 remains current; no silent supersession. Formal acceptance waits on the acceptance gates in section 16, ending in an append-only owner receipt (ACCEPT, ACCEPT_WITH_LIMITS, DEFER, REJECT, or SUPERSEDE). Until that receipt exists, the correct state is PROPOSED, and STP v1.1 remains the formal baseline.
+
Its evidence is a dual JavaScript and Python harness over synthetic fixtures. Passing those fixtures shows agreement for the enumerated synthetic records only. It does not establish all deltas, all schedules, live external effects, global confluence, fairness, or semantic truth. In Appendix B, termination is UNKNOWN and Ledger identity is BLOCKING.
The blueprint argues that AI reliability is a structural problem, not a model-size problem. Its core image is a librarian who keeps only what reflects what is currently true, checks new information against reality, and sets aside what cannot be verified instead of adding it to the pile.
+
It is written so that engineers, administrators, family members, and students can read the same pages.
+
If it does, update. If it does not, set it aside instead of adding it to the pile.
Page 2
If either gate fails, the system activates its Refusal Logic. This is a hard stop. It is not an AI decision.
Page 3
+
+
+
How it functions
+
Read it first if you are new to this work. It moves from the problem and the core idea to the architecture: a flexible reasoning layer, a fixed local Harness, and small structured records called State-Deltas passing between them. Each proposed change must pass an Ontology Gate and a Semantics Gate before it is written to an append-only Truth Ledger.
+
Five protocols, plus a set of definitions each given in technical, plain, and bridge form, give readers a shared vocabulary. Worked examples cover education, personal health, infrastructure, and enterprise compliance, and the last part gives separate guidance for engineers, administrators, affected people, and students.
+
+
+
Status and claim boundary
+
A blueprint and, in its own words, one synthesis among many. It states that it is not finished work. It contains no implementation, tests, or measured results, so the benefits described in its examples are design intentions, not demonstrated outcomes.
+
It notes that its parts (sandboxes, validation gates, append-only ledgers, schema validation) are established ideas; what it offers is their synthesis applied to agentic AI. The State-Delta Architecture page on this site walks the BespokeNode specification, which draws on this blueprint.
+
+
+
+
+
+
diff --git a/Paper-Thetabase.html b/Paper-Thetabase.html
new file mode 100644
index 0000000..59c34d9
--- /dev/null
+++ b/Paper-Thetabase.html
@@ -0,0 +1,91 @@
+
+
+
+
+
+Delta Atlas - Thetabase
+
+
+
+
+
+
+
+
+Skip to the paper
+
+
+
+
Protocols and papers
+
Thetabase
+
A five-page design brief for a standalone JSON caching library that reuses saved work and rechecks access before returning it.
+
Design brief · local runs, not production
+
+
Printed title
Thetabase: Reuse useful work. Recheck access. Adapt between runs.
Format
PDF, 5 pages
Date
September 2026
What is published
The design brief only. The library code and reproduction kit are not published here.
Saved work can be reused, but a saved result never carries permission with it: the host's access check runs again on each request.
+
The design starts with whole-job caching and adds reuse of intermediate stages only where measurements justify it. Which strategy to use is decided offline from recorded runs, then fixed for later requests, so the live path stays simple.
+
Saved computation never saves permission.
Page 2
Start with complete-result caching. Add reusable stages only where the measurements justify them.
Page 2
+
+
+
How it functions
+
The brief walks the pipeline (input, access check, compute or reuse, recheck, output), the two caching levels, and a Replay, Compare, Configure loop for choosing a strategy offline. Its rule is that reuse must save more compute than it costs in lookup, copying, and profiling.
+
Page 5 shows two reproduce commands and a five-line Python integration example in which the host supplies the access check. The commands refer to a separate kit that holds the library, reproduce.py, raw timings, and hashes. That kit is not published here, so this page offers the design and the reported figures, not runnable code.
+
+
+
Status and claim boundary
+
A design brief describing a prototype. Its measurements are local end-to-end runs, not production traffic. On repeated queries over one unchanged HTML page, hybrid stage reuse took 1.58 seconds against 9.62 for whole-job caching, which the brief reports as 84% less execution time. On simple JSON reports, whole-job caching was faster (3.21 seconds against 4.94 for hybrid), and on a cold single query hybrid was 7% slower.
+
Data boundary, in the brief's own terms: deterministic JSON with safe integers only; floats are rejected, and float and vector support is future adapter work. No universal crossover threshold is claimed, and the brief states that its design influences do not establish novelty or production validation.
+
+
+
+
+
+
diff --git a/Paper-Which-Labels.html b/Paper-Which-Labels.html
new file mode 100644
index 0000000..8aa55bf
--- /dev/null
+++ b/Paper-Which-Labels.html
@@ -0,0 +1,88 @@
+
+
+
+
+
+Delta Atlas - Which labels an AI actually uses on its own work
+
+
+
+
+
+
+
+
+Skip to the paper
+
+
+
+
Protocols and papers
+
Which labels an AI actually uses on its own work
+
The note behind Pin-Check: a count of which self-assessment labels a model actually used on its own analysis.
+
Small measured experiment · one model family
+
+
Printed header
Pin-Check skill, August 2026
Format
PDF, 3 pages
Date
August 2026
Scope
118 labelled decisions across four experiments and two labelling systems, one model family
A model was given problems that state their own answer and asked to label each piece of its analysis, including with a label meaning "this added nothing". That label was correct for every piece, and in the first run it was never used. After stricter written tests were added, it rose from one case to two.
+
Across 118 labelled decisions, the two easiest labels took 75 to 100% of the share and the strongest "this is wrong" labels took 0 to 2%. Every label the model chose was defensible; it kept choosing the ones that were easiest to defend.
+
On a problem that contains its own answer, that label is correct for every piece. It was never used once.
Page 1
I changed three things in that round, so the shift is measured but the cause is not isolated.
Page 2
+
+
+
How it functions
+
Run the ten-minute check on any labelling scheme you already use. Give it something that states its own answer, so the "nothing here" label is the correct one, and count how often it says so. The note says this tells you whether your labels are controls or decoration.
+
The note then points to Pin-Check, which replaces a judgement with a computation: it reports each precise number in a document as traced, rounded, or currently undefined, deciding by hashing files and comparing bytes. Pin-Check ships in this repository under skills/pin-check.
+
The PDF points readers to a full record at research/label-absorption-note in this repository. That record is not yet on the main branch, so it cannot be reached from this site.
+
+
+
Status and claim boundary
+
A small measured experiment on one model family. The document gives itself no formal status word. When the label tests were tightened, the traffic moved to the next-easiest label rather than to the correct one; three things changed in that round, so the note says the cause is not isolated.
+
A second finding, splitting one paragraph into claims (14, then 8, then 10 across three runs), comes from one system and one paragraph. The note does not show that other models or model families behave the same way.
+
+
+
+
+
+
diff --git a/assets/figures/bespokenode-diagram.png b/assets/figures/bespokenode-diagram.png
new file mode 100644
index 0000000..d8548a1
Binary files /dev/null and b/assets/figures/bespokenode-diagram.png differ
diff --git a/assets/figures/stp-fig1-consequence-path.png b/assets/figures/stp-fig1-consequence-path.png
new file mode 100644
index 0000000..b9ba4ff
Binary files /dev/null and b/assets/figures/stp-fig1-consequence-path.png differ
diff --git a/assets/figures/stp-fig2-state-layers.png b/assets/figures/stp-fig2-state-layers.png
new file mode 100644
index 0000000..1011c45
Binary files /dev/null and b/assets/figures/stp-fig2-state-layers.png differ
diff --git a/assets/figures/stp-fig3-causal-merge-conflict.png b/assets/figures/stp-fig3-causal-merge-conflict.png
new file mode 100644
index 0000000..a38c184
Binary files /dev/null and b/assets/figures/stp-fig3-causal-merge-conflict.png differ
diff --git a/assets/figures/stp-fig4-hysteresis.png b/assets/figures/stp-fig4-hysteresis.png
new file mode 100644
index 0000000..7008eeb
Binary files /dev/null and b/assets/figures/stp-fig4-hysteresis.png differ
diff --git a/assets/figures/stp-fig5-zero-trust.png b/assets/figures/stp-fig5-zero-trust.png
new file mode 100644
index 0000000..131d279
Binary files /dev/null and b/assets/figures/stp-fig5-zero-trust.png differ
diff --git a/assets/figures/thetabase-p1.png b/assets/figures/thetabase-p1.png
new file mode 100644
index 0000000..3f5ebc9
Binary files /dev/null and b/assets/figures/thetabase-p1.png differ
diff --git a/assets/figures/thetabase-p2.png b/assets/figures/thetabase-p2.png
new file mode 100644
index 0000000..2aa24d4
Binary files /dev/null and b/assets/figures/thetabase-p2.png differ
diff --git a/assets/figures/thetabase-p3.png b/assets/figures/thetabase-p3.png
new file mode 100644
index 0000000..28edb59
Binary files /dev/null and b/assets/figures/thetabase-p3.png differ
diff --git a/assets/figures/thetabase-p4.png b/assets/figures/thetabase-p4.png
new file mode 100644
index 0000000..52b99b2
Binary files /dev/null and b/assets/figures/thetabase-p4.png differ
diff --git a/assets/figures/thetabase-p5.png b/assets/figures/thetabase-p5.png
new file mode 100644
index 0000000..57d39a5
Binary files /dev/null and b/assets/figures/thetabase-p5.png differ
diff --git a/assets/figures/thumbs/bespokenode-diagram.webp b/assets/figures/thumbs/bespokenode-diagram.webp
new file mode 100644
index 0000000..352c3fe
Binary files /dev/null and b/assets/figures/thumbs/bespokenode-diagram.webp differ
diff --git a/assets/figures/thumbs/stp-fig1-consequence-path.webp b/assets/figures/thumbs/stp-fig1-consequence-path.webp
new file mode 100644
index 0000000..391f396
Binary files /dev/null and b/assets/figures/thumbs/stp-fig1-consequence-path.webp differ
diff --git a/assets/figures/thumbs/stp-fig2-state-layers.webp b/assets/figures/thumbs/stp-fig2-state-layers.webp
new file mode 100644
index 0000000..c789b62
Binary files /dev/null and b/assets/figures/thumbs/stp-fig2-state-layers.webp differ
diff --git a/assets/figures/thumbs/stp-fig3-causal-merge-conflict.webp b/assets/figures/thumbs/stp-fig3-causal-merge-conflict.webp
new file mode 100644
index 0000000..c6071c9
Binary files /dev/null and b/assets/figures/thumbs/stp-fig3-causal-merge-conflict.webp differ
diff --git a/assets/figures/thumbs/stp-fig4-hysteresis.webp b/assets/figures/thumbs/stp-fig4-hysteresis.webp
new file mode 100644
index 0000000..cd5fdd1
Binary files /dev/null and b/assets/figures/thumbs/stp-fig4-hysteresis.webp differ
diff --git a/assets/figures/thumbs/stp-fig5-zero-trust.webp b/assets/figures/thumbs/stp-fig5-zero-trust.webp
new file mode 100644
index 0000000..4f56260
Binary files /dev/null and b/assets/figures/thumbs/stp-fig5-zero-trust.webp differ
diff --git a/assets/figures/thumbs/thetabase-p1.webp b/assets/figures/thumbs/thetabase-p1.webp
new file mode 100644
index 0000000..0a58562
Binary files /dev/null and b/assets/figures/thumbs/thetabase-p1.webp differ
diff --git a/assets/figures/thumbs/thetabase-p2.webp b/assets/figures/thumbs/thetabase-p2.webp
new file mode 100644
index 0000000..cc0228f
Binary files /dev/null and b/assets/figures/thumbs/thetabase-p2.webp differ
diff --git a/assets/figures/thumbs/thetabase-p3.webp b/assets/figures/thumbs/thetabase-p3.webp
new file mode 100644
index 0000000..af0ffa2
Binary files /dev/null and b/assets/figures/thumbs/thetabase-p3.webp differ
diff --git a/assets/figures/thumbs/thetabase-p4.webp b/assets/figures/thumbs/thetabase-p4.webp
new file mode 100644
index 0000000..ae5aa1b
Binary files /dev/null and b/assets/figures/thumbs/thetabase-p4.webp differ
diff --git a/assets/figures/thumbs/thetabase-p5.webp b/assets/figures/thumbs/thetabase-p5.webp
new file mode 100644
index 0000000..5c5fe3e
Binary files /dev/null and b/assets/figures/thumbs/thetabase-p5.webp differ
diff --git a/assets/figures/thumbs/vir-crosswalk-final.webp b/assets/figures/thumbs/vir-crosswalk-final.webp
new file mode 100644
index 0000000..8984b2e
Binary files /dev/null and b/assets/figures/thumbs/vir-crosswalk-final.webp differ
diff --git a/assets/figures/vir-crosswalk-final.png b/assets/figures/vir-crosswalk-final.png
new file mode 100644
index 0000000..dc6e76b
Binary files /dev/null and b/assets/figures/vir-crosswalk-final.png differ
diff --git a/assets/papers/ai-work-accepted-state.pdf b/assets/papers/ai-work-accepted-state.pdf
new file mode 100644
index 0000000..b683fd0
Binary files /dev/null and b/assets/papers/ai-work-accepted-state.pdf differ
diff --git a/assets/papers/calibration-ledger-v9.pdf b/assets/papers/calibration-ledger-v9.pdf
new file mode 100644
index 0000000..e0a209e
Binary files /dev/null and b/assets/papers/calibration-ledger-v9.pdf differ
diff --git a/assets/papers/from-model-output-to-accepted-state.pdf b/assets/papers/from-model-output-to-accepted-state.pdf
new file mode 100644
index 0000000..814823c
Binary files /dev/null and b/assets/papers/from-model-output-to-accepted-state.pdf differ
diff --git a/assets/papers/state-delta-architecture-3.0.pdf b/assets/papers/state-delta-architecture-3.0.pdf
new file mode 100644
index 0000000..6944cd3
Binary files /dev/null and b/assets/papers/state-delta-architecture-3.0.pdf differ
diff --git a/assets/papers/stp-v1.1.pdf b/assets/papers/stp-v1.1.pdf
new file mode 100644
index 0000000..20fa58f
Binary files /dev/null and b/assets/papers/stp-v1.1.pdf differ
diff --git a/assets/papers/stp-v1.2-candidate.docx b/assets/papers/stp-v1.2-candidate.docx
new file mode 100644
index 0000000..6ae0be1
Binary files /dev/null and b/assets/papers/stp-v1.2-candidate.docx differ
diff --git a/assets/papers/thetabase.pdf b/assets/papers/thetabase.pdf
new file mode 100644
index 0000000..e911f4b
Binary files /dev/null and b/assets/papers/thetabase.pdf differ
diff --git a/assets/papers/which-labels-an-ai-actually-uses.pdf b/assets/papers/which-labels-an-ai-actually-uses.pdf
new file mode 100644
index 0000000..2c812a2
Binary files /dev/null and b/assets/papers/which-labels-an-ai-actually-uses.pdf differ
diff --git a/governance/harnesses/run-all.js b/governance/harnesses/run-all.js
index 01f3f49..b4b79d5 100644
--- a/governance/harnesses/run-all.js
+++ b/governance/harnesses/run-all.js
@@ -17,6 +17,7 @@ const scripts = [
'verify-public-explanation-surfaces.js',
'verify-atlas-foundational-repair.js',
'verify-six-signal-surface.js',
+ 'verify-portfolio-surface.js',
'verify-authority.js',
'authority-falsification.js',
'falsification.js',
diff --git a/governance/harnesses/verify-portfolio-surface.js b/governance/harnesses/verify-portfolio-surface.js
new file mode 100644
index 0000000..2286452
--- /dev/null
+++ b/governance/harnesses/verify-portfolio-surface.js
@@ -0,0 +1,202 @@
+#!/usr/bin/env node
+'use strict';
+
+/* Deterministic, no-network checks for the research portfolio added on 2026-09-25:
+ the eight paper pages, the Library "Protocols and papers" and "Figures" sections,
+ and the home-page link strip. Status words are load-bearing: each page, card, and
+ strip line must keep the document's own status and claim boundary, and none may
+ be upgraded. Mutation canaries at the end prove each guard bites. */
+const fs = require('fs');
+const path = require('path');
+const root = path.resolve(__dirname, '..', '..');
+const read = (file) => fs.readFileSync(path.join(root, file), 'utf8');
+const exists = (file) => fs.existsSync(path.join(root, file));
+
+const PAPERS = [
+ { page: 'Paper-STP-v1-2.html', file: 'assets/papers/stp-v1.2-candidate.docx',
+ chip: 'PROPOSED · owner review required', card: [/PROPOSED/, /owner review/, /formal baseline/],
+ must: [/PROPOSED; owner review required/, /STP v1\.1 remains current; no silent supersession/, /acceptance gates in section 16/,
+ /append-only owner receipt/, /STP v1\.1 remains the formal baseline/, /termination is UNKNOWN and Ledger identity is BLOCKING/,
+ /synthetic fixtures/, /not the complete draft/],
+ mustNot: [/\bv1\.2\b[^.<]{0,60}\b(?:is|was|has been) (?:formally )?accepted\b/i, /\bsupersedes STP v1\.1\b/i, /formal protocol/i] },
+ { page: 'Paper-STP-v1-1.html', file: 'assets/papers/stp-v1.1.pdf',
+ chip: 'Open source independent research · CC BY 4.0', card: [/formal baseline/],
+ must: [/Open source independent research/, /candidate synthesis/,
+ /STP v1\.1 remains the current baseline until an owner receipt records a decision on v1\.2/, /does not establish external truth/],
+ mustNot: [/\bsuperseded\b/i] },
+ { page: 'Paper-Thetabase.html', file: 'assets/papers/thetabase.pdf',
+ chip: 'Design brief · local runs, not production', card: [/design brief/i, /not production/i],
+ must: [/not production traffic/, /not published here/, /whole-job caching was faster/, /No universal crossover threshold is claimed/,
+ /do not establish novelty or production validation/],
+ mustNot: [/cache aggressively/i] },
+ { page: 'Paper-Calibration-Ledger-v9.html', file: 'assets/papers/calibration-ledger-v9.pdf',
+ chip: 'Research ledger · pre-publication · not peer reviewed', card: [/IMPLEMENTED, TESTED, PROPOSED, or UNKNOWN/],
+ must: [/RESEARCH LEDGER \| PRE-PUBLICATION \| NOT PEER REVIEWED/, /L3 to L5 are UNKNOWN/, /IMPLEMENTED, TESTED, PROPOSED, or UNKNOWN/,
+ /does not establish product efficacy, production safety/],
+ mustNot: [/lab notebook/i] },
+ { page: 'Paper-Which-Labels.html', file: 'assets/papers/which-labels-an-ai-actually-uses.pdf',
+ chip: 'Small measured experiment · one model family', card: [/first run/],
+ must: [/one model family/, /in the first run it was never used/, /rose from one case to two/, /cause is not isolated/,
+ /does not show that other models or model families behave the same way/, /not yet on the main branch/],
+ mustNot: [/\bmodels pick\b/i, /universal/i, /never used across/i] },
+ { page: 'Paper-AI-Assisted-Work.html', file: 'assets/papers/ai-work-accepted-state.pdf',
+ chip: 'Evidence review · 5 September 2026', card: [/evidence review/i, /Negative results are retained/],
+ must: [/REPRODUCED/, /SOURCE CHECKED/, /remain unestablished/, /not independent replication/, /prepared with OpenAI Codex/],
+ mustNot: [/has proved/i] },
+ { page: 'Paper-From-Model-Output.html', file: 'assets/papers/from-model-output-to-accepted-state.pdf',
+ chip: 'Working paper · owner-review draft v4', card: [/owner-review draft v4/],
+ must: [/owner-review draft v4/, /no completed publication commitment/, /\bTESTED\b[\s\S]*\bOBSERVED\b[\s\S]*\bPROPOSED\b[\s\S]*\bOPEN\b/,
+ /not independent reproduction/, /diagnostic inventory, not a coverage measure/, /Intended for release under CC BY 4\.0/,
+ /used on one public software project/, /later 37-page build/],
+ mustNot: [/citable/i, /tagged PROPOSED or TESTED/i] },
+ { page: 'Paper-State-Delta-Architecture-v3.html', file: 'assets/papers/state-delta-architecture-3.0.pdf',
+ chip: 'Blueprint · not a tested implementation', card: [/blueprint/i],
+ must: [/not finished work/, /design intentions, not demonstrated outcomes/, /No date printed/],
+ mustNot: [/(? /\bACCEPTED\b/.test(t) || UPGRADE_WORDS.test(t) }; // ACCEPTED is a status token; 'Accepted State' in a title is not
+const UNPUBLISHED = /\b(?:30%|70%|50%|20%|90%|100\/100|16 vignettes|55 alarms|56 frozen prompts|50 crude-hint|GT-[0-9]+\b|MED v2|Track [CM]\b|zero false alarms|false alarms?|premise and honest|honest runs|substantive disagreements|denaturation|crosstalk|vignettes?|MRI)/i;
+const decode = (s) => s.replace(/·/g, '·').replace(/"/g, '"').replace(/'|'/g, "'").replace(/&/g, '&');
+const visible = (source) => decode(source.replace(//gi, '').replace(//gi, '').replace(/<[^>]+>/g, ' ')).replace(/\s+/g, ' ').trim();
+
+function failuresFor(surfaces) {
+ const f = [];
+ const need = (condition, message) => { if (!condition) f.push(message); };
+
+ for (const paper of PAPERS) {
+ const html = surfaces[paper.page];
+ if (html === undefined) { f.push(`${paper.page}: page is missing`); continue; }
+ const text = visible(html);
+ need(exists(paper.file), `${paper.file}: paper file is missing`);
+ need(html.includes(`href="${paper.file}"`), `${paper.page}: does not link its paper file`);
+ need((html.match(/]*>${heading}`).test(html), `${paper.page}: missing section "${heading}"`);
+ }
+ const chip = decode((html.match(/
+
+
+
+
+
+
+
+
+
+
+
+