§27 Operation Catalog

This specification section defines implementation contracts for the Decision Lineage Protocol substrate.

The Decision Lineage Protocol substrate exposes two hundred and forty-four named operations across the nineteen primitives and ten cross-cutting operation domains. Each operation is a typed, authorized action with defined preconditions, postconditions, and invariant implications. This section specifies the complete logical contract that governs what the SDK must support; transport protocol, serialization format, and client-library ergonomics are DESIGN SPACE. The operations act on the logical schema defined in §26.

This section defines six operation types (§27.1), specifies per-primitive operation contracts organized by tier (§27.2–§27.6), catalogs cross-cutting composite operations (§27.7), consolidates the authorization matrix (§27.8), maps invariant enforcement points per operation (§27.9), and formalizes SDK constraints (§27.10).

§27.1 Operation Architecture Overview

§27.1.1 Six Operation Types

Every operation in the catalog belongs to exactly one of six types. The type determines the operation's structural role, its relationship to the primitive lifecycle, and its invariant enforcement profile.

Table 27.1.1: Operation Type Taxonomy

Create and Read are universal. Every primitive supports at minimum a Create and a Read operation. Tier 1 primitives support the full six-type range. Tier 2 primitives omit some Transition operations because their lifecycles are simpler.

Transition is the primary governed operation type. Most governance-significant actions are state machine transitions, not field updates. A Commitment does not become active by updating a status field — it becomes active through commitment.activate, which enforces B2 capacity verification, records the transition event, and triggers downstream invariant checks.

Composite operations are atomic. A composite operation either completes entirely or fails entirely. Partial completion is not a valid state. The SDK determines whether atomicity is achieved through database transactions, saga patterns, or another mechanism — this is DESIGN SPACE.

§27.1.2 Authorization Model

Every write operation — Create, Update, Delete, Transition, and Composite — requires authorization. Read operations respect depth-gated visibility (§23) but do not require explicit authorization checks beyond instance membership.

The authorization check comprises five sequential gates:

1. Authority scope. The actor holds an Authority with scope covering the operation target.
2. Authority traceability. The Authority is traceable to a root authority via the B5 delegation chain.
3. RACIVG role permission. The actor's RACIVG role for the target context permits the operation (§22.3).
4. Graduation gate. The actor's graduation stage meets the minimum required for the operation (§27.8).
5. Profile gate. The profile tier makes the operation available — some operations exist only at EAS or BAS (§27.8).

All five gates pass or the operation is rejected. There is no partial authorization. The authorization check itself produces an Authoritative audit record regardless of outcome.

§27.1.3 Truth Type Rules

All operations that produce or modify records are governed by truth type rules (§6):

Authoritative records are append-only. No field may be modified after creation. Corrections require supersession — a new record with supersedes_ref pointing to the original. The original is preserved unchanged.

Declared records are versioned. Modifications create new versions. The fields id, created_at, created_by, and truth_type are immutable across versions. Temporal bounds (effective_from, effective_to) are adjustable.

Derived records are ephemeral. They are recomputable from source data. Manual editing is prohibited. When source records change, dependent Derived records are marked stale and queued for recomputation.

Opaque records are boundary-enforced. Content behind an inspection boundary that cannot be crossed (§6.1). Opaque is system-assigned at boundary detection — no actor writes Opaque directly. Opaque records cannot be promoted through the standard Derived → Declared → Authoritative path; they transition to another truth type only when the inspection boundary is removed (§6.1, Opaque → Computed transition).

AI actors produce Derived only. All AI-generated content enters the substrate as Derived regardless of the AI actor's confidence level. Promotion to Declared requires human review. Promotion to Authoritative requires a separate human Decision with traceable Authority (B5). Truth type promotion is monotonic — no demotion path exists.

§27.1.4 Invariant Enforcement

Every write operation triggers zero or more invariant checks from the ten behavioral invariants (§5). Enforcement follows the two-pass validation strategy:

