§28 Query Architecture

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

The Decision Lineage Protocol substrate is AI-native infrastructure. Humans express intent in natural language; AI translates to substrate queries. No user — human or AI agent — writes Cypher or SQL directly. The query architecture defines a pattern-based query model with forty-four named patterns across eleven domain families, a dual-language execution strategy (Cypher for graph traversal, SQL for relational operations), canonical return structures with mandatory truth type metadata, an AI query generation layer that maps natural language to parameterized templates, and a three-format interchange layer exposing query results to external consumers.

This section specifies the query contracts — inputs, outputs, traversal semantics, governance constraints, and interchange mappings — that the SDK must implement. The forty-four patterns read the state produced by the two hundred and forty-four operations defined in §27. Transport protocol, wire format, and client-library ergonomics are DESIGN SPACE.

§28.1 Query Architecture Overview

§28.1.1 Design Principles

The query architecture rests on five principles:

Pattern-based query model. Every query the substrate supports maps to a named pattern with typed inputs, a defined traversal strategy, a canonical return structure, and explicit governance constraints. Ad-hoc queries do not exist. AI agents and SDK consumers select patterns, supply parameters, and receive structured results. The pattern library is the complete query surface.

AI-native interface. The primary query interface is natural language. Humans describe what they want; the AI query generation layer identifies the matching pattern, extracts parameters, validates constraints, and executes the query. The AI layer never constructs raw query strings — it fills parameters into pre-validated templates.

Dual-language execution. The substrate uses two query languages with an architectural boundary. Cypher (Apache AGE) handles graph traversals — variable-depth paths along the thirteen cross-primitive relationships defined in §4.4. SQL (PostgreSQL) handles relational operations — lookups, filters, aggregations, and joins on fixed-schema tables. Hybrid patterns compose results from both engines at the SDK layer. The boundary is stable: if a pattern traverses variable-depth paths, it requires Cypher; everything else is SQL.

Truth type transparency. Every query result carries truth type metadata — truth_type, verification_state, and record_lifecycle_state — on every returned record. Consumers always know the epistemic status of the data they receive. Derived content is never presented as canonical without explicit marking.

Three interchange formats. Query results are exposed through three formats: MCP Server for AI agent interaction, JSON Export for integration pipelines, and RDF/OWL Export for formal compliance and archival. Not all patterns require all formats — internal governance patterns (scope validation, principal enforcement) are SDK-only.

§28.1.2 Query Stack

The query stack comprises four layers:

Table 28.1.1: Query Stack Layers

The AI Generation layer sits between the human and the query engine. It translates intent to parameterized templates, validates parameters against the substrate schema, enforces depth limits and access control, and handles disambiguation when multiple patterns match a natural language query.

§28.1.3 Pattern-to-Operation Correspondence

The forty-four query patterns read state produced by the two hundred and forty-four operations defined in §27 and the seventy-two cross-cutting operations spanning multiple primitives. Every operation postcondition creates or modifies queryable state:

• Create operations produce records queryable by truth type filter (QP-TRU-01) and domain-specific patterns.
• Transition operations advance lifecycle state queryable by status-filtered patterns (QP-ORC-01, QP-SIG-01, QP-SIG-02, QP-TMP-01).
• Composite operations produce multi-primitive state queryable by graph traversal patterns (QP-AUTH-01 through QP-LIN-04) and governance state patterns (QP-GOV-01 through QP-GOV-05).
• Invariant enforcement produces validation reports queryable by QP-INV-01 and QP-INV-02.
• KPI operations produce measurement records queryable by QP-KPI-01 through QP-KPI-03.

No operation produces state that falls outside the forty-four pattern query surface.

§28.2 Dual-Language Strategy

§28.2.1 Language Selection

The substrate query engine uses two languages, each selected for a distinct structural reason.

