PAT-0180
Compatibility Violation
A structural condition where a graph, object, behavior, or runtime state exceeds a declared compatibility envelope without an authorized exception.
Primary Lenses
Compatibility Envelope Lens
Determines whether structure fits within declared runtime, platform, version, or support constraints.
Lens Application
The Compatibility Envelope Lens is a strong inspection mechanism for Compatibility Violation because it focuses on whether the examined condition remains inside its declared compatibility boundary or depends on unsupported versions, platforms, configurations, or runtime assumptions.
Inspect For
- Declared compatibility limits, support matrices, or version ranges
- Runtime behavior outside supported environments
- Objects or graph structures exceeding platform constraints
- Exceptions, overrides, or unsupported compatibility claims
Avoid
Treat mismatch signals as prompts for closer inspection, not confirmation of Compatibility Violation, until authorized exceptions or documented compatibility extensions are checked.
Secondary Lenses
Boundary Compliance Lens
Evaluates observed structure against declared boundary posture, including allow, block, and exception rules.
Lens Application
The Boundary Compliance Lens applies indirectly to Compatibility Violation by helping inspect whether observed behavior, graph shape, object state, or runtime posture sits outside declared allow, block, or exception boundaries. It can surface compatibility concerns when boundary rules and compatibility envelopes overlap, but should not be treated as a standalone determination.
Inspect For
- Declared allow or block rules near compatibility limits
- Runtime states outside expected boundary posture
- Missing, expired, or unauthorized exceptions
- Boundary rule changes that expose compatibility drift
Avoid
Treat boundary noncompliance as an inspection signal, not sufficient evidence that Compatibility Violation is present.
Primary Issue Matches
Supporting Issue Matches
AI Output Breaks Parser
The AI output causes a parser, validator, importer, or structured-output consumer to fail.
Automation Skips Required Approval
An automated AI or workflow step proceeds past an approval gate that should have been required before action.
Citation Points to Wrong Source
A citation, reference, link, or source pointer is present, but it points to the wrong source, wrong passage, wrong document, or unsupported evidence.
Declared Owner Cannot Control Outcome
A person, role, system, or policy is declared responsible for an outcome but does not have the actual authority or control needed to govern it.
Model and Workflow Disagree on Next Step
The AI model recommends or selects a next step that conflicts with the workflow state, required handoff, routing rule, or process sequence.
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 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.
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 Call Contract Mismatch
The AI or agent calls a tool with names, arguments, types, modes, or shapes that do not match the declared tool interface.
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.
Wrong Field Types
The AI returns fields with values whose types do not match the expected schema, such as strings where numbers, booleans, arrays, objects, or enums are required.