Pass 1 (SHACL Core). Single-node property checks at O(1). Invariants B1, B2, B3, B4, B5-immediate, B6-binding, and B8-core. Always Blocking — no profile may downgrade below Blocking.

Pass 2 (SHACL-SPARQL). Graph traversal and transitive closure checks. Invariants B5-T, B6-U, B8-routing, and B9. Profile-configurable enforcement mode — defaults vary by invariant and profile tier.

Schema Pass. Shapes-on-shapes validation. Invariant B7 (all objects flaggable). Runs at deployment time and schema changes, not per-operation.

Operations declare which invariants they touch. The invariant enforcement engine validates after the operation writes but before the transaction commits. If any Blocking invariant fails, the transaction rolls back.

§27.2 Tier 1 Primitive Operations

Tier 1 contains the nine irreducible core primitives (§4.1). Each primitive supports the full operation type range and participates in at least one behavioral invariant.

§27.2.1 Intent

Intent represents a stated objective — the answer to "what should happen?" An Intent lifecycle progresses through proposal, activation, and terminal resolution.

Table 27.2.1: Intent Operations

Lifecycle. draft → proposed → active ↔ paused | blocked → achieved | abandoned | superseded.

Semantic boundary: Intent declares what should happen. Commitment (§27.2.2) binds parties to do it. Work (§27.2.4) executes it. Achievement of an Intent is a governance conclusion, not a work-tracking status.

§27.2.2 Commitment

Commitment binds two or more parties to an obligation with terms and capacity allocation. The lifecycle governs negotiation, acceptance, performance, and breach.

Table 27.2.2: Commitment Operations

Lifecycle. proposed ↔ negotiating → accepted → active ↔ suspended → fulfilled | breached → terminated | expired | superseded. Cure transitions breached → active.

§27.2.3 Capacity

Capacity represents a quantified resource — time, skill, budget, authority scope — that can be allocated to Commitments. The B2 invariant ensures Commitments never exceed available Capacity.

Table 27.2.3: Capacity Operations

Lifecycle. available ↔ partially_available ↔ exhausted | blocked | reserved | replenishing.

§27.2.4 Work

Work represents effort expended in service of a Commitment. B1 enforces the structural link — every Work instance must reference exactly one Commitment. Work Specifications (SM-4) govern how AI-composed work is confirmed and promoted.

Table 27.2.4: Work Operations

Lifecycle. defined → ready → assigned ↔ in_progress ↔ blocked → review → accepted | rejected → completed | abandoned | cancelled | superseded. Rejection loops back to in_progress via work.rework.

Table 27.2.5: Work Specification Operations (SM-4)

Lifecycle (SM-4). draft → confirmed → active → completed → promoted | rejected. Stage C low-risk work may skip confirmation via work_spec.skip_confirm.

§27.2.5 Evidence

Evidence records factual artifacts — observations, measurements, documents, validation reports. Evidence is immutable after creation. The B3 invariant requires every Evidence instance to carry exactly one truth type.

Table 27.2.6: Evidence Operations

Immutability rule. Evidence records cannot be updated. Verification adds records — it does not modify the Evidence itself. Corrections require supersession: a new Evidence record that links to and replaces the original. The original is preserved. Promotion (evidence.promote) is the sole sanctioned exception to immutability: it advances the record's truth type in place — identity, verification state, and graduation stage carry (§6.6) — under the human gate (§22.3), recording a Decision + Account. All other post-creation change is supersession.

§27.2.6 Decision

Decision records a governance choice — the answer to "what was chosen and why?" Every Decision creates an Account record (B4). AI actors may produce Decision proposals as Derived content; only humans may finalize governance Decisions.

Table 27.2.7: Decision Operations

Lifecycle. draft → final → superseded | reversed | expired.

Decision zones govern AI participation. Zone 1 (Green): AI may decide autonomously at Stage C, logged, reversible, within delegation. Zone 2 (Yellow): AI prepares, human reviews within window. Zone 3 (Orange): human decides with AI support. Zone 4 (Red): human only — AI may not prepare.