Cypher (Apache AGE) handles graph traversals — queries that follow variable-depth paths along the thirteen cross-primitive relationships (§4.4). Authority delegation chains, decision lineage traces, impact radius computations, escalation path resolutions, and recursive instance hierarchies are graph-native operations. Cypher expresses these as declarative path patterns with per-hop filtering and depth control. Apache AGE runs as a PostgreSQL extension, keeping both languages within a single database system.

SQL (PostgreSQL) handles relational operations — lookups on fixed-schema tables, filtered queries with known join paths, aggregations, and temporal reconstructions. Governance state queries, truth type filtering, actor context loading, work specification retrieval, KPI metrics, and cycle management are relational by nature. SQL's mature optimization, window functions, and aggregation capabilities serve these patterns directly.

§28.2.2 Classification Rule

The classification rule is deterministic: if a pattern traverses variable-depth paths along cross-primitive relationships, it is Cypher-required. If it performs lookups, filters, or aggregations on fixed-schema tables with known joins, it is SQL-eligible. If it combines both, it is Hybrid-required.

Table 28.2.1: Language Classification Summary

§28.2.3 Language Distribution by Domain

Graph traversal concentrates in two domain families. Authority & Delegation and Decision Lineage account for seven of ten Cypher-required patterns. This reflects the substrate's core structural insight: authority chains and decision lineage are inherently graph problems — they involve variable-depth paths, multi-edge traversals, and per-hop validation.

Table 28.2.2: Language Classification by Domain Family

§28.2.4 Hybrid Composition Model

All ten Hybrid patterns follow a consistent composition strategy: SQL identifies entities and filters records; Cypher validates structural relationships through graph traversal; the SDK composes results into the canonical return structure. The SDK query layer orchestrates this composition — it is not visible to query consumers.

Representative hybrid composition:

• QP-AUTH-05 (AI-Cannot-Be-Principal Enforcement): SQL identifies AI actors by type. Cypher traverses each actor's authority chains to verify human-held root termination.
• QP-GOV-04 (Conformance Test): SQL executes Pass 1 invariant checks (B1–B4, B5-immediate, B6-binding). Cypher executes Pass 2 checks (B5-T transitive chain, B8 signal routing). SDK aggregates into a unified conformance report.
• QP-INV-01 (Conservation Law Compliance): SQL runs all single-node property checks. Cypher runs transitive closure and cross-instance validation. SDK merges into a compliance result.

§28.2.5 CTE Fallback Strategy

Recursive Common Table Expressions (CTEs) provide a fallback for deployments without Apache AGE. Simple single-edge-type chains — authority delegation (QP-AUTH-01, QP-AUTH-02), instance hierarchy (QP-PRO-02) — have clean CTE substitutions with acceptable performance up to depth twenty. Multi-edge patterns (QP-LIN-01 decision lineage) require multiple CTEs joined at the application layer. Impact radius (QP-LIN-03) with its thirteen-edge-type multi-directional traversal has no viable CTE fallback — Apache AGE is required for this pattern.

Table 28.2.3: CTE Fallback Viability

§28.3 Query Pattern Library

§28.3.1 Pattern Taxonomy

The query pattern library comprises forty-four named patterns organized into eleven domain families. Each pattern specifies typed input parameters, a canonical return structure, traversal semantics, depth limits, governance constraints, and use cases. The families are not arbitrary groupings — they correspond to the structural domains of the governance substrate.

Table 28.3.1: Query Pattern Library

MCP exposure. Thirty-five of forty-four patterns are exposed as MCP Server tools. Nine patterns are SDK-only: internal validation patterns (QP-AUTH-04, QP-AUTH-05), access control patterns (QP-ACT-04, QP-PRO-04), internal analytics (QP-ORC-03, QP-ORC-04, QP-SIG-04, QP-TMP-02), and structural validation (QP-PRO-03).

§28.3.2 Domain Family Descriptions

Table 28.3.2: Domain Families

§28.4 Authority & Decision Patterns

