Two months after Issue 10, the team extends the classifier's contract on purpose.
For a good reason.
A fifth field, breaking_confidence, is added to flag whether a change's breaking status was stated explicitly in the commit message or inferred by the classifier.
Every mechanism this series has built runs exactly as designed.
The Ground Truth Contract is updated using the Issue 4 method.
A Red-Team Protocol pass runs against the new field before deployment, using the Issue 8 method.
The Validation Suite confirms that the classifier's output still satisfies its own contract.
No canonical case regresses, so the Circuit Breaker from Issue 9 never trips.
The change is recorded in the Immutable Snapshot from Issue 10.
Reviewed.
Approved.
Deployed.
Two days later, the public changelog starts producing broken release notes.
The classifications are correct.
The classifier is still passing every check.
The failure is downstream.
Some release notes begin surfacing internal confidence language that was never meant for customers.
A sentence that should read:
"This release changes the authentication flow for API clients."
now occasionally becomes:
"This release changes the authentication flow for API clients. Breaking confidence: inferred."
Another entry changes its phrasing because the downstream prompt interprets the new field as customer-facing metadata.
Nothing about the classifier's own output is wrong.
The changelog page is generated by a second prompt.
That prompt takes the classifier's JSON and turns it into human-readable release notes.
It was built against the classifier's original four-field contract.
Nobody updated the downstream contract when breaking_confidence appeared.
The release-notes generator had no defined behavior for the new field.
It did not know whether the field should be ignored, interpreted, or exposed.
Most of the time, the field had no visible effect.
Sometimes the model incorporated it into the final answer because the downstream prompt never specified what an additional field meant.
The Ground Truth Contract does not catch this because the classifier is satisfying its own definition of correct.
The Validation Suite does not catch it because the classifier is passing its own tests.
The Circuit Breaker does not trip because none of the classifier's canonical cases changed.
Every control built so far is scoped to an individual step or its review state.
None explicitly validates the contract between two steps.
The pipeline did not fail inside either prompt.
It failed at the seam.
Method Deep-Dive: the property that exists at the boundary between prompts
In Cognitive Interface Architecture, Prompt Chain Integrity is the property a prompt chain has when every handoff is checked against an explicit contract before the downstream step runs.
A Ground Truth Contract defines correctness inside a step.
Prompt Chain Integrity checks whether the contract between steps still holds.
That distinction matters.
A prompt chain creates a new failure surface the moment one step consumes another step's output.
The first prompt may be correct.
The second prompt may also be correct relative to the input shape it was designed to receive.
The chain can still fail if the first prompt changes what it produces and the second prompt continues operating under an outdated assumption.
Without a checked handoff, the failure is quiet.
Step one produces something close enough to the old interface.
Step two runs anyway.
The final output looks plausible.
The problem becomes expensive to trace because the failure did not originate inside either prompt.
It originated in the assumption connecting them.
That assumption was never written down as a contract.
This is a different failure surface from the mechanisms covered in Issues 3 through 10.
A Ground Truth Contract specifies what correct means for one step.
A Validation Suite checks that step against its defined criteria.
A Red-Team Protocol probes the workflow for failure conditions.
A Circuit Breaker stops the system when a defined threshold is crossed.
An Immutable Snapshot records what was checked and concluded.
All of those mechanisms still matter.
But none of them automatically answers a different question:
Does what step one produced still match what step two was built to consume?
That question lives at the boundary.
The fix is not a better prompt on either side.
It is a check at the seam itself.
Before the downstream prompt runs, compare what actually arrived against what the downstream step is entitled to assume.
If the handoff no longer matches, stop loudly.
Constraint Case Study: catching the fifth field before it reaches the generator
In this pipeline, the release-notes generator is built against an exact schema contract.
That means an additional field is itself a contract change.
The generator is allowed to run only when the classifier produces exactly the field set it was designed to consume.
One boundary check closes the gap:
RELEASE_NOTES_EXPECTED_FIELDS = {
"change_type",
"severity",
"scope",
"summary",
}
def check_chain_boundary(classifier_output: dict) -> None:
produced = set(classifier_output.keys())
unexpected = produced - RELEASE_NOTES_EXPECTED_FIELDS
missing = RELEASE_NOTES_EXPECTED_FIELDS - produced
if unexpected or missing:
raise RuntimeError(
"Chain boundary broken between classifier and "
"release-notes generator. "
f"Unexpected fields: {unexpected or 'none'}. "
f"Missing fields: {missing or 'none'}. "
"Update the downstream contract before this chain runs again."
)
def generate_release_note(classifier_output: dict) -> str:
check_chain_boundary(classifier_output)
# The downstream generator only runs against the exact
# schema it was designed to consume.
return render_release_note(classifier_output)With this check in place, the first appearance of breaking_confidence stops the chain before the release-notes generator sees it.
Nothing malformed reaches the public changelog.
The error names the change directly:
Unexpected fields: {'breaking_confidence'}
Now the team has to make a deliberate decision.
Should the release-notes generator ignore the field?
Should it use the field internally but never surface it?
Should the field change how the release note is phrased?
Should the downstream schema expand to permit it?
Any of those decisions can be correct.
What cannot remain correct is having no decision at all.
Once the team decides what the downstream contract should be, it updates the expected schema and the release-notes prompt together.
Then the chain runs again.
The important part is not the Python function.
It is the architectural rule the function enforces:
A downstream step does not consume a changed interface until that interface change has been acknowledged deliberately.
Vocabulary Anchor: Prompt Chain Integrity
In Cognitive Interface Architecture, Prompt Chain Integrity is the property a prompt chain has when every handoff between steps is checked against an explicit contract before the downstream step runs.
If the handoff stops matching the contract, the chain fails loudly instead of continuing under an outdated assumption.
Prompt Chain Integrity is a property of the connection between steps.
It is not a property of either prompt in isolation.
In use:
"Every prompt in the pipeline passed its own Validation Suite. The chain still broke because nothing checked Prompt Chain Integrity where the classifier's output became the release-notes generator's input."
Where it does not apply:
A single-prompt system has no inter-prompt boundary to check.
The Ground Truth Contract and Validation Suite already define and test correctness inside that step.
Prompt Chain Integrity also does not replace those mechanisms.
A boundary check can confirm that the correct fields crossed the seam.
It cannot tell you whether the classifier's internal conclusion was correct.
It cannot tell you whether the release-notes prompt contains a flawed instruction.
It only answers the boundary question:
Did the downstream step receive the interface it was built to consume?
A chain can have perfect Prompt Chain Integrity and still produce a wrong answer if one step's own contract is wrong.
The seam can be correct while the step is not.
Both levels require controls.
Architecture Brief: the unit of analysis just expanded
Every mechanism from Issues 3 through 10 treated the prompt as the primary unit of control.
That remains valid.
A prompt still needs its own Ground Truth Contract.
Its own validation.
Its own failure conditions.
Its own review history.
But the moment one prompt consumes another prompt's output, the unit of analysis expands.
Now the seam matters too.
A system with multiple steps has two different control problems:
Is each step correct?
and:
Are the assumptions between steps still correct?
Per-step controls answer the first question.
Prompt Chain Integrity answers the second.
In a simple linear chain of N prompts, there are N-1 handoffs to check.
Three prompts in a straight line create two seams.
Four prompts create three.
But real systems do not stay linear for long.
Once one output feeds multiple consumers, or multiple branches merge into another step, the number of handoffs follows the dependency structure, not the number of prompts.
That matters because a single upstream contract change can now affect several downstream consumers, each with a different assumption about what it receives.
The practical question changes.
Do not ask only:
"Does this prompt still work?"
Ask:
"For every place this prompt's output becomes another step's input, is there a written contract for the handoff, and does something verify it before the downstream step runs?"
If the answer is no, the system has a blind spot.
Every component can pass independently while the chain fails between them.
Closing Calibration
Check one thing this week.
Find every place in your own system where one step's output becomes another step's input.
That might be:
A second LLM call.
A downstream function.
An agent handoff.
A human copying output from one tool into another.
For each boundary, ask:
What is the first step required to produce?
What is the second step allowed to assume?
Is that handoff written down?
Does anything verify it before the second step runs?
If the answer is:
"The second step just uses whatever the first step sends."
you have the exact failure surface this issue describes.
You do not need a large orchestration framework to start fixing it.
Write down the expected handoff.
Check the actual input against it.
Stop the downstream step when the contract changes.
One seam.
One explicit contract.
One loud failure instead of a quiet one.
Next week, the shape changes.
Two prompts in a line are the simplest possible chain.
Real systems branch.
A classifier may feed a release-notes generator, a dashboard, and an alerting rule at the same time.
Three consumers.
Three different assumptions.
One upstream change.
Checking each seam is possible.
But before you can check the seams, you need to know where they are.
Once outputs branch, merge, and feed each other across a larger system, the dependency structure itself becomes part of the architecture.
That structure has a name.
The Constraint