Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/ai-protocol-kit/llms.txt

Use this file to discover all available pages before exploring further.

The Field Findings & Bugs Protocol v2 governs how an AI captures, holds, compares, and promotes findings and bugs as structured artifacts during live review or analytical work. It is not a patch spec, a task plan, or a summary style guide. Its job is to prevent weak findings, weak bug records, premature clustering, false generalization, and convergence by momentum — the failure modes that occur when an AI starts from the first salient point and builds structure immediately, rather than opening the field first and letting the full problem space become visible before drawing conclusions.

​
The core distinction

Registration is not promotion. A finding or bug may be recorded early. It may not be generalized, clustered, elevated, or used to drive action until its relation to the wider field is sufficiently clear.
Recording a finding is an act of capture, not an act of interpretation. The moment a finding is registered, it has a surface, an epistemic state, and local boundaries — nothing more. Clustering, rule extraction, sprint selection, patch recommendation, and structural conclusion all require a separate step: the horizontal pass, which checks the full field before any finding is allowed to grow beyond its local scope.

​
Operating posture

The protocol operates on a horizontal-first principle. Before converging on conclusions, the full field must be opened. This means:
  • Do not start from the first salient point and immediately build structure around it
  • Keep all active lenses live at the same time — do not process them sequentially
  • If lenses pull in opposite directions, treat that tension as information, not noise to be resolved early
  • Do not converge until the problem is closed enough to resolve that tension, or to bound it explicitly
The horizontal pass is what separates disciplined analytical work from pattern-matching on momentum. Convergence is only permitted when the field has been sufficiently opened and the relations between findings are clear enough to act on.

​
Active lenses

The following lenses remain live simultaneously throughout any review or analytical session governed by this protocol. Tension between them is expected and informative.
Prefer explanations grounded in actual causal structure over pattern-based shortcuts. When a finding can be explained either by a known heuristic or by identifying the underlying mechanism, the mechanism takes precedence. Heuristics may be recorded but must not be promoted to governing rules.
Findings should narrow what is possible — ruling out states, causes, or explanations — before they assert what is true. Privative reasoning reduces the solution space. Convergence follows only after sufficient elimination.
Cognitive and operational overload degrades finding quality. The protocol constrains the number of simultaneously open, promoted findings to what can be meaningfully held and compared. Unpromoted findings remain registered but do not claim attention until the field is ready.
When a finding depends on an ambiguity that materially changes what should happen next, do not smooth over it. The finding must be held open and the ambiguity must be marked explicitly. Premature closure on ambiguous findings produces false confidence downstream.
A single finding may stand as a local case. It may not become a family, a rule, a pattern, or a strategy by itself unless the reason for promotion is explicitly justified. One instance is evidence; it is not a law.
Do not introduce structural frameworks, categorization schemes, or classification hierarchies before they are warranted by the finding set. A flat list of well-scoped findings is more reliable than a premature taxonomy built on weak cases.
Any individual finding exists inside a larger system. Before promoting a finding, consider where it sits in that volume — whether its consequences stay local or propagate further. A local surface defect may have corridor-level or system-level consequences.
The location where a finding is observed is not the same as the scope of its impact. A bug on a narrow surface may invalidate wider logic. A finding that appears bounded may reveal a structural flaw. Always distinguish observation surface from consequence boundary.

​
The 15 protocol rules

Before recording a finding, identify the target object, the active surface, the current scope, and the authority frame. If these are not closed enough, record the uncertainty before recording the finding itself. Capturing a finding against an open or ambiguous object produces a finding that cannot be reliably compared, promoted, or acted on.
A finding may be registered when all of the following are true: it has a surface that can be pointed to; it is at least partly verifiable in the live object or live evidence base; it can stand as a local point without pretending that wider relations are already known.
Every finding must explicitly separate verified, inferred, and hypothetical states. Do not write inferred or hypothetical states as if they were verified. This separation is not stylistic — it determines which findings can be promoted and which must be held open.
Recording a finding does not yet authorize: clustering, generalization, rule extraction, sprint selection, patch recommendation, or structural conclusion. These require the horizontal pass to be completed first.
Before promoting any finding, reopen the field horizontally. Check relations, tensions, dependencies, exclusions, collisions, false groupings, and hidden asymmetries. Do not promote from an isolated point if its wider relation is still unknown and could change its meaning.
A single finding may stand as a local case. It may not become a family, a rule, a pattern, or a strategy by itself unless the reason for promotion is explicitly justified.
Every finding must state whether its consequence currently appears: local / bounded; corridor-level / wider than local surface; or not yet closed.
A finding should not be kept alive merely because it sounds plausible or elegant. It must have at least one of the following: operational consequence; structural consequence; or an unresolved tension that could change a decision, patch, or recommendation.
If a finding depends on an ambiguity that materially changes what should happen next, do not smooth over it. Mark the ambiguity and keep the finding open.
A finding may be promoted only when at least one of the following is true: it invalidates other findings; it orders other findings; it opens or closes a corridor; it changes the expected action; or it changes the recommendation boundary.
Do not multiply findings that collapse into the same governing issue. Fuse vertically only after the relation is clear. Until then, keep them separate and honestly bounded.
Each finding record must close at least: ID, surface, epistemic state, impact, boundaries, relations, and operational state. Incomplete records are not valid finding artifacts.
Allowed states: open, bounded, deferred, closed. A finding must carry one of these states at all times. An untagged finding has no valid operational position.
If a finding remains ambiguous but does not currently change action, recommendation, or scope: register it, bound it, and do not force convergence. Forced convergence on an ambiguous finding is a failure mode, not a resolution.
A findings file is a disciplined holding field for live analytical pressure. It is not a patch queue, not a design doctrine, and not a summary of what already feels true.

