Three weeks after Issue 9's Circuit Breaker went live on the changelog classifier, it trips again.
Different case. Different cause.
The person who reopened it last time is out this week. The person on call opens the trip reason, sees a case ID and a FAIL status, and has one question:
Is the current contract the same one that was reviewed and confirmed three weeks ago, or has nothing been checked since Issue 4?
There is no durable answer.
The phrase used three weeks ago reopened the pipeline. It did not record what the reviewer inspected, what they ruled out, or what they decided was now the trusted baseline.
That decision lived in one person's memory and a Slack message that has since scrolled out of view.
The on-call engineer spends forty minutes reconstructing context someone else already established. They rerun the Issue 8 Red-Team Protocol against a contract that may already have been checked.
They cannot tell.
Nothing about the previous decision was recorded in a form the pipeline, the current reviewer, or the next reviewer can consult.
This is not a diagnosis problem.
Issues 6 through 9 already cover diagnosis, validation, gating, and drift triage.
This is a memory problem.
The system knows what is currently running. It does not know what was previously checked, why that state was trusted, or what conclusion justified reopening the gate.
Method Deep-Dive: why a mutable log is not a durable decision record
Most teams already keep some form of log.
A changelog file. A Slack thread. A comment in the code.
All three can preserve information. None of them guarantees that the reasoning behind a decision remains available in the form it existed when the decision was made.
A changelog can be edited later to make the sequence look cleaner than it was.
A Slack thread can disappear from the working context of the next person who needs it.
A code comment can vanish the next time someone modifies the file.
The failure is not that these tools are bad.
The failure is that the decision has no dedicated persistence contract.
In Cognitive Interface Architecture, an Immutable Snapshot is an append-only decision record that preserves what was checked, when it was checked, and what was concluded.
Its write model is the important part.
A changed decision creates a new entry. It does not rewrite the previous one.
The old entry remains available as a record of what was believed true at that point in the system's history.
That distinction matters because review state drifts.
A new reviewer does not automatically inherit the reasoning of the previous reviewer. A new agent does not know why a prior state was accepted. A future version of the same person may not remember the assumptions behind a decision made three months earlier.
Memory is not an interface.
A durable decision record is.
A minimal Immutable Snapshot needs four fields:
A unique identifier that is never reused.
A date.
What was checked.
What was concluded.
That is enough to make the decision consultable by someone who was not in the room.
It is also enough to prevent a common review failure: treating today's accepted state as if it had no history.
Constraint Case Study: a decision log for the classifier's breaker reopens
The classifier's Circuit Breaker from Issue 9 gates publishing behind a phrase.
Before this issue, the gate recorded only that someone supplied the correct phrase.
It did not record what justified reopening the pipeline.
Adding an Immutable Snapshot closes that gap.
Every reopen appends a decision entry before the gate changes state. Every future reviewer can inspect the decision history before deciding whether the current state can be trusted.
import json
from datetime import datetime, timezone
SNAPSHOT_LOG_PATH = "decisions/classifier_snapshots.jsonl"
def append_snapshot(trip_reason: dict, checked: str, conclusion: str) -> str:
entry_id = f"D-{sum(1 for _ in open(SNAPSHOT_LOG_PATH)) + 1:03d}"
entry = {
"id": entry_id,
"date": datetime.now(timezone.utc).isoformat(),
"trip_reason": trip_reason,
"checked": checked,
"conclusion": conclusion,
}
# Append-only write path.
# A changed decision creates a new line instead of rewriting a prior one.
with open(SNAPSHOT_LOG_PATH, "a") as f:
f.write(json.dumps(entry) + "\n")
return entry_id
def unlock_circuit(
phrase: str,
trip_reason: dict,
checked: str,
conclusion: str
) -> bool:
if phrase != CIRCUIT_BREAKER_UNLOCK_PHRASE:
return False
entry_id = append_snapshot(
trip_reason=trip_reason,
checked=checked,
conclusion=conclusion,
)
circuit_state["open"] = False
circuit_state["trip_reason"] = None
circuit_state["last_verified_snapshot"] = entry_id
return TrueThe function no longer flips a boolean and discards the reasoning behind the decision.
It requires two pieces of review context before the gate can reopen:
checked records what the reviewer actually examined.
conclusion records what the reviewer decided after examining it.
For example:
checked = "Red-Team Protocol pass using the Issue 8 method"
conclusion = "Model drift confirmed. Ground Truth Contract criteria unchanged. Pipeline resumed without contract revision."
The next time the breaker trips, the responder reads classifier_snapshots.jsonl first.
They can see what caused the previous trips, what was checked each time, and what conclusion justified each reopen.
Today's failure may match a previously investigated pattern.
It may contradict a prior conclusion.
It may be genuinely new.
The reviewer can now tell the difference.
The forty minutes of reconstructed context from the Opening Frame becomes a two-minute read.
There is one important boundary.
This example implements an append-only application write path. It does not make the underlying JSONL file tamper-proof. Another process with file access could still rewrite or delete it.
If your system requires cryptographic integrity, retention guarantees, or storage-level immutability, those controls belong below this example.
The architectural requirement here is narrower:
A changed decision produces a new record instead of silently replacing the old one.
Vocabulary Anchor: Immutable Snapshot
In Cognitive Interface Architecture, an Immutable Snapshot is an append-only artifact that preserves a decision or context that must persist across reviewers, agents, or future system states.
Once written, an entry is not revised as part of the normal decision workflow.
If the decision changes, the system writes a new entry.
The prior entry remains available as evidence of what was checked and what was concluded at that point in time.
In an AI review pipeline, an Immutable Snapshot prevents a new reviewer from reconstructing prior reasoning from memory.
It gives that reviewer a consultable decision history.
In use:
"The Circuit Breaker tripped three times this quarter for three different reasons. The classifier snapshot log preserves the reviewer's conclusion from each event, so the fourth trip took two minutes to triage instead of forty."
An Immutable Snapshot does not perform the review itself.
It records what another mechanism concluded.
A Red-Team Protocol examines a contract for gaps.
A Validation Suite detects deviations from that contract.
A Circuit Breaker converts a critical deviation into a stop condition.
A Semantic Drift Vector helps a reviewer identify what changed.
An Immutable Snapshot records what those processes found and what decision followed.
It also does not replace version control for code.
Version control records changes to an artifact.
An Immutable Snapshot records the reasoning attached to a decision.
Those histories can overlap. They are not the same thing.
An Immutable Snapshot is also not a justification for retaining every log forever without structure.
An unindexed pile of append-only entries may satisfy the write model and still fail operationally.
The identifier and date fields exist so the record remains searchable as the history grows.
Architecture Brief: the loop closes with memory, not just control
Six issues now cover the lifecycle of one prompt system.
BYOP diagnoses an existing failure.
Issue 3 starts with something already going wrong and identifies the missing constraint.
The Ground Truth Contract specifies correctness.
Issue 4 defines what must be true before the system is trusted.
The Validation Suite enforces the contract continuously.
Issue 6 compares live behavior against the defined baseline.
The Semantic Drift Vector diagnoses what changed.
Issue 7 gives the reviewer a directional model for the deviation.
The Red-Team Protocol searches for gaps before they become production failures.
Issue 8 challenges the contract before deployment.
The Circuit Breaker converts a critical failure into a stop.
Issue 9 prevents the system from continuing when a defined threshold is crossed.
Each mechanism controls something important.
None of them, by itself, preserves the reasoning generated when a human responds to the failure.
A Validation Suite can record that something failed.
That is not the same as recording why the reviewer decided the contract was still correct.
A Circuit Breaker can record that the gate reopened.
That is not the same as recording what evidence justified reopening it.
A Semantic Drift Vector can describe what changed.
That diagnosis disappears from institutional memory unless the system preserves the conclusion.
Detection happens in the present.
Diagnosis happens in the present.
Review happens in the present.
Without an Immutable Snapshot, the next incident can still begin from zero.
The mechanisms now form a closed control loop:
Specify. Examine. Enforce. Stop. Diagnose. Remember.
The last step changes the behavior of the whole system.
The pipeline no longer accumulates only states.
It accumulates decisions.
That distinction is what turns repeated review from repeated work into institutional knowledge.
Closing Calibration
Set up one thing this week.
Find the point in your own pipeline where a human makes a judgment call and communicates it informally.
It may be a Slack message.
A code comment.
A verbal "yes, ship it."
A note buried in a ticket.
Replace that informal handoff with four fields:
Identifier
Date
What was checked
What was concluded
Write the result somewhere that uses an append-only decision workflow.
You do not need a new database to start.
A structured text file with one entry per decision is enough for the first implementation.
The value is not the storage mechanism.
The value is that the next reviewer can inspect the reasoning without reconstructing it.
The system now remembers more than what is running.
It remembers why someone decided that state was trustworthy.
Next week, the boundary expands.
Every fix in this series has treated the changelog classifier as if it were the whole system.
It is not.
Its output feeds another prompt downstream. That prompt turns classified commits into a public release note.
Change what the classifier emits, even correctly, and the downstream prompt may interpret that new output differently.
A local fix can create a remote failure.
The property that tells you whether a chain of prompts remains coherent when one link changes has a name:
That is the next constraint.
The Constraint