Families A and B are the most graph-intensive domains. They traverse the cross-primitive relationships defined in §4.4 to answer the substrate's core structural questions: who has authority, how was it delegated, why was a decision made, and what does it affect.

§28.4.1 Authority Chain Traversal (QP-AUTH-01)

Authority chain traversal follows the delegates relationship (§4.4, relationship #11) upward from any authority to the root. This is the foundational graph pattern — every authorization check, audit trail, and scope validation relies on it.

Table 28.4.1: QP-AUTH-01 Specification

§28.4.2 Multi-Path Authority Check (QP-AUTH-03)

Multi-path authority check answers the question "can this actor do this?" by traversing from actor through holds and delegates edges to find any authority matching the required scope. The pattern uses eager termination — it returns the shortest valid path, not all paths.

Table 28.4.2: QP-AUTH-03 Specification

§28.4.3 Decision Lineage Trace (QP-LIN-01)

Decision lineage trace follows the causal chain from a decision backward through its antecedents — the intents that framed it, the evidence that informed it, the authority that legitimized it, and the account that contextualized it. This pattern traverses four of the thirteen cross-primitive relationships (§4.4): frames, evaluates, legitimizes, and contextualizes.

Table 28.4.3: QP-LIN-01 Specification

§28.4.4 Impact Radius (QP-LIN-03)

Impact radius is the most graph-intensive pattern. It traverses all thirteen cross-primitive relationships outward from a decision to compute the connected subgraph of affected entities within a configurable depth. This is not a tree — it is an arbitrary subgraph with multiple edge types, branching, and reconvergence.

Table 28.4.4: QP-LIN-03 Specification

§28.4.5 Decision Reconstruction (QP-LIN-04)

Decision reconstruction assembles the complete context of a decision for audit: the decision record, its authority chain, the account state at decision time, the evidence set evaluated, the intent framing, and the constraint set in scope. This is a hybrid pattern — graph traversal resolves structural relationships; SQL retrieves field-level details and the temporal constraint snapshot.

Table 28.4.5: QP-LIN-04 Specification

§28.4.6 Remaining Authority & Decision Patterns

Four additional patterns complete these families:

Table 28.4.6: Additional Authority & Decision Patterns

§28.5 Governance & Compliance Patterns

Families C and I address governance infrastructure: what governance frameworks are active, where compliance gaps exist, whether behavioral invariants hold, and how violations are tracked and overridden.

§28.5.1 Conformance Test (QP-GOV-04)

The conformance test pattern executes the ten conformance tests defined in §13, each backed by one or more of the ten behavioral invariants. This is a hybrid pattern: Pass 1 tests (B1 through B4, B5-immediate, B6-binding) are relational single-node checks; Pass 2 tests (B5-T transitive chain, B8 signal routing) require graph traversal.

Table 28.5.1: QP-GOV-04 Specification

§28.5.2 Gap Register (QP-GOV-03)

The gap register query retrieves governance gaps characterized by the seven verification types (§6.7): EXIST, COMPLETE, CURRENT, APPROVED, CONSISTENT, COMPLIANT, RATIFIED. Each gap records which verification types are present and which are missing, enabling graduated assessment of governance completeness.

Table 28.5.2: QP-GOV-03 Specification

§28.5.3 Conservation Law Compliance (QP-INV-01)

Conservation law compliance runs the full invariant test suite — Pass 1 relational checks and Pass 2 graph checks — mapped to the nine conservation laws (§9). Each conservation law maps to one or more behavioral invariants: organizational direction is enforced by B9; binding force by B1 and B2; feasibility truth by B2; epistemic status by B3; scope preservation by B5; rule universality by B6; emergency signaling by B7 and B8.

Table 28.5.3: QP-INV-01 Specification

§28.5.4 Remaining Governance & Compliance Patterns

Table 28.5.4: Additional Governance Patterns

§28.6 Truth & Verification Patterns

Family D enforces the epistemic boundary (§6) through queries. Every primitive record in the substrate carries a truth type (Authoritative, Declared, Derived, Opaque — §6.1), a verification state, and a record lifecycle state. These four patterns make the epistemic layer queryable.

§28.6.1 Truth Type Filter (QP-TRU-01)

The foundational epistemic query. It filters any of the nineteen primitive tables by truth type and lifecycle state. This pattern is invoked — directly or as a sub-query — by virtually every other pattern that returns primitive records.

Table 28.6.1: QP-TRU-01 Specification

§28.6.2 Promotion Pathway Status (QP-TRU-04)

The promotion pathway query tracks AI-generated content through its lifecycle from staging to promotion or expiration. All AI output lands in staging with truth type Derived (§6.2). Promotion to Declared requires human review; promotion to Authoritative requires a Decision with traceable Authority (B5). No demotion path exists — the promotion direction is monotonic.

Table 28.6.2: QP-TRU-04 Specification

§28.6.3 Remaining Truth & Verification Patterns

Table 28.6.3: Additional Truth Patterns

§28.7 Actor, Work & Orchestration Patterns

Families E and F provide the query surface for actor context, RACIVG role assignments, work specifications, routing decisions, and delegation scope. These patterns read the state produced by the orchestration operations (§27.7) and actor lifecycle operations (§27.2).

§28.7.1 Actor Context (QP-ACT-01)

Every actor action requires context loading — the actor's type, active roles, authority scope, constraints, governance posture, and delegation references. This is the most frequently invoked pattern. It is pure SQL: a lookup on the actors table joined with delegations and role envelopes.

Table 28.7.1: QP-ACT-01 Specification

§28.7.2 Routing Resolution (QP-ORC-02)

Routing resolution queries audit the seven-step resolution engine (§A2): CLASSIFY → ACTIVATE → ROUTE → SELECT → COMPOSE → CONFIRM → EMIT. Each routing decision record captures the five-dimensional context (AICAR type, decision type, consequence level, operating posture, graduation stage), the alternatives considered, the selection rationale, and the computed human-in-the-loop level.

Table 28.7.2: QP-ORC-02 Specification

§28.7.3 Remaining Actor & Orchestration Patterns

Table 28.7.3: Additional Actor & Orchestration Patterns

§28.8 Signal, IQ & Emergence Patterns

Family G provides the query surface for the signal routing mechanism (B8), the investigative query lifecycle (B9), escalation chain resolution, and pattern detection. These patterns enforce the governance routing invariants — signals reach authority, and emergence converts to action.

§28.8.1 Signal Routing (QP-SIG-01)

Signal routing queries filter the signal register by status and object type, then validate that each signal's routing target is on the governance chain for the flagged object (B8). This is a hybrid pattern: SQL filters signals; Cypher traverses the governs edge (Authority → Primitive) and the delegates chain upward to verify routing compliance.

Table 28.8.1: QP-SIG-01 Specification

§28.8.2 Escalation Chain (QP-SIG-03)

The escalation chain query resolves the full authority path for a governed object — from the immediate governing authority to the root. This implements the algedonic channel: emergency signals can bypass intermediate hierarchy to reach any authority on the chain. The pattern is Cypher-required: it traverses the governs edge to find the immediate authority, then follows delegates upward.

Table 28.8.2: QP-SIG-03 Specification

§28.8.3 IQ Lifecycle (QP-SIG-02)

Investigative queries are the emergence mechanism — context-attached or free-floating capture of questions that arise from governance activity. The IQ lifecycle query filters by status, intent type (eight types: explore, validate, disambiguate, fill_gap, challenge, connect, branch_inventory, confidence_probe), and origin type (claim, signal, capture, workflow). B9 enforcement requires that every resolved IQ produces a Decision or Work item — the gap between what the organization knows and what it does about it must close.

§28.8.4 Pattern Detection (QP-SIG-04)

Pattern detection aggregates signals and IQs within a time window to identify recurring patterns. Pattern detection evidence enters as Derived truth (§6) and requires human promotion before influencing routing decisions. This is an SDK-only pattern — not exposed via MCP.

§28.9 Profile, KPI & Temporal Patterns

Families H, J, and K cover the portfolio hierarchy, measurement framework, and temporal governance layer.

§28.9.1 Recursive Instance Tree (QP-PRO-02)

The recursive instance tree traverses the substrate's organizational hierarchy — parent-child relationships, spawning events, graduation topology changes, evidence feeds, and federation licenses. This is a Cypher-required pattern: instance relationships form a graph with five edge types (PARENT_CHILD, SPAWNS, GRADUATES_TO, FEEDS, LICENSES_FROM) and unknown depth.

Table 28.9.1: QP-PRO-02 Specification

§28.9.2 Invariant Signal Query (QP-KPI-02)

Invariant signals are the always-on diagnostic dimensions that protect the enterprise during change. Eight dimensions — cycle time distribution, quality/rework rate, variance/predictability, escalation frequency, judgment load, evidence completeness, semantic integrity, change failure rate — are monitored continuously regardless of phase. These are not targets; they are diagnostic signals that answer "is the system healthier or more fragile than before?"

Table 28.9.2: QP-KPI-02 Specification

§28.9.3 Remaining Profile, KPI & Temporal Patterns

Table 28.9.3: Additional Profile, KPI & Temporal Patterns

§28.10 Return Structure Specifications

§28.10.1 Design Principles

All return structures share four properties:

1. Truth type metadata on every record. Fields truth_type, verification_state, and record_lifecycle_state appear on every primitive record and graph node. No consumer receives data without knowing its epistemic status.
2. Pagination via cursor. List results use opaque cursor-based pagination with a configurable limit (default: 50, maximum: 500).
3. Query metadata on every response. Every response includes a QueryMetadata envelope: query_id, pattern_id, execution timestamp, execution duration, language used, depth limit applied, profile type.
4. Typed identifiers. All identifiers are UUID. All timestamps are ISO 8601 / TIMESTAMPTZ.

§28.10.2 Return Structure Categories

The forty-four patterns produce results from six structural categories.

Table 28.10.1: Return Structure Categories

§28.10.3 Graph Result Structures

Three structures represent graph query results, distinguished by topology:

PathResult. An ordered sequence of nodes and edges for linear traversal queries. Used by authority chains (QP-AUTH-01, QP-AUTH-03), decision lineage (QP-LIN-01), and escalation chains (QP-SIG-03). Fields: nodes[] (ordered, with node_type, truth_type, depth), edges[] (ordered, with edge_type from thirteen §4.4 relationships), total_depth, terminated_at (root_reached, max_depth, or no_further_nodes).

TreeResult. A hierarchical structure with recursive children for tree-shaped traversals. Used by delegation trees (QP-AUTH-02), decision descendants (QP-LIN-02), and instance trees (QP-PRO-02). Each TreeNode carries node_id, node_type, truth_type, depth, edge_type (relationship to parent), and children[].

SubgraphResult. An arbitrary graph structure for multi-directional traversals. Used by impact radius (QP-LIN-03) only. Fields: center (traversal origin), nodes[] (with node_type, truth_type, depth_from_center), edges[] (with edge_type, direction), total_nodes, total_edges, max_depth_reached.

Graph results are not paginated. They are bounded by depth limits — the query's max_depth parameter controls response size. For large trees, consumers reduce max_depth to control payload.

§28.10.4 Common Fields on Primitive Records

Every primitive record returned by any pattern includes the following fields:

Table 28.10.2: Common Record Fields

§28.10.5 Governance State Structures

Governance domain patterns return specialized structures that capture the compliance and activation state of the substrate.

GapRegisterEntry. Used by QP-GOV-03. Each entry characterizes a governance gap using the seven verification types (§6.7):

Table 28.10.3: GapRegisterEntry Fields

ConformanceResult. Used by QP-GOV-04 and QP-INV-01. Each result records one conformance test execution:

Table 28.10.4: ConformanceResult Fields

§28.10.6 Orchestration Structures

RoutingDecisionRecord. Used by QP-ORC-02. Captures the full context of a routing decision from the seven-step resolution engine (§A2):

Table 28.10.5: RoutingDecisionRecord Fields

WorkSpecificationRecord. Used by QP-ORC-01. Captures the cognitive decomposition and composition strategy for a work specification:

Table 28.10.6: WorkSpecificationRecord Fields

§28.10.7 Structure-to-Pattern Mapping

Table 28.10.7: Return Structure Usage

Structures listed in Table 28.10.7 without field-level tables in §28.10.3–§28.10.6 (such as ActorContextRecord, PortfolioRecord, SignalRecord, InvariantSignalReading, and others) are specified by their pattern definitions in §28.4–§28.9. Field-level definitions for these structures are DESIGN SPACE.

§28.10.8 List Wrapper and Metadata

PaginatedList<T>. All patterns returning multiple records wrap them in a standard list envelope: items[], total (total matching records before pagination), cursor (opaque, null on last page), limit, has_more, instance_id.

QueryMetadata. Included on every query response:

Table 28.10.8: QueryMetadata Fields

ValidationError. Returned when a query fails validation before execution: error_code, error_message, parameter (which failed), constraint_violated, suggested_action.

§28.11 AI Query Generation

§28.11.1 Generation Architecture

The AI query generation layer translates natural language to parameterized query templates. The layer performs four functions: pattern identification, parameter extraction, validation, and execution. It never constructs raw Cypher or SQL strings — it fills typed parameters into pre-validated templates registered at SDK initialization.

§28.11.2 Template Catalog

High-frequency patterns use deterministic templates with no AI-generated query structure. The AI layer selects a template and fills parameters; the template itself is pre-validated.

Table 28.11.1: High-Frequency Templates

§28.11.3 Validation Pipeline

Every AI-generated query passes through a six-step validation pipeline before execution:

Step 1: Pattern Selection. The AI layer identifies which pattern maps to the natural language query. If the query is ambiguous — "show me the authority" could mean QP-AUTH-01 (chain), QP-AUTH-03 (check), or QP-ACT-01 (context) — the AI layer disambiguates by conversational context or asks the user to clarify.

Step 2: Parameter Extraction. The AI layer extracts typed parameter values from natural language. Entity resolution maps names to UUID lookups ("Sarah" → actor_id). Scope resolution constructs JSONB from descriptions ("finance purchases" → scope object). Temporal resolution converts relative expressions ("last quarter" → INTERVAL).

Step 3: Parameter Validation. Type check: parameters match template type declarations. Existence check: referenced UUIDs exist in the substrate. Range check: numeric parameters within bounds. ENUM check: values in controlled vocabulary.

Step 4: Profile Check. Depth limits within profile maximum. Pattern available at this profile tier. Actor has visibility for requested scope (QP-PRO-04).

Step 5: Execute. Template instantiated with validated parameters. Query engine invoked — Cypher, SQL, or both per the pattern's language classification. Results returned in canonical structure.

Step 6: Post-Processing. Truth type metadata verified on all result records. Depth limits annotated in QueryMetadata. Pagination applied if result set exceeds limit.

§28.11.4 Natural Language Mapping

Each domain family defines representative natural language patterns that map to specific query patterns. The following examples are illustrative, not exhaustive:

Table 28.11.2: Natural Language → Pattern Mapping (Representative)

§28.11.5 Truth Type Awareness

The AI layer includes truth type filters appropriate to the query context. Default behavior: canonical queries filter to truth_type IN (authoritative, declared). Staging review queries filter to truth_type = derived. The AI layer overrides defaults only on explicit user request ("show me everything including AI drafts"). When Derived content is included in results, it is explicitly marked as non-canonical.

§28.11.6 Error Handling and Escalation

When validation fails, the AI layer follows a three-step fallback:

1. Retry with correction. If a parameter fails validation (e.g., entity not found), the AI layer corrects or asks the user for clarification. One retry attempt.
2. Offer alternative pattern. If the requested pattern is unavailable (access control, profile limitation), suggest related patterns within the actor's scope.
3. Escalate to user. If no alternative exists, surface the failure with explanation: what was requested, why it failed, what the actor can do instead.

Table 28.11.3: Error Categories

§28.11.7 Profile Variations

Query behavior varies by substrate profile. Profiles affect available patterns, depth limits, RACIVG role scope, conformance level range, KPI class availability, and cycle type access.

Table 28.11.4: Query Behavior by Profile

Profiles may override default depth limits within bounds through profile configuration (§28-C12). No override may exceed the stated maximums. Depth overrides deeper than the profile default require documented justification.

§28.11.8 Template Versioning

Templates are versioned independently of the substrate schema. Breaking changes — parameter type modifications, result structure changes — increment the major version. Non-breaking changes — new optional parameters, additional result fields — increment the minor version. Backward compatibility, deprecation availability, and deprecation notice requirements are specified in §28-C27 through §28-C29.

§28.12 Interchange Format Architecture

§28.12.1 Three Formats

Query results are exposed through three interchange formats, each optimized for a different consumer class.

Table 28.12.1: Interchange Format Summary

MCP Server is the primary AI agent interface. It signals that the substrate is infrastructure, not just an application. AI agents query authority, lineage, and governance context through MCP tools with structured input/output contracts.

JSON Export provides accessibility. Graph structures are flattened to arrays with parent references. OWL restrictions are simplified to constraints. Temporal semantics are simplified to timestamps. The trade-off is intentional: JSON is universally consumable.

RDF/OWL Export provides fidelity. The full internal model — including OWL class restrictions, SHACL shapes, PROV-O provenance chains, and SKOS concept schemes — is preserved. W3C standards ensure long-term archival stability. The trade-off: RDF requires specialized tooling.

§28.12.2 MCP Tool Catalog

Thirty-five of forty-four patterns are exposed as MCP Server tools. Each tool maps one-to-one to a query pattern with the same inputs and outputs.

Table 28.12.2: MCP Tool Summary

§28.12.3 SDK-Only Patterns

Nine patterns are not exposed via MCP. They serve internal governance functions consumed by other patterns or used by the SDK enforcement engine:

Table 28.12.3: SDK-Only Patterns

§28.12.4 Fidelity Analysis

The three formats differ in fidelity for graph-intensive patterns:

Table 28.12.4: Key Fidelity Gaps

For patterns returning primitive records and aggregates, MCP/JSON fidelity is sufficient — the information is inherently tabular. Graph-intensive patterns experience structural information loss in JSON that RDF/OWL preserves.

§28.13 SDK Constraints

The following table consolidates all §28 constraints. Supporting reference material for depth limits (§28.13.2) and RACIVG access control (Table 28.13.3) follow the register.

Table 28.13.1: §28 Constraint Register

§28.13.2 Depth Limit Scaling by Profile

Query traversal depth limits scale with profile tier. EAS supports the deepest traversals (complex enterprise topology with deep authority chains and audit-grade lineage). BAS supports moderate depths (operational complexity at business scale). PAS supports the tightest limits (bounded project scope) or inherits from its parent.

Specific depth values per traversal type and profile are deployment-configurable. Reference defaults: see ../reference-defaults/calibration-parameters.md §4.

• MUST: Implementations enforce profile-specific depth limits.
• MUST NOT: Implementations exceed deployment-configured profile maximums on traversal queries.
• DESIGN SPACE: Specific depth limit values per profile and traversal type.

Table 28.13.3: Query Access by RACIVG Role

§28.14 Terminology

Table 28.14.1: §28 Terminology Definitions

§28.15 Cross-References

Table 28.15.1: §28 Cross-Reference Map

Scope

Scope limited to logical model specification. 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.