§27.2.7 Authority

Authority represents the right to act — delegated or root. The B5 invariant requires every Authority to be traceable through a delegation chain terminating at a root authority. Authority is the foundation of the authorization model.

Table 27.2.8: Authority Operations

Lifecycle. pending → active ↔ suspended → expired | revoked | superseded.

Table 27.2.9: Delegation Operations (SM-5)

Lifecycle (SM-5). proposed → active ↔ modified | suspended → revoked | expired.

AI-Cannot-Be-Principal applies to all delegation writes. AI actors cannot propose, grant, modify, or revoke delegations. AI actors may query authority.can_exercise and authority.resolve_chain to inspect delegation state.

§27.2.8 Account

Account records per-event linkage between actors and their governance actions. Every Decision creates an Account entry (B4). Account records are always Authoritative and immutable.

Table 27.2.10: Account Operations

Account is per-event linkage, not aggregation. Each Account record links one actor to one governance action. Temporal framing — "what was Actor X accountable for during Period Y?" — uses Cycle queries (§28). Account records are never modified or deleted.

§27.2.9 Constraint

Constraint represents a binding rule — policy, compliance requirement, physical limitation, or organizational boundary. B6 requires every Constraint to target at least one primitive instance and specify an enforcement mode.

Table 27.2.11: Constraint Operations

Lifecycle. active ↔ suspended → deprecated.

Override protocol (§5.5). Exceptions follow a four-step protocol: (1) the overriding actor must hold Authority governing the violated primitive, (2) the override is itself a Decision requiring an Account (B4), (3) Evidence is produced as Declared truth (not Authoritative), and (4) the original violation record is preserved — overrides are append-only.

§27.3 Tier 2 Infrastructure Operations

Tier 2 contains four unconditional infrastructure primitives (Identifier, Entity, Context, Namespace) that exist in every substrate deployment regardless of profile tier (§4.5), plus Actor lifecycle operations (SM-1). These primitives support the Tier 1 governance model but do not carry MVR fields.

§27.3.1 Identifier

Identifier provides unique naming and resolution services. System-generated UUIDs carry Authoritative truth type. Human-supplied external references carry Declared truth type.

Table 27.3.1: Identifier Operations

§27.3.2 Entity and Actor

Entity represents a participant — human, organization, role, or system. Actor is the governance identity that an Entity holds within a substrate instance. Actor lifecycle operations (SM-1) govern registration, activation, suspension, and deactivation.

Table 27.3.2: Entity Operations

Table 27.3.3: Actor Operations (SM-1)

Lifecycle (SM-1). registered → active ↔ suspended → deactivated → archived.

Actor Context operations. Each actor holds an Actor Context per instance they participate in (§22.1). Actor Context supports actor_context.create, actor_context.update, and actor_context.delete. Deletion is blocked if the actor is sole Accountable for active Decisions in the instance.

§27.3.3 Context

Context provides situational framing for governance actions. Six context types — temporal, spatial, relational, situational, interpretive, and composite — classify the environment in which primitives operate.

Table 27.3.4: Context Operations

§27.3.4 Namespace

Namespace organizes primitives into hierarchical scoping domains. Four scopes — core, domain, tenant, and sandbox — govern vocabulary and concept ownership. Sandbox namespaces carry mandatory expiration.

Table 27.3.5: Namespace Operations

Lifecycle. proposed → under_review → active → graduated | expired | retired.

§27.4 Tier 3 Governed Operations

Tier 3 primitives — Orientation, Learning, and Activation — support deliberate governance posture and institutional adaptation. They activate at graduation Stage B (§4.7). All Tier 3 write operations require elevated governance authority.

§27.4.1 Orientation

Orientation declares the pre-decisional framing — values, boundaries, and harm prohibitions — that governs an entity's participation. Only one Orientation may be active per owner. AI cannot create or modify Orientation (L4 gradient level — highest deliberation).

Table 27.4.1: Orientation Operations

§27.4.2 Learning

