PAT-0190
Contract Drift
A structural condition where a declared contract changes but connected structures, implementations, consumers, or expectations do not update in sync.
Primary Lenses
Reconciliation Lens
Evaluates whether structural changes align with declared authority updates, version changes, or reconciliation rules.
Lens Application
The Reconciliation Lens is a strong inspection mechanism for Contract Drift because it examines whether declared contract changes have been reconciled across connected structures, implementations, and expectations. It helps surface mismatches between authority updates, version signals, implementation behavior, and consumer assumptions.
Inspect For
- Contract changes without matching implementation updates
- Version or authority updates not reflected downstream
- Consumers relying on older expectations
- Reconciliation rules skipped or inconsistently applied
Avoid
Treat mismatch signals as prompts for closer inspection, not confirmation of Contract Drift, until the update path, dependency context, and reconciliation rules are checked.
Convergence Lens
Compares parallel structural systems to determine whether they align under shared authority.
Lens Application
The Convergence Lens is a strong inspection mechanism for Contract Drift because it places related structures side by side and checks whether declared contracts, implementations, consumers, and operational expectations still converge under the same authority.
Inspect For
- Divergence between declared contract and implemented behavior
- Consumers relying on outdated assumptions
- Parallel documentation, schema, API, or workflow mismatch
- Authority updates applied unevenly across connected structures
Avoid
Treat divergence as an inspection signal requiring follow-up, not proof that Contract Drift is fully present.
Secondary Lenses
Determinism Lens
Evaluates whether identical structural inputs produce equivalent structural outputs across repeated executions.
Lens Application
The Determinism Lens applies indirectly to Contract Drift by helping inspect whether drift is affecting repeatability across connected structures. When a declared contract changes unevenly, identical structural inputs may yield divergent outputs, routing, validation behavior, or consumer responses, signaling areas where synchronization may need closer review.
Inspect For
- Same inputs producing different outputs across runs
- Validation differences between contract and implementation paths
- Consumer behavior changing without input changes
- Environment-specific or version-specific output variance
Avoid
Treat nondeterministic behavior as a signal for further drift inspection, not evidence that Contract Drift has been established.
Primary Issue Matches
Actual Policy Differs From Declared Policy
The policy the AI or workflow actually follows differs from the policy that is documented, declared, displayed, or expected.
Context Changes After Restore
Restoring, reopening, resuming, or reloading a task changes the context that the AI uses to continue the work.
Old Output Expectations Survive Migration
Expectations from a prior model, prompt, schema, tool, or workflow survive a migration and continue shaping review or downstream handling after they should be replaced.
Policy Update Not Reflected in Output
A policy, rule, standard, or instruction has been updated, but the AI output still follows the older version.
Prompt Changed but Workflow Did Not
A prompt changes but the workflow, parser, review step, routing rule, or downstream expectation still assumes the old prompt behavior.
Rubric Changed but Results Did Not
A review rubric, scoring rule, evaluation standard, or classification criterion changes, but AI results continue to reflect the old rubric.
Same Contract Name Has Different Meanings
The same prompt, schema, field, policy, tool, or workflow contract name is used in different places with different meanings.
Stale Context Affects Output
Old context, prior instructions, outdated references, or earlier task state continue to affect output after they should no longer apply.
Version Change Breaks Existing Prompt
A prompt that previously produced usable results stops working after a version change in the model, tool, policy, schema, product surface, or workflow.
Supporting Issue Matches
AI Forgets Earlier Constraints
A constraint, instruction, preference, or decision that should persist through the task stops affecting later output.
Early Model Output Gets Overweighted Downstream
An early AI output receives too much authority in later workflow steps, decisions, reviews, or generated artifacts.
Output Breaks After Model Change
Output that previously worked begins failing after a model, mode, runtime, or product behavior changes.
Output Changed Without Declared Change
Output shape, content, format, fields, or behavior changes without a declared change to the prompt, schema, model, workflow, or governing rule.
Prompt Behavior Changed Without Version Change
A prompt begins producing different behavior even though no prompt version, model version, workflow version, or declared dependency change is recorded.
Revoked Approval Still Treated as Active
An approval, permission, exception, or authorization that was revoked continues to affect AI behavior or workflow decisions as if it were still active.
Same Rule Declared in Multiple Places
The same rule, constraint, instruction, or policy appears in multiple places, creating redundancy and possible drift.
Saved Reference No Longer Works
A saved source, citation, file reference, prompt reference, or workflow pointer previously worked but no longer resolves to the expected object or meaning.
Small Change Produces Large Downstream Effects
A small prompt, schema, policy, output, or workflow change creates unexpectedly large effects in downstream steps.
Tool Result Not Integrated Correctly
The AI receives a tool result but misreads, ignores, overwrites, misplaces, or fails to incorporate it correctly into the final output or workflow state.