​
Finding record shape

Every finding captured under this protocol must follow this record shape. Fields may not be omitted. If a field cannot be filled, its uncertainty must be stated explicitly. 
ID:
Surface:
Verified:
Inferred:
Hypothetical:
Impact:
Boundaries:
Relations:
Operational state:
Next review need:
Do not treat inferred states as verified. Epistemic labeling is not optional.

​
Failure modes prevented

This protocol is specifically designed to prevent the following seven failure modes:
  1. Registering vibes as findings — capturing the feeling that something is wrong without a verifiable surface or anchor
  2. Treating inferred states as verified — promoting conclusions that depend on inference as if they had been directly confirmed
  3. Clustering too early — grouping findings before their relations are clear, creating false families
  4. Promoting single cases into rules — elevating one instance to a pattern, policy, or law without justification
  5. Widening scope without naming it — allowing a finding’s impact boundary to grow implicitly without explicit acknowledgment
  6. Converging from momentum instead of structure — closing the field because progress feels good rather than because the structure warrants it
  7. Turning a findings file into a patch plan or ideology dump — treating the findings artifact as a design doctrine or action backlog rather than a disciplined analytical holding space

​
Protocol text

The complete source protocol text is preserved below for reference. 
FIELD FINDINGS & BUGS PROTOCOL
Version: v2
Type: LLM operational protocol
Scope: review finding and bug capture, comparison, and later promotion

Purpose
This protocol governs how an LLM should capture, hold, compare, and promote findings and bugs during live review or analytical work.
It is not a patch spec.
It is not a task plan.
It is not a summary style guide.
Its job is to prevent weak findings, weak bug records, premature clustering, false generalization, and convergence by momentum.

Core distinction
Registration is not promotion.
A finding or bug may be recorded early.
It may not be generalized, clustered, elevated, or used to drive action until its relation to the wider field is sufficiently clear.

Operating posture
Do not start from the first salient point and build structure immediately.
Open the field horizontally first.
Keep the active lenses live at the same time.
If they pull in opposite directions, treat that tension as information.
Do not converge until the problem is closed enough to resolve that tension or bound it explicitly.

Active lenses
- mechanism beats heuristic
- privative but convergent
- miller constraint
- fail-closed on meaningful ambiguity
- no formalization from single instance
- simplicity before meta-machinery
- the task is a point, the system is the volume
- local surface != local consequence

Protocol

1. Close the object before capture
Before recording a finding, identify:
- the target object
- the active surface
- the current scope
- the authority frame
If these are not closed enough, record the uncertainty before recording the finding itself.

2. Registration threshold
A finding may be registered when all of the following are true:
- it has a surface that can be pointed to
- it is at least partly verifiable in the live object or live evidence base
- it can stand as a local point without pretending that wider relations are already known

3. Epistemic labeling is mandatory
Every finding must explicitly separate:
- verified
- inferred
- hypothetical
Do not write inferred or hypothetical states as if they were verified.

4. Registration does not authorize promotion
Recording a finding does not yet authorize:
- clustering
- generalization
- rule extraction
- sprint selection
- patch recommendation
- structural conclusion

5. Horizontal pass before promotion
Before promoting any finding, reopen the field horizontally.
Check:
- relations
- tensions
- dependencies
- exclusions
- collisions
- false groupings
- hidden asymmetries
Do not promote from an isolated point if its wider relation is still unknown and could change its meaning.

6. No formalization from single instance
A single finding may stand as a local case.
It may not become a family, a rule, a pattern, or a strategy by itself unless the reason for promotion is explicitly justified.

7. Impact classification
Every finding must state whether its consequence currently appears:
- local / bounded
- corridor-level / wider than local surface
- not yet closed

8. Relevance threshold
A finding should not be kept alive merely because it sounds plausible or elegant.
It must have at least one of the following:
- operational consequence
- structural consequence
- unresolved tension that could change a decision, patch, or recommendation

9. Fail-closed capture
If a finding depends on an ambiguity that materially changes what should happen next, do not smooth over it.
Mark the ambiguity and keep the finding open.

10. Promotion threshold
A finding may be promoted only when at least one of the following is true:
- it invalidates other findings
- it orders other findings
- it opens or closes a corridor
- it changes the expected action
- it changes the recommendation boundary

11. Compression rule
Do not multiply findings that collapse into the same governing issue.
Fuse vertically only after the relation is clear.
Until then, keep them separate and honestly bounded.

12. Output discipline
Each finding record must close at least:
- ID
- surface
- epistemic state
- impact
- boundaries
- relations
- operational state

13. Operational states
Allowed states:
- open
- bounded
- deferred
- closed

14. Closure rule
If a finding remains ambiguous but does not currently change action, recommendation, or scope:
- register it
- bound it
- do not force convergence

15. Final use rule
A findings file is a disciplined holding field for live analytical pressure.
It is not a patch queue, not a design doctrine, and not a summary of what already feels true.

Recommended record shape

ID:
Surface:
Verified:
Inferred:
Hypothetical:
Impact:
Boundaries:
Relations:
Operational state:
Next review need:

Failure modes this protocol is designed to prevent
- registering vibes as findings
- treating inferred states as verified
- clustering too early
- promoting single cases into rules
- widening scope without naming it
- converging from momentum instead of structure
- turning a findings file into a patch plan or ideology dump

Build docs developers (and LLMs) love

Get started for freeTalk to us