Learning captures institutional adaptation signals — pattern observations, validations, threshold adjustments, and structural reconfigurations. Four governance levels (L1–L4) determine the deliberation required for application.

Table 27.4.2: Learning Operations

Lifecycle. detected → analyzed → applied → monitoring | rejected.

§27.4.3 Activation

Activation governs the six-stage governance pipeline (§12): discover, analyze, implement, evidence, verify, sustain. Each stage produces specific primitive outputs and enforces stage-appropriate invariants.

Table 27.4.3: Activation Operations

Status lifecycle. pending → ready → active ↔ blocked → complete.

Six-stage pipeline (§12). discover → analyze → implement → evidence → verify → sustain. Stage advancement requires both Accountable (A) and Governor (G) role confirmation at EAS. BAS supports a subset of stages.

§27.5 Tier 4 AI-Native Operations

Tier 4 primitives — Interpretation and Environment Interface — extend the substrate with AI-specific governance capabilities. They activate at graduation Stage B and are available at EAS and BAS only (§4.7).

§27.5.1 Interpretation

Interpretation captures AI-generated meaning-making — classifications, extractions, recommendations, analyses, predictions, and gap identifications. All Interpretations enter as Derived (B3). Resolution requires human action.

Table 27.5.1: Interpretation Operations

Lifecycle. pending → agent_proposed → human_review → resolved | disputed | withdrawn.

Stakes × novelty routing matrix (§4.6.3). Low × Low: Citation Fidelity (verification). Low × High: Pattern Anomaly Flag (escalation). High × Low: Reasoning Integrity (logic review). High × High: Judgment Alignment (expert interpretation) — red zone. Red-zone guard rejects promotions without evidence of substantive review (rubber-stamp detection).

§27.5.2 Environment Interface

Environment Interface connects the substrate to external systems — inbound signals, outbound actions, and feedback loops. Inbound signals enter as Derived. Outbound actions require Authority.

Table 27.5.2: Environment Interface Operations

Lifecycle. active ↔ dormant → closed.

§27.6 Tier 5 Configuration Operations

Tier 5 contains a single primitive — Cycle — that provides temporal configuration for governance rhythms. Cycle is available at EAS and BAS only.

§27.6.1 Cycle

Cycle defines recurring governance cadences — execution pulses, activation sweeps, weekly reviews, learning integrations, orientation checks, and commitment reconciliations. Every cycle's decision step requires sense_maker = human.

Table 27.6.1: Cycle Operations

Lifecycle. scheduled → running → completed | skipped | failed.

§27.7 Cross-Cutting Operations

Ten cross-cutting operation domains define composite operations that span multiple primitives. Six primary domains — signals (§14–§15), IQs (§16), VPs (§17), governance activation (§12), orchestration (§A1–§A2), and KPIs — address governance concerns that no single primitive handles alone. Four additional domains — profile/portfolio management, graduation, agent behavioral cycles, and ontology alignment — provide lifecycle and integration operations.

§27.7.1 Signal Operations

Signals implement the algedonic channel — the mechanism for surfacing problems at any governance level. B7 guarantees that all nineteen primitive classes have a signal attachment surface. B8 guarantees that every signal routes to an authority on the governance chain.

Table 27.7.1: Signal Operations

Lifecycle (SM-7). created → routed → processing → escalated → monitoring → resolved | dismissed.

Any actor may raise a signal. Resolution and dismissal require a Decision (B4) by an actor with authority over the flagged object.

§27.7.2 IQ Operations

Investigative Queries operationalize emergence — the process by which questions arising from governance activity become institutional knowledge. B9 guarantees that every resolved IQ produces a Decision or Work item.

Table 27.7.2: IQ Operations

Lifecycle (SM-8). open → assigned → investigating → resolved → promoted | abandoned | superseded. Reversion: resolved → open.

Zero friction, globally accessible. IQ creation has no authorization gate beyond instance membership. The cost of a question is always lower than the cost of an unasked question.

§27.7.3 VP Operations

