AI said “done.” Can the next chat actually continue?
Paste this into the same AI session:
Create an OSI Restart Note for the work above.
Use only inspectable evidence.
Do not treat your own completion claim as proof.
Write MISSING or UNKNOWN when evidence is unavailable.
Return only:
- What changed
- What is still unresolved
- Where to restart
- Next action and proposed owner
Paste the result into the next chat.
This creates a restart note. It does not prove that the work occurred.
Full completion and handoff check →
AI says “done,” but you still have to reconstruct what changed, what is missing, and where to continue.
If every new chat makes you re-explain the same work, you are paying the recovery cost again.
Save this prompt for every consequential AI “done” report. Share the Restart Note whenever a new chat, agent, or teammate has to continue without guessing.
Long-running human–AI work often creates the same restart costs repeatedly:
- A new AI needs the same project explanation again.
- The agent says “done,” but you still have to verify and clean up.
- The reason behind an earlier decision disappears with the previous chat.
- A handoff transfers information but creates more work.
- Nobody can tell what was actually checked, what remains unresolved, or where to restart.
- Adding more agents makes you carry more project state, not less.
Measured result, scale readiness, and advanced layers
The previous AI may have produced an output without leaving a completion state that the next human or AI can safely accept, verify, roll back, and continue.
That is False Completion: the work looks finished locally while missing evidence, unresolved state, and ownership are transferred downstream.
OSI compacts the continuation surface: the bounded outcome, evidence required for the next judgment, unresolved state, authority, rollback or restart point, and next owner.
It is designed to reduce repeated explanation and recovery without discarding the state needed to restart safely. It is not designed to make every isolated turn shorter, and the fixed internal result documented in the advanced section below is not a universal performance estimate.
When the required state is preserved, OSI prevents repeated reconstruction by shifting work from repeated recovery to bounded one-time recording. This is an operating mechanism, not an experimentally measured saving.
| Without OSI | With OSI |
|---|---|
| AI says “done” | Exact output is frozen |
| Evidence is incomplete | Evidence and procedure are recorded |
| The next session reconstructs state | Restart state is inherited |
| Verification is repeated | Prior verification remains inspectable |
| Ownership is unclear | The next action and proposed owner are visible |
| Mistakes create repair work | Missing Closure blocks unsafe continuation |
OSI pays a bounded integrity cost once. Missing completion state may otherwise be paid for repeatedly by every later human, model, session, or agent.
This is an operating mechanism, not a published percentage effect.
Long project history
14,651 characters across eight fixed internal cases
↓ OSI
Compact restart surface
3,267 characters
↓
77.70% fewer characters
192 / 192 registered restart items retained in scoring
In one fixed internal eight-case evaluation, restart material was reduced from 14,651 to 3,267 characters — a 77.70% character reduction — while retaining 192 / 192 registered restart items in scoring. The complete public reproduction package for this internal evaluation is not currently included in the repository.
The compact restart surface preserves the answers needed for bounded continuation:
- What changed?
- What remains unresolved?
- Where should work restart?
- Who is proposed to own the next action?
A new human or AI can continue from the bounded operational state instead of reconstructing the entire project history.
If responsibility transfer is claimed, naming a proposed owner is not enough: the receiver's acceptance, acknowledgement evidence, and timestamp must also be recorded.
Your current workflow may already be strong.
Before changing anything, ask your own AI whether adding more projects, agents, handoffs, collaborators, and model changes is likely to amplify useful structure, amplify recovery cost, or remain unknown from the available history.
Run the Scale Readiness check →
You do not need to understand OSI first. Use an AI session that already has access to your real work history. If the available history does not support a direction, the result should remain UNKNOWN.
Run the one-minute restart check →
Illustrative Level 1 example — not part of the measured eight-case result.
Before
Done. The repository was updated and tests passed.
This does not reveal the changed surface, evidence, unresolved state, restart point, or next owner.
After
- Output reference:
PATCH-001 - Changed surface:
src/parser.ts;tests/parser.test.ts - Validation receipt:
RECEIPT-001— illustrative identifier, not inspectable here - Authority source: illustrative Level 1 acceptance policy, not supplied here
- Missing closure: inspectable artifact, command/output/status, authority source, and receiver acceptance
- Restart point: state immediately before
PATCH-001 - Next action: inspect the evidence before accepting the bounded parser maintenance change
- Responsibility transfer: claimed in this walkthrough
- Proposed next owner: receiving maintainer
- Receiver acceptance:
NOT RECORDED— acknowledgement and timestamp missing - Example status:
ILLUSTRATIVE - Gate:
DELAY — NOT VERIFIED
For a stronger completion check, continue to the full five-minute workflow and template.
No installation, blind evaluation, Gold, Mapping, or multi-agent setup is required for the Level 1 workflow.
This result is limited to the fixed internal eight-case evaluation. It does not establish a general token-reduction rate, general time savings, equivalent effects in external environments, market demand, or superiority over other context-transfer methods.
OSI's supporting layers follow this order:
- V11 — Reconnectability: retain the operational state required for restart and connect it to its origin, As-of condition, stop condition, and rollback or re-entry path.
- V12 — Completion Integrity: prevent false completion and responsibility loss by preserving evidence, authority, ownership, unresolved state, and bounded acceptance.
- V13 — Next-Loop Governance: fix the next safe action, next owner, and conditions for re-entry.
V11, V12, and V13 support the restart-oriented compression method. They do not make restart automatic or establish universal reliability.
Done. The repository was updated and the tests passed.
- exact changed paths are absent;
- the test command and execution receipt are absent;
- the rollback or restart point is absent;
- unresolved assumptions are hidden; and
- the next safe action and owner are absent.
DELAY
The semantic claim may be correct, but receipt and completion integrity are not yet sufficient to accept “done.”
Closure would require a stable output reference, the exact changed paths, the actual validation command and result, the named authority source, any required independent closure state, unresolved assumptions, a rollback/restart point, and a proposed owner for the next safe action. If completed handoff is claimed, the receiver's acceptance evidence is also required.
Without that record, the next session must rediscover the state. With it, the next human or AI can inspect the missing closure and resume at the bounded action without pretending the change failed.
See the illustrative Level 1 walkthrough.
OSI separates an answer from the state required to accept, transfer, audit, or resume it.
| Integrity surface | Question it answers |
|---|---|
| Semantic outcome | What did the AI conclude, including uncertainty? |
| Output identity | Which exact response, patch, commit, file, or artifact is being evaluated? |
| Evidence / receipt integrity | Which executions and validations have inspectable results? |
| Procedure integrity | Were the required steps, ordering, and boundaries followed? |
| Authority | Who was allowed to perform or approve the action? |
| Witness state | Was independent fixation required, and was it completed? |
| Unresolved items | What remains unknown, missing, or contradictory? |
| Rollback / restart point | Where can work be reversed or safely resumed? |
| Proposed next owner | Who is proposed for the next bounded action or judgment? |
| Receiver acceptance | If responsibility transfer is claimed, did the receiver accept, and what acknowledgement and timestamp prove it? |
| Gate | Is bounded acceptance PASS, DELAY, or BLOCK? |
The difference is:
The AI produced an answer.
versus:
This exact output was produced under this authority, with this evidence, these unresolved items, this Witness state, and this safe continuation path.
As AI work becomes more autonomous and complex, what will serve as the basis for trusting that the work is actually complete?
OSI does not ask you to trust fluent output, model confidence, model reputation, the author's credentials, or an unverified “done” report. It asks you to inspect:
- exact artifact identity;
- evidence and execution receipts;
- procedure and authority;
- Witness or independent closure state;
- unresolved items;
- rollback or restart point; and
- the next action and owner.
That record does not guarantee that a conclusion is true. It makes the acceptance basis visible, makes missing closure explicit, and gives the next human or AI a bounded place to continue.
OSI does not make trust automatic. It makes trust inspectable.
The integrity record is created once. Without it, every new chat, model, agent, or maintainer may inherit the same missing context and repeat the same search, verification, explanation, and coordination work.
A slightly slower close can therefore be cheaper than repeated recovery. Preserving state also limits unsafe momentum: when evidence, authority, ownership, or the restart point is absent, the Gate can stop continuation before an omission compounds into broader repair work.
This is the project's long-run cost hypothesis and operating rationale. Comparative total-workflow savings have not yet been measured.
| Reported field | Recorded value |
|---|---|
| Runtime executions | 18 / 18 |
| Witness fixations | 18 / 18 |
| Primary Evaluator evaluations | exactly 1 |
| Evaluated B-IDs | 18 / 18 |
| PE rerun / replacement | 0 / 0 |
| Gold / Mapping access before Ledger freeze | 0 / 0 |
| Runtime / Ledger modification | 0 / 0 |
| Later V11+V12 validator-side result | 7 PASS / 1 DELAY / 0 BLOCK |
These are reported Formal Run counts, not independently reproducible facts from this public repository. The public repository records the values and terminal chronology but does not include all source preimages, custody artifacts, manifests, or identity bindings needed to reproduce them. They are not efficiency effect sizes.
| Fixed corpus | Full | Compact | Saved | Recorded reduction | n |
|---|---|---|---|---|---|
| Candidate reports | 14,651 characters |
3,267 |
11,384 |
77.70% |
8 |
| Synthetic adversarial reports | 24,711 characters |
10,763 |
13,948 |
56.44% |
8 |
These are recorded character-count results for two fixed internal runs. The candidate result includes recorded scoring of 192 / 192; the synthetic row records packet-build totals, while its cold-start scoring assertions remain pending and must not be presented as completed. The complete public corpus, registry, scoring rows, processor, and counting rules are not included here. These are not token, time, total-cost, handoff, safety, or external-performance measurements. See the Claim Boundary, registered measured facts, and native-domain protocol.
- percentage token or elapsed-time reduction;
- percentage self-verification or correction-loop reduction;
- re-onboarding time, handoff success rate, or human monitoring reduction;
- comparative productivity or accuracy gain;
- deployment safety or general real-world performance;
- comparative market demand;
- total continuation cost or a comparative effect against RTK;
- Blind Evaluation of the later
7 PASS / 1 DELAY / 0 BLOCKresult; - Primary rubric scoring of that later result; and
- the FR-v0.2.1-01 final blind score.
| Category | Current boundary |
|---|---|
| RECORDED INTERNAL RESULT | Fixed internal eight-case character reduction of 77.70%.192 / 192 registered items retained in scoring.The arithmetic and recorded values are public; the complete reproduction package is not. |
| NOT ESTABLISHED | General token reduction. General time reduction. Equivalent effects in external environments. Market demand. RTK superiority. Universal handoff reliability. |
| PROHIBITED | Reopening or retrospectively repairing FR-v0.2.1-01. Rewriting private evidence chronology. Presenting Scientific Missing Closure as resolved. Converting lack of external response into demand rejection. |
The repository also preserves adverse historical evidence. In an earlier fixed native-domain comparison, RTK produced the correct registered bounded state at Execution Stage 2 in 8 / 8 cases; OSI Responsibility Stage 2 produced the correct bounded state in 1 / 8, with 14 critical failure events across 7 cases.
The lanes used different native artifacts and rubrics, so these figures are not a winner score and do not establish responsibility equivalence or total continuation cost. They do pressure a blanket “OSI by default” claim. See the registered measured facts and native-domain protocol.
The 1 / 8 result remains a valid As-of finding; it was not treated as a stable limit of OSI or rewritten after the fact. Shin identified the missing joint as V11 Reconnectability: Responsibility Surface control alone did not preserve all conditions needed to reconnect judgment-critical state to its origin, stop condition, and rollback/re-entry path.
A later preregistered Compound Gate v0.2 added:
- Gate A: V11 Reconnectability Gate; and
- Gate B: V12 Responsibility Surface Gate.
The registered validator-side Compound Gate for attempt_02 produced:
- PASS:
7 / 8; - DELAY:
1 / 8; and - BLOCK:
0 / 8.
R07 remained DELAY because the permitted evidence did not supply the required rollback/re-entry trigger or re-evaluation conditions. Those conditions were not retrospectively invented to force PASS.
This is substantial Forward-only architectural recovery from the earlier 1 / 8 result. It is not evidence of complete 8 / 8 recovery: Blind Evaluation was NOT RUN, Primary rubric scoring was NOT RUN, and no comparative effect size, main empirical Claim confirmation, or RTK superiority is claimed.
| Output | Plain meaning |
|---|---|
| Semantic outcome | What the AI or Runtime concluded, including uncertainty. |
| Receipt integrity | Whether claimed execution and validation have inspectable evidence. |
| Procedure integrity | Whether authorized steps, ordering, and boundaries were followed. |
| Witness state | Whether independent fixation was required and completed. |
| Gate | PASS, DELAY, or BLOCK. |
| Missing Closure | What still prevents bounded acceptance. |
| Next safe action | The bounded point where work may continue or restart. |
| Proposed next owner | The human, agent, or role proposed for that action or judgment. |
| Receiver acceptance | For a claimed responsibility transfer: acceptance status, acknowledgement evidence, and timestamp. |
PASSrequires an inspectable artifact identity, inspectable receipt or execution evidence, actual command/output/status when execution is claimed, a named authority source, no unresolved blocker, and receiver acceptance when responsibility transfer is claimed. Plausible identifiers alone are insufficient. It is not proof of truth.DELAYmeans closure may be reachable after specified evidence or verification is obtained; it is not failure.BLOCKmeans accepting or continuing would cross an integrity or authority boundary; it is not punishment.
The purpose is not to force PASS. The purpose is to prevent False Completion and preserve a safe continuation path.
Use for one AI output, coding task, completion report, or ordinary handoff. Record the minimum inspectable completion state in minutes using the quick-use template.
Use for state-changing work across sessions: identify changed files or systems, evidence, authority, unresolved assumptions, rollback, the proposed next owner, and—when responsibility transfer is claimed—the receiver's acceptance and restart point.
Useful public references: the quick-use template, Claim Boundary, and canonical failure record.
Use when many chats, models, agents, or extended project phases share responsibility. Preserve As-of state, role boundaries, active and parked lines, exactly-once requirements, and the next Gate so continuation does not run on momentum.
Use for preregistered blind research involving multiple roles, Runtime execution, independent Witness fixation, committed Gold, private Mapping, controlled reveal, and final comparison.
Level 4 has materially higher setup and custody cost. Reveal artifacts, manifests, commitments, owners, and retrieval routes must be proven before Runtime begins. FR-v0.2.1-01 shows why commitment existence alone is not reveal readiness.
Most users should begin at Level 1. The Formal Run is evidence and an advanced reference, not the entry cost for using OSI.
In an earlier fixed native-domain comparison, RTK produced the correct registered bounded state at Execution Stage 2 in 8 / 8 cases, while OSI’s first Responsibility-stage design produced it in 1 / 8, with 14 critical failure events across 7 cases.
The lanes used different native artifacts and rubrics, so this is not a superiority result. OSI preserves the adverse result and records the later V11 + V12 correction only as a Forward-only architectural update.
Read the bounded RTK → OSI lineage and correction record →
OSI overlaps with restart and context-transfer approaches such as RTK in the broad problem it addresses. OSI’s bounded contribution here is narrower: it evaluates whether a compact operational surface can preserve preregistered restart-relevant items across fixed internal cases. This repository does not claim superiority over RTK or equivalent performance outside the registered evaluation.
For RTK itself, use the authoritative RTK repository. The clean public projection contains no executable RTK artifact; the evidence boundary identifies the fixed artifact retained only in the private research archive.
This is independent work. You do not need to trust an affiliation, credential, or confident claim.
You can inspect:
- the published Forward-only correction and failure chronology;
- schemas and templates;
- the lightweight adoption path and illustrative walkthrough;
- recorded Formal Run counts and the frozen Ledger identity;
- the preserved terminal
BLOCK; - the failure chronology;
- published evidence-hash labels and registered methods; and
- explicit measured, inferred, hypothesized, and unmeasured boundaries.
The failure record is not a claim of empirical success. It is evidence that the project did not rewrite the past, reconstruct unavailable custody artifacts, or manufacture a final score after a completion joint failed.
Readers can inspect the artifacts and reach a different interpretation. Inspectability is the credibility path; author status is not.
Do not trust the author's status. Inspect the system's evidence and boundaries.
This Formal Run is a subordinate completion-integrity record. Its terminal BLOCK is not project failure or full scientific validation. The historical record reports preserved pre-unblinding blindness and completed Runtime, Witness, and exactly-once Primary Evaluator observation, but the post-unblinding comparison did not complete because the pre-existing Gold / Mapping source binding could not be proven.
| Field | Final state |
|---|---|
| Formal Run | FR-v0.2.1-01 |
| Terminal Gate | BLOCK — TERMINALLY CLOSED |
| Runtime | 18 / 18 |
| Witness | 18 / 18 |
| Primary Evaluator | Exactly 1, over 18 / 18 B-IDs |
| Blind Observation Ledger | FROZEN — SHA-256 176da386cc4aefe481ecf1fe13b7e60c0d051e440c403da2866fa3434e7968d0 |
| Pre-freeze Gold / Mapping access | 0 / 0 |
| PE rerun / replacement | 0 / 0 |
| Runtime / Ledger modification | 0 / 0 |
| Final blind score | NOT COMPUTABLE |
| Operational Missing Closure | NONE within the terminally closed operational scope; this does not mean scientific closure |
| Scientific Missing Closure | UNRESOLVED — Gold/Mapping source binding and public reveal-custody inspectability |
| Claim | PRESSURED — UNCHANGED |
| Falsifier | UNRESOLVED — UNCHANGED |
The run remains terminally closed. No reopening, Gold or Mapping reconstruction, retrospective commitment repair, rerun, or replacement is permitted.
The public record distinguishes reported execution from inspectable scientific closure. It does not include every retrievable hash preimage, custody and retrieval artifact, visible-role/internal-identity/artifact mapping, closure record for the earlier blinding or authorization HOLD, or independent reveal-retrievability preflight. Those absences keep scientific closure unresolved while the terminal BLOCK remains correct.
- all 18 Runtime executions and all 18 Witness fixations;
- exactly one Primary Evaluator observation over B001–B018;
- Blind Observation Ledger freeze before any Gold or Mapping access; and
- preservation with no rerun, replacement, Runtime modification, or Ledger modification.
The pre-existing authoritative Gold and Mapping reveal sources, manifests, custody receipts, and retrieval bindings were not provably available. Gold/Mapping agreement comparison could not begin.
- Runtime and Witness
18 / 18; - the frozen Blind Observation Ledger and its identity;
- pre-unblinding blindness;
- exactly-once PE observation; and
- the no-repair, no-rerun, and no-replacement record.
- Gold-to-Ledger or Mapping-to-Ledger agreement;
- a final blind score;
- evidence-based Claim or Falsifier resolution; or
- successful end-to-end Formal Run completion.
BLINDING FAILURE / BLOCK does not mean that the Primary Evaluator saw Gold or Mapping before Ledger freeze. Pre-unblinding blindness was preserved. The complete blind protocol could not validly close because authoritative reveal-source bindings were not proven.
See the canonical FR-v0.2.1-01 failure record.
Execution completion is not evaluation completion. A commitment's recorded existence is not the same as provable reveal readiness. The final evidence joint is part of the Completion Line.
Retrospective Gold or Mapping reconstruction was rejected because a new artifact could not prove what had been committed before blind evaluation. OSI therefore blocked its own Formal Run instead of forcing PASS, while preserving the phases and evidence that did complete.
This does not prove OSI's empirical performance. It directly demonstrates the protocol's refusal to convert incomplete closure into a success claim—the behavior OSI calls prevention of False Completion.
- Project README — value, trust model, usage levels, evidence, and limits.
- Quick use — one-output template, Gate guide, illustrative walkthrough, and AI prompt.
- Level 1 copy-paste template.
- Formal compact 12-field schema — Level 4 research schema, not a Level 1 requirement.
- Contributing guide
- Code of Conduct
- Security and private disclosure guidance
- Support guidance
- Issue templates
This clean public release surface is available under the MIT License.
- OSI does not guarantee truth, universal correctness, or safe deployment.
- OSI does not replace tests, CI, formal verification, review, or human judgment.
- Not all work needs the full protocol; Level 1 is the ordinary starting point and a simple note may be enough when no acceptance boundary exists.
- The repository has not measured percentage reductions in tokens, time, self-verification, correction loops, monitoring, or total workflow cost.
- The fixed character-count findings are internal bounded results, not general performance or productivity claims.
- FR-v0.2.1-01 has no final blind score and did not complete end-to-end.
- The repository does not establish OSI or RTK superiority, product readiness, market validation, or universal performance.
- The research evidence is not independent third-party validation.
- Inspectable evidence does not eliminate judgment; it exposes the basis and boundaries for judgment.
- The MIT license governs this clean public release surface; it does not alter the evidentiary limits above.
- No GitHub Release, tag, or external announcement is implied by this initial repository publication.