LEN-0180
Determinism Lens
Evaluates whether identical structural inputs produce equivalent structural outputs across repeated executions.
Primary Pattern Matches
Non-Deterministic Execution
A structural condition where equivalent inputs and declared constraints produce divergent outputs across executions.
Lens Application
The Determinism Lens is a primary inspection mechanism for Non-Deterministic Execution because it focuses directly on whether repeated executions preserve equivalent structural outputs when inputs and declared constraints remain equivalent.
Inspect For
- Output drift across repeated equivalent executions
- Hidden sources of randomness, timing, or ordering
- Inconsistent constraint interpretation between runs
- Divergent intermediate states or final structures
Avoid
Treat a single divergent run as an inspection signal rather than conclusive evidence without comparing repeated executions and surrounding structural conditions.
Silent Mutation
A structural condition where a change occurs without a corresponding declared update, authority update, or version change.
Lens Application
The Determinism Lens is a primary inspection mechanism for Silent Mutation because it checks whether identical structural inputs produce equivalent outputs over repeated runs. Unexpected variation can indicate a change occurring silently, especially when no corresponding version, declaration, or authority update is visible.
Inspect For
- Output drift from identical structural inputs
- Repeated executions producing different structures
- Missing version or authority changes beside changed results
- Undeclared transformations in stable workflows
Avoid
Treat output variation as a signal for closer inspection rather than as proof that Silent Mutation has occurred.
Secondary Pattern Matches
Constraints Underspecified
A structural condition where declared constraints are insufficient to eliminate ambiguity or multiple admissible states.
Lens Application
The Determinism Lens applies indirectly to Constraints Underspecified by surfacing where identical inputs produce varying outputs. That variation may indicate declared constraints leave multiple admissible states unresolved, warranting closer structural inspection.
Inspect For
- Output variation across repeated executions
- Multiple acceptable states from the same inputs
- Tie-breaking or ordering behavior not declared
- Hidden defaults influencing repeatability
Avoid
Treat nondeterministic behavior as an inspection signal, not proof that Constraints Underspecified is present.
Contract Drift
A structural condition where a declared contract changes but connected structures, implementations, consumers, or expectations do not update in sync.
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.
Divergent Outputs
A structural condition where parallel evaluations under comparable scope and shared authority produce non-equivalent outputs.
Lens Application
The Determinism Lens applies indirectly to Divergent Outputs by helping inspect whether output differences arise despite equivalent inputs, repeated execution conditions, or comparable evaluation authority. It highlights instability across runs, but should not be treated as sufficient on its own to establish the condition.
Inspect For
- Repeated evaluations with equivalent structural inputs
- Output differences under comparable scope
- Shared authority producing inconsistent results
- Execution conditions that appear materially unchanged
Avoid
Treat nondeterministic variation as an inspection signal, not confirmation of Divergent Outputs, until scope, authority, and structural comparability are checked.
Persistence Instability
A structural condition where persisted state cannot be stored and restored into an equivalent structure without alteration.
Lens Application
As a secondary lens, the Determinism Lens supports inspection of Persistence Instability by surfacing inconsistent restoration outcomes across repeated persistence cycles. If identical persisted structures restore into varying or altered forms, determinism checks may help locate where persistence behavior contributes to structural instability.
Inspect For
- Different restored structures from identical persisted inputs
- Repeated save/load cycles producing drift
- Non-deterministic ordering, defaults, or identifiers after restore
- Environment-dependent restoration behavior
Avoid
Treat inconsistent restoration as a supporting inspection signal, not as standalone confirmation that Persistence Instability is present.
Reference Instability
A structural condition where references, identifiers, links, or anchors change across equivalent evaluations without a declared cause.
Lens Application
As a secondary lens, the Determinism Lens can support inspection of Reference Instability by comparing repeated runs or equivalent evaluations for reference consistency. It may surface unstable anchors, regenerated identifiers, or shifting links, but it should be paired with more direct reference-focused checks before drawing conclusions.
Inspect For
- Identifiers changing across equivalent evaluations
- Links or anchors resolving differently between runs
- Reference order, naming, or targeting drift
- Missing declared cause for reference changes
Avoid
Treat nondeterministic output as a supporting inspection signal, not as sufficient evidence that Reference Instability has been established without checking the affected references and structural context.
Related Issues
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.
AI Forgets Earlier Constraints
A constraint, instruction, preference, or decision that should persist through the task stops affecting later output.
AI Memory Has No Governance
Saved or persistent AI memory affects output without clear rules for ownership, scope, review, update, expiry, or removal.
AI Memory Updated Without Asking
AI memory, saved context, preference, or durable state is updated without the user clearly asking for or approving that update.
Answer Has No Traceable Source Link
The answer makes a claim, recommendation, citation, or factual statement without a source link or trace path that allows the user to verify where it came from.
Answer Has Too Many Paths
The answer presents too many possible paths, interpretations, options, or next steps without enough structure to choose among them.
Cannot Identify Authoritative State
The user or workflow cannot tell which state, version, review result, decision, source, or output is currently authoritative.
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.
Context Changes After Restore
Restoring, reopening, resuming, or reloading a task changes the context that the AI uses to continue the work.
Context Leaks Between Tasks
Context, assumptions, constraints, examples, files, or decisions from one task affect another task where they should not apply.
Diagnostic Area Has No Coverage
A known diagnostic area, failure mode, requirement, or review dimension has no Issue, check, rubric item, or workflow coverage.
Early Model Output Gets Overweighted Downstream
An early AI output receives too much authority in later workflow steps, decisions, reviews, or generated artifacts.
Evaluation Rubric Has Coverage Gap
An evaluation rubric, grading standard, or review checklist leaves part of the required evaluation space uncovered.
File-Bounded Task Uses Outside Content
The AI is asked to work only from a specific file or document but uses content, assumptions, or sources outside that file.
Format Rule Too Weak
The format instruction is too vague, incomplete, or optional to reliably produce output that satisfies the expected structure.
Invalid JSON Output
The AI returns malformed JSON or structured output that cannot be parsed.
Missing Fallback for Unavailable Information
The task does not declare what the AI should do when required information, sources, tools, fields, or evidence are unavailable.
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.
One Prompt Carries Too Many Meanings
A single prompt carries too many meanings, goals, roles, constraints, or implied tasks for the AI to interpret consistently.
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.
Output Exceeds Length Limit
The AI output exceeds a declared length, token, word, character, section, field, or size limit.
Parallel Reviews Never Agree
Parallel AI, human, workflow, or tool reviews keep producing different results without resolving into a shared decision state.
Policy Area Has No Examples
A policy, rule, standard, or guidance area has no examples showing how it should apply to real cases.
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 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.
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.
Prompt Does Not Say What to Exclude
The prompt declares what to include but does not declare what should be excluded, allowing unwanted scope, sources, content, or actions into the result.
Prompt Has Too Many Valid Interpretations
The prompt allows too many reasonable interpretations, causing the AI to choose among valid paths without enough guidance.
Prompt Only Works After Retry
The prompt fails, misroutes, or produces an unusable response on one attempt but works after retry without a meaningful change to the input.
Relationship Map Has Missing Links
A map of related Issues, rules, patterns, cases, fields, tools, or workflow steps is missing links needed to navigate or reason over the structure.
Repeated Constraints Create Confusion
Repeated constraints, instructions, limits, or exclusions make the task harder to interpret instead of clearer.
Results Vary Too Much
Repeated or comparable runs produce outputs that vary more than the task, workflow, or user can tolerate.
Retry Makes the Problem Worse
A retry, repair attempt, regeneration, or follow-up instruction increases the error, expands the failure, or creates additional breakage instead of narrowing the problem.
Review Rubric Missing Required Criteria
A review rubric, grading rule, evaluation checklist, or classification standard lacks criteria required to make the review reliable.
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.
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.
Same Instructions Allow Different Outputs
The same instructions are broad or underspecified enough to allow materially different outputs that all appear compliant.
Same Rule Declared in Multiple Places
The same rule, constraint, instruction, or policy appears in multiple places, creating redundancy and possible drift.
Saved Memory Not Used
A saved memory, preference, instruction, or durable context item exists but does not affect the AI output when it should.
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.
Schema Reference Loops Without Base Case
A schema, field, type, object, or structured reference points through a loop without a base case that allows validation or interpretation to resolve.
Similar Cases Route to Different Outcomes
Similar inputs, cases, prompts, or workflow states are routed to different outcomes without a declared difference that explains the split.
Small Change Produces Large Downstream Effects
A small prompt, schema, policy, output, or workflow change creates unexpectedly large effects in downstream steps.
Stale Context Affects Output
Old context, prior instructions, outdated references, or earlier task state continue to affect output after they should no longer apply.
Task Has No Clear Limit
The task does not declare where the AI should stop, what is out of scope, or what counts as enough work.
Task Progress Is Lost Midway
The AI loses track of completed work, prior decisions, current position, or remaining steps before the task is finished.
Tool Exists but Required Inputs Are Missing
A usable tool or integration exists, but the AI or agent does not have the required inputs, permissions, fields, identifiers, or context needed to call it correctly.
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.
Validation Result Changes on Retry
A validation, grading, review, classification, or pass/fail result changes after retry even though the input and declared validation rules did not change.
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.
Workflow Step Lacks Required Conditions
A workflow step can run, route, approve, reject, or continue without the required conditions being declared or checked.