Validated Projections materialize derived views from source primitives — plan baselines, condition assessments, and predictions. All VPs carry truth type Derived (B3). No human approval is required for materialization.

Table 27.7.3: VP Operations

Cache states (SM-9). current → stale → recomputing → current | invalidated.

Invalidation cascade. Plan Baseline invalidation immediately invalidates dependent Condition Assessments, which immediately invalidates dependent Predictions. Staleness propagates differently — stale records may be recomputed; invalidated records cannot.

VP disposition routing. When a Condition Assessment reveals deviation, the disposition determines the governance response: investigate (creates Work), re-evaluate plan (creates Decision + recomputation), compensate (creates Constraint exception), acknowledge (creates Evidence + scheduled review), escalate (routes Decision by Authority), accept risk (creates Learning + Decision), remediate (creates corrective Work), defer (schedules future assessment), or no action (audit log entry only).

§27.7.4 Governance Activation Operations

Governance Activation implements the six-stage pipeline (§12) that discovers, projects, and closes governance gaps. Each stage is a composite operation producing specific primitive outputs.

Table 27.7.4: Governance Activation Operations

§27.7.5 Orchestration Operations

The seven-step orchestration engine (§A1, §A2) classifies cognitive work, activates constraints, routes to actors, selects within delegation bounds, composes Work Specifications, confirms with human oversight, and emits to the execution layer.

Table 27.7.5: Orchestration Operations

AICAR classification operations. aicar.classify_work classifies cognitive work into A/B/C/D components, supporting composite classifications (A+B+C). aicar.extend_type registers new derivative types under human approval; derivatives inherit parent properties and cannot modify them (taxonomy closure).

Delegation-as-Composition. delegation.compose is a composite operation that assembles Intent + Authority + Commitment + Constraint + Work + Context into a coherent delegation envelope. AI-Cannot-Be-Principal. B1/B2/B5 enforced.

§27.7.6 KPI Operations

KPI operations govern the introduction, retirement, and monitoring of governance health indicators. Three KPI classes — Invariant Signal (IS), Control KPI (CKPI), and Intent Progress Indicator (IPI) — serve distinct governance rhythms.

Table 27.7.6: KPI Operations

§27.7.7 Profile and Portfolio Operations

Profile operations govern instance creation and graduation across the three profile tiers (§21, §23). Portfolio operations manage recursive parent-child instance relationships with tighten-only constraint monotonicity.

Table 27.7.7: Profile and Portfolio Operations

§27.7.8 Graduation Operations

Graduation operations manage the per-scope AI governance maturity model (§8, §A1, SM-2). Graduation is per-scope — each AICAR type × Decision type × domain namespace has an independent graduation stage.

Table 27.7.8: Graduation Operations

Stage criteria thresholds. Stage A → A+: sufficient interactions accumulated over a sufficient observation period, across a sufficient diversity of work contexts and human review decisions. Stage A+ → B: further accumulated interactions, validated patterns promoted to Declared, multiple registered actors. Stage B → C: sustained confirmation rate over a sustained observation period. Stage C maintenance: sustained accuracy, low rejection rate, stable escalation frequency. Specific threshold values are substrate-level reference defaults, not protocol commitments — see ../reference-defaults/calibration-parameters.md §§5–6.

§27.7.9 Agent Behavioral Cycle Operations

The agent behavioral cycle (SM-6) governs how AI actors operate within the substrate. Three tracks — monitoring (Stage A), navigation (Stage A+/B), and execution (Stage C) — are gated by graduation stage.

Table 27.7.9: Agent Behavioral Cycle Operations

Cycle states (SM-6). LISTENING → CONTEXT_LOADING → NAVIGATING | MONITORING | EXECUTING → PROPOSING | ALERTING | COMPLETING → LISTENING. The cycle is non-terminating — agents return to LISTENING after completing each pass.

§27.7.10 Ontology Alignment Operations

Ontology alignment operations (§18, §19) manage the Knowledge Integration pipeline that maps external domain concepts to the substrate's nineteen-primitive model.

