§16 IQ Capture
Emergence-oriented cognitive overflow capture. Eight intent types. Decision-blocking. Promotion paths.
§16 IQ Capture
v2.0.0 · Locked · L1 · March 19, 2026
§16 Purpose
IQ Capture is the mechanism by which humans capture cognitive emergence during substrate operation. When working in the governance substrate, ideas branch, questions surface, patterns appear, and gaps become visible. These cognitive events do not attach to any single governed object — they are the overflow of active sense-making. IQ Capture provides a structured landing place for this overflow, converting tacit cognitive events into structured, investigable governance data.
IQ Capture is an extension point, not a primitive. The DLP-Core protocol defines the emergence capture requirement through behavioral invariant B9 (§5): every resolved Investigative Query must produce a Decision. The ProtoLex Substrate provides the implementation — intent types, origin types, routing logic, lifecycle management, and promotion paths. IQ is not one of the 19 primitives (§4); it is an operational mechanism that operates on primitives through promotion: a resolved IQ can produce Work, Decision, or Intent primitives.
§16 Foundation
§14 provides the parent capture framework. This section specifies IQ Capture as the second of two concrete capture mechanisms. Signal Capture (§15) specifies the first. IQ Capture serves a single architectural purpose: preventing organizational amnesia. Ideas, questions, patterns, and gaps that surface during governance operation are captured rather than lost. IQ is the exhaust valve for cognitive overflow — not an add-on feature, but part of the operating experience.
§16 Governance
No governance authority distinct from lineage for this document.
§16 Substance
§16.1 IQ Capture Definition
Table 16.1.1: IQ Capture Boundary
| IQ Capture IS | IQ Capture IS NOT |
|---|---|
| Emergence-oriented — "something surfaced that needs a home" | A flag that something is wrong — use Signal Capture (§15) for object-level problems |
| Generative — creating new investigative threads from cognitive events | A complaint mechanism or support ticket |
| Context-anchored or free-floating — may reference origin context or stand alone | Object-anchored — signals require a specific flagged object; IQs do not |
| Optionally attached to any governed object | A bug report — defects in governed objects are Signal territory |
| Routed to an investigator (self, domain expert, or object authority) | Routed to the flagged object's authority chain — that is Signal routing (B8) |
Distinction from Signal Capture. Signal Capture (§15) flags problems with existing objects — "THIS thing is wrong." IQ Capture surfaces cognitive overflow — "something emerged that needs a home." The mechanisms are parallel, not subordinate (§14.5). A signal is reactive and object-attached. An IQ is generative and context-attached or free-floating.
Six design principles govern IQ Capture:
- Zero friction. One entry (observation text) to complete capture. Intent type selection and context are available but never required for submission.
- Always available. IQ Capture is globally accessible from any point in the substrate. Every screen MUST include a global capture entry point.
- Structurally typed. Eight intent types classify the cognitive event and inform routing. Categories map to resolution paths.
- Optionally deep. Priority, assignment, linked objects, and rich context are available but optional. Capture MUST succeed at minimum effort.
- Context preserved. A snapshot of the user's working context at capture time is recorded with every IQ. This snapshot is immutable — it preserves what the human was working on at the moment of capture.
- Investigator-routed. IQs route to an investigator — self-assignment by default for personal inquiry, domain expert or object authority for validation and challenge types.
§16.2 Intent Types
Eight intent types classify the cognitive event that triggered the capture. The first six are first-order intent types: they capture cognitive emergence about the governed world. The last two are second-order intent types (§14.6): they capture concerns about the capture process itself. All eight use the same IQ lifecycle.
Table 16.2.1: Intent Type Definitions
| Intent Type | Description | Typical Prompt | Eventual Resolution |
|---|---|---|---|
explore | Curiosity, hypothesis generation | "I wonder if..." | Research → Claim or dismissal |
validate | Verification need, doubt about a current state | "Is this actually true?" | Confirm or refute → Claim |
disambiguate | Semantic confusion, unclear meaning | "What does this mean exactly?" | Clarification → Definition |
fill_gap | Missing information detected | "We don't know X yet" | Research → Evidence |
challenge | Active dispute, suspected error | "I suspect this is wrong" | Investigation → Restatement |
connect | Pattern recognition, relationship sensed | "This relates to something else" | Link discovery or dismissal |
branch_inventory | Multiple threads emerged during a session or decision boundary | Session boundary, complex input | Thread triage: pursued, parked, dropped, merged, or promoted |
confidence_probe | Gap between stated and felt confidence | Behavioral trigger detection | Disposition clarity: settled, parked, provisional, or needs revisit |
Branch inventory specifics. Branch inventory IQs record all detected threads from a session or decision boundary. Each thread receives a disposition: pursued, parked, dropped, merged, or promoted. The capture method records how the inventory was generated: explicit (human volunteers), prompted (system asks at boundary), or detected (agent identifies and proposes for human confirmation). Branch inventories MUST record all detected threads, not only those pursued. Dropped threads MUST have a disposition recorded, even if the disposition is "unknown."
Confidence probe specifics. Confidence probe IQs are agent-initiated under Assistive posture — the agent detects behavioral signals (short acknowledgments, quick topic changes, circling without landing, compound questions) and prompts the human. The probe is opt-in: the human may dismiss without responding. Dismissal is itself recorded as a disposition — no response is not no data. When a response is received, a confidence adjustment may be recorded (before/after confidence levels with reason). The agent cannot record a disposition on the human's behalf. The human remains the sensor; the agent amplifies the sensor's sensitivity. No autonomy escalation is permitted.
§16.3 Origin Types
Four origin types classify how an IQ was created. Each origin type carries different context and determines default routing.
Table 16.3.1: Origin Type Definitions
| Origin Type | Source | Default Routing | Context Captured |
|---|---|---|---|
claim | Spawned from claim adjudication (§6.5) — a question surfaces during claim review | Route to claim reviewer | Claim identity, claim state at spawn time, evidence references |
signal | Spawned from signal processing (§15) — deeper investigation required | Route to signal's authority holder | Signal identity, signal type, flagged object identity and state |
capture | Direct human capture — global or contextual entry point | Route to capturer (self-assign default) | Current work context: origin URL, object type and identity if contextual, session identity |
workflow | System-generated from workflow trigger — a workflow step surfaces a gap | Route per workflow routing rules | Workflow identity, trigger condition, workflow state at trigger time |
Table 16.3.2: Routing Defaults by Intent Type
| Intent Type | Default Assignment | Rationale |
|---|---|---|
explore | Self | Personal curiosity, low urgency |
validate | Object authority | Verification requires authoritative answer |
disambiguate | Domain expert pool | Semantic questions need expertise |
fill_gap | Self or research function | Information gathering |
challenge | Object authority | Disputes need authoritative review |
connect | Self | Pattern connection is personal insight |
branch_inventory | Self | Session-boundary reflection is personal |
confidence_probe | Self | Agent-initiated but human-decided disposition |
Origin type determines the initial routing target. Intent type refines assignment within that routing context. When origin type and intent type routing defaults conflict, origin type takes precedence for the routing target; intent type informs the assignment method within that target's scope.
§16.4 IQ Schema
The IQ schema defines field requirements at the architectural level. Substrate implementations MUST provide these fields; they MAY extend with additional fields.
Table 16.4.1: IQ Schema — Required Fields
| Field | Type | Immutable | Description |
|---|---|---|---|
iq_id | Identifier | From creation | Unique IQ identifier |
capture_text | Text | From creation | The human's articulation of the cognitive event — IMMUTABLE; original preserved exactly as captured |
intent_type | Enumeration (8 types) | From creation | Cognitive event classification — one of the eight intent types (§16.2) |
origin_type | Enumeration (4 types) | From creation | Creation source — one of the four origin types (§16.3) |
raised_by | Reference → Entity | From creation | The human who captured the IQ |
raised_at | Timestamp | From creation | When the IQ was captured |
status | Enumeration (7 states) | No | Current lifecycle state — see §16.5 |
capture_context | Object | From creation | Origin context at capture time — IMMUTABLE (see Table 16.4.3) |
Table 16.4.2: IQ Schema — Optional Fields
| Field | Type | Immutable | Description |
|---|---|---|---|
assigned_to | Reference → Entity | No | Current investigator — updated on assignment and reassignment |
resolution | Object | From resolution | Resolution record: summary, resolver identity, timestamp, linked artifacts, resolution_decision_id |
promoted_to | Array of References | From promotion | Work, Decision, or Intent primitives created by promotion — each entry records target_type and target_id |
superseded_by | Reference → IQ | From supersession | The IQ that absorbed or replaced this one |
parent_signal_id | Reference → Signal | From creation | Source signal identity, when origin_type = "signal" |
parent_claim_id | Reference → Claim | From creation | Source claim identity, when origin_type = "claim" |
blocking_decision_id | Reference → Decision | From creation | Decision this IQ blocks, when created from a decision context (§16.6) |
capture_text_versions | Array of Objects | Append-only | Edit history: each entry records version_text, edited_by, edited_at |
related_iqs | Array of References | No | Links to related IQs for cross-referencing |
Table 16.4.3: Capture Context Schema
| Field | Requirement | Description |
|---|---|---|
origin_url | REQUIRED | The URL or screen the human was viewing at capture time |
origin_object_type | OPTIONAL | Primitive type of the object in view, if contextual capture |
origin_object_id | OPTIONAL | Identifier of the object in view, if contextual capture |
origin_object_label | OPTIONAL | Human-readable label of the object in view |
session_id | REQUIRED | Session identifier for continuity tracking |
captured_at | REQUIRED | Timestamp of context capture |
Immutability constraint. Capture text is IMMUTABLE. The original human articulation is preserved exactly as captured. Edits create new versions appended to capture_text_versions with editor identity and timestamp. The original capture_text field is never modified. This ensures the original cognitive event is never retroactively rewritten — the governance record preserves what was articulated at the moment of emergence.
Progressive immutability. Fields set at creation (capture text, intent type, origin type, attribution, capture context) are never modified. Fields set during processing (assignment, resolution, promotion) are immutable from their assignment point. This mirrors the progressive immutability model of Signal Capture (§15.4).
§16.5 IQ Lifecycle
The IQ lifecycle governs instances from capture through resolution, promotion, abandonment, or supersession. The authoritative lifecycle specification is the state machine companion (v9/state-machines/iq-lifecycle.md); this subsection provides the architectural summary.
Seven states. Three terminal, one soft-terminal.
Table 16.5.1: IQ Lifecycle Summary
| State | Entry Condition | Exit Transitions | Authority Required |
|---|---|---|---|
| Open | IQ created via capture event, signal spawn, claim spawn, or workflow trigger | → Assigned (investigator designated) or → Superseded, → Abandoned | None — any human may capture an IQ |
| Assigned | Investigator designated (self, routed, or manual) | → Investigating (work begins) or → Assigned (reassignment) or → Superseded, → Abandoned | System (auto-route) or any authorized actor |
| Investigating | Investigator begins active work | → Resolved, → Promoted, → Abandoned or → Assigned (return to pool) or → Superseded | Assigned investigator |
| Resolved | Answer found and documented | Soft-terminal: → Open (reversion on new information) | Assigned investigator |
| Promoted | IQ converted to one or more primitives (Work, Decision, Intent) | Terminal | Assigned investigator |
| Abandoned | IQ determined no longer relevant | Terminal | Assigned investigator or IQ authority |
| Superseded | Another IQ absorbs or replaces this one | Terminal | IQ authority or superseding IQ's investigator |
Soft-terminal: Resolved. A resolved IQ MAY be re-opened if new information surfaces that contradicts or materially extends the original findings. Re-opening transitions the IQ back to Open and creates a new investigation cycle. The original resolution record is preserved (append-only). If the question resurfaces after a promoted IQ, a new IQ is created — promoted IQs cannot revert.
Terminal: Promoted, Abandoned, Superseded. Promoted IQs have been operationalized into primitives; further questions create new IQs. Abandoned IQs carry documented rationale; if the question resurfaces, a new IQ is created with a link to the abandoned predecessor. Superseded IQs link to the superseding IQ that inherited their investigation context.
Table 16.5.2: Resolution Paths
| Path | From State | To State | What Happens | Required Artifacts |
|---|---|---|---|---|
| Resolved (answer found) | Investigating | Resolved | Investigation complete; findings documented; may produce Claims entering graduation (§6.5) at stage Asserted | Resolution summary, resolver identity, timestamp, resolution_decision_id, linked claims (if any) |
| Promoted to Work | Investigating | Promoted | Investigation reveals effort is required — task decomposition, resource allocation, or execution beyond simple inquiry | promotion_targets[] with target_type = "Work" and target_id, promotion rationale, resolution_decision_id |
| Promoted to Decision | Investigating | Promoted | Investigation reveals a choice point — the question cannot be resolved by research alone | promotion_targets[] with target_type = "Decision" and target_id, promotion rationale, resolution_decision_id |
| Promoted to Intent | Investigating | Promoted | Investigation reveals a strategic gap — an organizational objective not yet formally captured | promotion_targets[] with target_type = "Intent" and target_id, promotion rationale, resolution_decision_id |
| Abandoned | Any active state | Abandoned | IQ determined no longer relevant | Abandonment rationale, resolver identity, timestamp, resolution_decision_id |
| Superseded | Any active state | Superseded | Another IQ absorbs this one | Superseding IQ identity, supersession rationale, resolution_decision_id |
B9 enforcement. Every terminal transition — Resolved, Promoted, Abandoned, Superseded — MUST produce a resolution_decision_id pointing to a Decision primitive (§4.1) that records the governance act of resolving the IQ. The resolution act IS a governance decision: it links to an Account (B4), is legitimized by the resolver's Authority (B5), and produces an Evidence record (the resolution summary) with truth type Declared (§6). This ensures no IQ resolution is invisible to the governance record. An IQ that reaches a terminal state without a resolution_decision_id is a B9 violation.
Multiple promotion. A single IQ MAY produce multiple promotion targets simultaneously when the investigation reveals compound findings. An IQ exploring a compliance gap might simultaneously produce a Work item to remediate the gap, a Decision to choose between remediation approaches, and an Intent to formalize a new compliance objective. Each target is recorded in the promotion_targets[] array. The single resolution_decision_id covers the governance act of the composite promotion.
Promotion invariant requirements. Promoted primitives MUST satisfy their own behavioral invariants independently: Work requires Commitment (B1), Decision requires Account (B4). The IQ's investigation context becomes part of the promoted primitive's evidentiary basis, but the promoted primitive carries its own governance obligations.
§16.6 Decision-Blocking Interaction
IQs interact with the Decision lifecycle through a blocking mechanism. When a Decision participant identifies an investigation need, the formal mechanism ensures the Decision waits for findings rather than proceeding with incomplete information.
Blocking flow. A Decision participant says "I need to investigate first." An IQ is created with origin_type = "capture" and blocking_decision_id pointing to the Decision. The Decision enters a blocked state — pending, blocked by the open IQ. The IQ proceeds through its lifecycle normally (Open → Assigned → Investigating → terminal). When the IQ reaches any terminal state (Resolved, Promoted, or Abandoned), the Decision is unblocked. IQ findings are available as evidence input to the Decision.
Table 16.6.1: Decision-Blocking Constraints
| Constraint | Rule | Rationale |
|---|---|---|
| Blocking is voluntary | The actor chooses to create a blocking IQ; the system does not auto-block | Investigation need is a human judgment, not a system determination |
| One-to-many | A single Decision can be blocked by multiple IQs; all must resolve before the Decision unblocks | Multiple investigation needs may exist for a single Decision |
| Abandonment unblocks | If a blocking IQ is abandoned, the Decision unblocks | The investigation was deemed unnecessary; the Decision can proceed |
| Supersession transfers | If a blocking IQ is superseded, the block transfers to the superseding IQ | The investigation continues under a different IQ; the blocking relationship follows |
| Promotion unblocks | If a blocking IQ is promoted to a Decision, the original blocked Decision unblocks | The promoted Decision is a new governance object; the original Decision is no longer blocked |
| IQ findings as evidence | When a blocking IQ resolves, its findings enter the Decision's evidence basis | The Decision proceeds with the investigation context the participant needed |
Distinction between resolution_decision_id and promoted Decision. The resolution_decision_id records the governance act of resolving the IQ — it is the Decision that says "we investigated and here is what we found." A promoted Decision is a new governance object representing the choice point the IQ revealed. These are two distinct Decision instances. The first closes the IQ; the second opens a new governance thread.
§16.7 Capture Entry Points
IQ Capture MUST be accessible from two classes of entry point: global (available from any substrate screen) and contextual (available from specific governed object views with auto-filled origin context).
Table 16.7.1: Global Capture Entry Points
| Location | Trigger | Context Captured |
|---|---|---|
| Header or navigation bar | Persistent capture icon | Current URL, timestamp, session identity |
| Command palette | Capture command or keyword | Current URL, timestamp, session identity |
| Mobile floating action | Capture action button | Current screen, timestamp, session identity |
Table 16.7.2: Contextual Capture Entry Points
| Context | Trigger | Additional Context |
|---|---|---|
| During Work execution | "Something came up" action on the Work view | Work item identity and state |
| During Decision making | "I need to investigate first" action on the Decision view | Decision in progress, trigger context, blocking relationship auto-created |
| During Evidence review | "This raises a question" action on the Evidence view | Evidence item identity, associated claim if applicable |
| From dashboard or monitoring | Quick capture from monitoring view | Dashboard state, active filters |
| From agent interaction | "Agent noticed → Human interprets" — agent surfaces a pattern; human captures interpretation | Agent observation, pattern detected, agent identity |
DESIGN SPACE: UI patterns — icon choice, keyboard shortcuts, button placement, modal flow — are implementation decisions. The architecture requires two capabilities: (a) global access from any substrate screen, and (b) contextual access from any governed object view that auto-fills origin context. Substrate implementations MUST satisfy both. They MAY choose any UI pattern that meets the zero-friction and always-available design principles (§16.1).
§16.8 Governance Constraints
Five governance constraints ensure that IQ Capture maintains structural integrity across the capture, investigation, and resolution lifecycle.
Table 16.8.1: IQ Governance Rules
| Rule | Constraint | Rationale |
|---|---|---|
| Capture text immutability | Original capture_text is write-once; edits create new versions in capture_text_versions[] with editor identity and timestamp | Protects the original cognitive event from retroactive rewriting — the governance record preserves what was articulated at the moment of emergence |
| Resolution requirements | Every terminal transition MUST record: resolution summary, resolver identity, timestamp, linked artifacts, and resolution_decision_id | Ensures every IQ resolution is a traceable governance act (B9); no IQ is informally dismissed |
| Pattern privacy | IQ capture patterns by user MUST NOT be used for performance evaluation, supervisor visibility without explicit consent, or aggregation that identifies individuals | Prevents chilling effect on emergence capture — the mechanism requires that humans feel safe asking questions without fear of judgment |
| Re-opening rules | A Resolved IQ MAY be re-opened with documented rationale and new evidence reference; re-opening creates a new investigation cycle with original resolution preserved | Maintains audit trail while allowing new information to reactivate investigation |
| Promotion traceability | Every promoted primitive MUST link back to its source IQ via origin_iq_id; the IQ MUST record the promoted primitive via promoted_to[] | Preserves bidirectional lineage from cognitive emergence through investigation to organizational action |
Priority inference. Four conditions boost IQ priority:
| Condition | Priority Boost | Rationale |
|---|---|---|
| Origin is Decision in progress | +1 | IQ is blocking a Decision; timely resolution prevents governance delay |
| Origin is compliance domain | +1 | Regulatory implications warrant faster investigation |
Intent is challenge | +1 | Active dispute requires timely resolution to prevent organizational drift |
| Multiple similar IQs exist | +1 | Pattern emerging; organizational attention warranted |
Cross-mechanism interaction. IQ Capture interacts with Signal Capture (§15) at two integration points. A signal in Processing state may spawn an IQ (§15.7) when deeper investigation is required; the signal enters Monitoring and tracks the IQ's resolution. An IQ during investigation may spawn a signal when a problem with a specific governed object is discovered. Both interactions create bidirectional links for lineage traversal (§14.5).
Truth type assignment. The IQ capture act produces Authoritative truth (§6) — a human's articulation of cognitive emergence is a fact about what surfaced in their thinking. IQ resolution produces Declared truth — it represents the resolver's best current judgment. Promoted artifacts carry the truth type rules of their target primitive class (§14.4).
§16 Boundaries
IQ Capture is limited to cognitive emergence and investigation contexts. It does not create governance records directly; promotion creates records. IQ routing targets investigators, not authority chains. IQs may be context-anchored or free-floating; they do not require object attachment.
§16 Positions
Locked positions:
- IQ Capture is generative and emergence-oriented; it captures cognitive events that do not anchor to specific objects.
- All eight intent types are required; six are first-order (emergence about the governed world), two are second-order (emergence about capture itself).
- IQ capture text is immutable from creation; edits create versioned entries without modifying the original.
- Every resolved IQ MUST produce a
resolution_decision_idrecording the governance act of resolution (B9 enforcement). - IQs can spawn Signals and vice versa with bidirectional traceability.
- Resolved IQs are soft-terminal and may revert to Open if new information surfaces; Promoted/Abandoned/Superseded are hard-terminal.
- Decision-blocking is voluntary, one-to-many, and unblocks automatically when the blocking IQ reaches any terminal state.
- Promotion targets (Work, Decision, Intent) each create a primitive instance carrying its own behavioral invariants.
§16 Lineage
Version history:
- v2.0.0 (2026-03-19): Locked specification with eight intent types, four origin types, comprehensive schema with capture context, seven-state lifecycle with soft-terminal Resolved, B9 enforcement via resolution_decision_id, decision-blocking mechanism, global and contextual entry points, and governance constraints on capture immutability and pattern privacy.
Provenance:
This section defines IQ Capture as a concrete instantiation of the Capture Principle (§14.1) with full intent/origin taxonomy, schema, lifecycle, blocking interaction, entry points, and governance constraints. It specifies behavioral enforcement of B9 (every resolved IQ produces a Decision) with comprehensive resolution paths, promotion targets, and promotion invariants.
§16 Commitments
SDK MUST constraints:
- MUST enforce B9: every terminal transition (Resolved, Promoted, Abandoned, Superseded) produces a
resolution_decision_idpointing to a Decision primitive. - MUST provide global IQ capture entry points on every substrate screen.
- MUST provide contextual IQ capture entry points with auto-filled origin context on all governed object views.
- MUST preserve capture text immutability: original capture is write-once; modifications create versioned entries in
capture_text_versions[]. - MUST preserve capture context immutability: origin context snapshots are immutable from creation.
- MUST implement eight intent types with first-order/second-order classification.
- MUST implement four origin types with type-specific routing defaults.
- MUST implement seven-state lifecycle with soft-terminal Resolved allowing reversion and hard-terminal Promoted/Abandoned/Superseded.
- MUST enforce progressive immutability: fields set at creation are never modified; fields set during processing are immutable from assignment.
- MUST support decision-blocking: IQs created with
blocking_decision_idblock the referenced Decision until the IQ reaches a terminal state. - MUST support multiple promotion: a single IQ may produce multiple promotion targets simultaneously.
- MUST enforce promotion invariants: promoted primitives satisfy their own behavioral invariants independently.
- MUST implement bidirectional signal-IQ traceability with navigable links in both directions.
- MUST preserve pattern privacy: IQ capture patterns by user MUST NOT be used for performance evaluation without explicit consent.
- MUST support IQ re-opening: Resolved IQs MAY revert to Open with documented rationale; original resolution is preserved append-only.
- MUST assign truth types: IQ capture is Authoritative; IQ resolution is Declared; promoted artifacts carry their target primitive's truth type rules.
§16 Coverage
This section provides complete coverage of:
- IQ Capture definition with boundary clarification (emergence vs. problems, generative vs. reactive).
- Eight intent types spanning first-order cognitive emergence (explore, validate, disambiguate, fill_gap, challenge, connect) and second-order lineage (branch_inventory, confidence_probe).
- Four origin types (claim, signal, capture, workflow) with type-specific routing defaults.
- Eight routing defaults by intent type with conflict resolution rules.
- IQ schema with 8 required fields and 9 optional fields covering identity, immutability, lifecycle, assignment, resolution, promotion, and traceability.
- Capture context schema with 6 fields for origin preservation.
- Immutability constraints for capture text with versioning and progressive immutability model.
- Seven-state lifecycle with entry conditions, exit transitions, and authority requirements.
- Soft-terminal Resolved state with reversion rules.
- Hard-terminal states (Promoted, Abandoned, Superseded) with lifecycle preservation.
- Six resolution paths with required artifacts for each path.
- B9 enforcement requiring
resolution_decision_idfor all terminal transitions. - Multiple promotion enabling compound findings.
- Promotion invariant requirements linking promoted primitives to source IQ and governing invariants.
- Decision-blocking interaction with voluntary blocking, one-to-many relationships, and unblock triggers.
- Global and contextual capture entry points with context capture details.
- Five governance constraints: capture text immutability, resolution requirements, pattern privacy, re-opening rules, promotion traceability.
- Priority inference rules for Decision-blocking, compliance origin, challenge intent, and pattern emergence.
- Cross-mechanism signal-IQ interactions with bidirectional traceability.
- Truth type assignment: Authoritative for capture, Declared for resolution, target-dependent for promotion.
Completeness is achieved. All IQ capture flows, investigation paths, promotion routes, decision blocking, and governance constraints are fully specified.