Table 27.7.10: Ontology Alignment Operations

§27.8 Authorization Matrix

The authorization matrix maps every write operation to actor type, minimum RACIVG role, minimum graduation stage, and profile tier availability. This section provides the consolidated summary.

§27.8.1 Actor Type Permissions

Four actor types (§22.2) participate in operations with distinct permission boundaries. Permission values: P = Permitted, X = Prohibited, C = Conditional (conditions specified per operation).

Table 27.8.1: Actor Type Permission Summary

§27.8.2 RACIVG Role Requirements

Operations that modify governance state require specific RACIVG roles. The role requirement varies by profile tier: EAS uses all six roles (RACIVG), BAS uses four (RACI), PAS uses two (Owner/Collaborator mapped to R and A).

Table 27.8.2: RACIVG Minimum Role by Operation Category

Exactly one A per context. No governance context may have zero or multiple Accountable parties. The A role is always human (§22.3).

G role for policy implications. When an operation implicates Constraints or Orientation, the Governor (G) role must participate. G is EAS-only; BAS and PAS approximate through the A role.

V role for evidence requirements. When an operation requires Evidence evaluation, the Verifier (V) role must participate. V is EAS-only.

§27.8.3 Graduation Gates

Some operations require a minimum graduation stage. Graduation is per-scope: AICAR type × Decision type × domain namespace (§8, §A1).

Table 27.8.3: Graduation-Gated Operations

No stage skipping. Graduation advances one stage at a time: A → A+ → B → C. Auto-regression may drop to the immediate predecessor stage only. Human-initiated regression may drop to any lower stage.

§27.8.4 Profile Tier Availability

Some operations are available only at specific profile tiers. PAS is the most restricted; EAS is the most permissive.

Table 27.8.4: Profile-Restricted Operations

§27.9 Invariant Enforcement Points

Each behavioral invariant (§5) is triggered by a specific set of operations. This section maps invariants to their triggering operations, validation pass, enforcement timing, and override availability.

The trigger tables below list the operations whose primary purpose intersects the invariant — the operations where the invariant check is structurally essential to the operation's postconditions. Any operation that produces a Decision also triggers B4; the B4 table lists the operation categories rather than enumerating every Decision-producing operation individually. The per-primitive operation tables in §27.2–§27.6 are authoritative for the complete invariant profile of each operation.

§27.9.1 B1 — Work Requires Commitment

Every Work instance must link to exactly one Commitment. Prevents shadow work.

Shape: dlps:B1-WorkRequiresCommitment Pass: 1 (Core). Always Blocking. Override: None. No override mechanism exists for B1.

Table 27.9.1: B1 Triggering Operations

§27.9.2 B2 — Commitment Requires Capacity

Every Commitment must link to at least one Capacity allocation. Prevents impossible promises.

Shape: dlps:B2-CommitmentRequiresCapacity Pass: 1 (Core). Always Blocking. Override: None.

Table 27.9.2: B2 Triggering Operations

§27.9.3 B3 — Evidence Requires Truth Type

Every Evidence instance must carry exactly one truth type from the four-value vocabulary (Authoritative, Declared, Derived, Opaque — §6.1). All AI-generated content enters as Derived. Opaque is system-assigned at boundary detection. Prevents epistemic corruption.

Shape: dlps:B3-EvidenceRequiresTruthType Pass: 1 (Core). Always Blocking. Override: None.

Table 27.9.3: B3 Triggering Operations

§27.9.4 B4 — Decision Requires Account

Every Decision must link to exactly one Account. Prevents context-free decisions.

Shape: dlps:B4-DecisionRequiresAccount Pass: 1 (Core). Always Blocking. Override: None.

Table 27.9.4: B4 Triggering Operations

§27.9.5 B5 — Authority Must Be Traceable

Every Authority must be root or link through a delegation chain terminating at root. Prevents untraceable authority.

Two shapes with different enforcement profiles:

B5-immediate (Pass 1, Always Blocking). Shape dlps:B5-AuthorityTraceable. Checks: isRootAuthority = true OR delegated_from present. O(1).

B5-T (Pass 2, Default Blocking). Shape dlps:B5-AuthorityChainReachesRoot. Checks: transitive closure to root; detects circular delegation. O(chain depth). May be downgraded to Warning during bootstrapping only — not below Logging.

Table 27.9.5: B5 Triggering Operations

Profile variability. EAS and BAS: B5-T is Blocking (Warning during bootstrap only). PAS: B5-T is Warning.

§27.9.6 B6 — Constraint Binds Primitives

Every Constraint must target at least one primitive instance and specify an enforcement mode.

Two shapes:

B6-binding (Pass 1, Always Blocking). Shape dlps:B6-ConstraintBindsPrimitives. Checks: applies_to non-empty AND enforcement_mode in vocabulary. O(1).

B6-U (Pass 2, Default Warning). Shape dlps:B6-ConstraintUniversality. Checks: universal Constraint targets all instances of governed class. O(instances of target class). Override available via §5.5.

Table 27.9.6: B6 Triggering Operations

Profile variability. B6-binding: Blocking at all tiers. B6-U: EAS = Warning (may upgrade for regulatory domains), BAS = Warning, PAS = Logging.

§27.9.7 B7 — All Objects Flaggable

Every primitive class (all nineteen) must have a signal attachment surface. Prevents invisible problems.

Shape: dlps:B7-SignalSurfaceCoverage Pass: Schema Pass (deployment-time). O(19). Override: None. Deployment is halted until corrected.

Table 27.9.7: B7 Triggering Events

Profile variability. Blocking at all profiles. EAS: all nineteen classes. BAS: Tiers 1–3 minimum. PAS: Tiers 1–2 minimum.

§27.9.8 B8 — Signals Route to Authority

Every Signal must route to an authority on the governance chain for the flagged object.

Two components:

B8-core (Pass 1, Always Blocking). Shape dlps:B8-SignalsRouteToAuthority (core). Checks: routed_to is not null and resolves to Authority. O(1).

B8-routing (Pass 2, Default Warning). Shape dlps:B8-SignalsRouteToAuthority (SPARQL). Checks: target is on the flagged object's authority chain at any depth. O(chain depth). Routing outside the chain is a violation; routing to a higher level on the correct chain is valid.

Table 27.9.8: B8 Triggering Operations

Profile variability. B8-core: Blocking at all tiers. B8-routing: EAS = Warning (may upgrade for regulated domains), BAS = Warning, PAS = Logging.

§27.9.9 B9 — IQ Resolution Creates Decision

Every resolved IQ must produce a Decision or Work item. Prevents inert emergence.

Shape: dlps:B9-IQResolutionCreatesDecision Pass: 2 (SPARQL). Default Warning. O(1) per resolved IQ. Override: Available via §5.5, rarely needed since abandonment (a Decision to not act) satisfies B9.

Table 27.9.9: B9 Triggering Operations

Profile variability. EAS = Warning (may upgrade to Blocking for high-governance domains), BAS = Warning, PAS = Logging.

§27.9.10 Enforcement Summary

Table 27.9.10: Invariant Enforcement Profile Matrix

Reading this table. Pass 1 shapes are universally Blocking — no profile may downgrade them. Pass 2 shapes decrease in strictness from EAS through PAS. No invariant may be downgraded below Logging for any profile. The Schema Pass (B7) runs at deployment time and is universally Blocking.

§27.10 SDK Constraints

Table 27.10.1: §27 SDK Constraints

§27.11 Terminology

§27.12 Cross-References

Scope

Scope limited to logical operation contracts. Transport protocol, serialization format, and implementation languages are DESIGN SPACE.

Implementation Requirements

SDK implementations MUST respect all invariant shapes, enforce truth type boundaries, and validate all constraints at specified passes. Specification is immutable during lock period. SHACL two-pass validation is mandatory. Truth type boundaries are preserved through all operations. Session isolation is required for all writes.