§A2 Work Orchestration

§A1 specifies the structural grammar for AI governance — the AICAR cognitive type taxonomy, the five-dimensional routing space, the delegation model, and the graduation stages. This section specifies how the DLP substrate implements that grammar: the resolution engine that converts work requests into governed Work Specifications, the constraint evaluation mechanics that determine routing, the execution layer interface, and the pattern detection and learning systems that drive graduation.

The relationship between §A1 and §A2 is the same as the relationship between protocol and implementation throughout the architecture. §A1 defines what must be true for any DLP implementation. §A2 defines how the DLP substrate makes it true. A competing DLP implementer could build a different Work Orchestration engine; they could not change the structural grammar of §A1.

Work Orchestration introduces no new primitives. Every operation in this section is a composition of the nineteen primitives (§4) — Decision, Authority, Constraint, Work, Evidence, Account, and their Tier 2–5 infrastructure. The orchestration engine is a governed composition pattern, not an extension to the primitive model.

§A2.1 Orchestration Resolution Engine

When a work request arrives, the substrate resolves routing through a seven-step sequence. Each step is a primitive operation with lineage. The sequence is canonical — all steps execute in order, producing a traceable chain from work request to execution.

Table A2.1.1: Seven-Step Resolution Sequence

Step 6 (CONFIRM) executes conditionally. At Stage A (Capture) and Stage B (Advise), human confirmation is always required. At Stage C (Orchestrate), confirmation is computed from the five-dimensional resolution — the HITL placement is a function of the routing space (§A1), not a fixed design choice. When the five-dimensional resolution produces a low-risk, high-confidence position (e.g., Citation + Cost + Reversible + Normal + Stage C), the substrate may emit without human confirmation. When any dimension elevates risk, confirmation is required.

Resolution Decision Record

Each resolution produces a RoutingDecision record — a Decision (§4) with routing-specific structure:

When the substrate cannot resolve routing — no eligible actor for a required cognitive work type, constraint conflicts, insufficient delegation, or confidence below the configured floor — it escalates. Escalation is a state transformation with lineage: the substrate records what it could not resolve, why, and to whom the escalation is routed (per B8, §5).

§A2.2 Constraint Evaluation Mechanics

Three constraint types govern AI routing. All three are specializations of the Constraint primitive (§4). They compose through intersection to produce the effective constraint set for any given work request.

Table A2.2.1: Constraint Type Definitions

Routing Constraints are evaluated before delegation lookup. They determine which AI actors are eligible for a work request based on work type, cognitive type, domain, and contextual conditions. A routing constraint may specify preferred actors (ordered preference), required capabilities (cognitive work types the actor must support), and excluded actors (actors prohibited for this work type).

Behavioral Constraints bind how an AI actor performs work once routed. They travel with the Work Specification and are consumed by the execution layer. Each behavioral constraint specifies an enforcement level: Blocking (prevents non-compliant output), Warning (flags non-compliance but permits output), Logging (records silently), or Advisory (suggests alternatives). The enforcement levels correspond to the four modes defined for the Constraint primitive (§4).

Activation Constraints determine when additional constraint sets load based on context. They are the mechanism by which domain-specific rules — regulatory requirements, organizational policies, temporal conditions — dynamically scope AI behavior. An activation constraint fires when its trigger conditions match the current work context, loading the specified constraint set and optionally deactivating superseded constraints. Five-dimensional triggers enable activation based on routing space position: a decision type escalation, consequence level change, or operating posture shift can load additional constraint sets.

Constraint Composition

Multiple constraints compose through intersection:

EffectiveConstraints(work) =
   RoutingConstraints(work.type, work.domain)
 ∩ BehavioralConstraints(work.cognitiveType, selectedActor)
 ∩ ActivationConstraints(work.context, work.dimensionalPosition)

The resulting possibility space is the intersection of all active constraints. When constraints conflict — a routing constraint permits an actor that a behavioral constraint excludes — the conflict is itself a Decision requiring resolution through the authority chain. Constraint conflict resolution produces lineage: who resolved the conflict, on what basis, and what the resulting effective constraint set is.

Constraint cascade in recursive structures follows the tighten-only rule (§23). Child instances inherit parent constraints and may tighten but never loosen. The effective constraint set at any recursion level includes all ancestor constraints.

§A2.3 Work Specification Architecture

The Work Specification is the substrate's governed output — the instruction that the execution layer consumes. It represents the substrate's resolution of what cognitive work is needed, who handles each component, and under what constraints. The Work Specification is a composition of primitives, not a new primitive.

Table A2.3.1: Work Specification Structure

The cognitive decomposition expresses composite work as ordered components. A compliance determination might decompose into: Citation (retrieve regulatory text), Reasoning (analyze whether facts satisfy criteria), Context (consider organizational history and prior determinations), Communication (draft the finding). Each component may route to a different AI actor based on delegation scope, or to the same actor with different constraint sets active.

Work Specification as State Transformation

Creating a Work Specification is itself a state transformation:

This means the routing decision has lineage. "Why did the substrate route this work to Actor A instead of Actor B?" is answerable from the transformation record.

Table A2.3.2: Work Specification Lifecycle States

Each state transition is a primitive operation with lineage. The transition from Draft to Confirmed is a Decision (§4) with Authority (§4). The transition from Active to Completed is verified by checking that all required outputs specified in the cognitive decomposition have been received.

§A2.4 Execution Layer Interface

The substrate produces Work Specifications. The execution layer consumes them. This boundary is intentional and architecturally significant — the substrate governs what happens; the execution layer determines how it happens.

Table A2.4.1: Substrate vs. Execution Layer Responsibilities

The substrate does not encode prompts, model parameters, or tool configurations. These are execution layer concerns. The substrate specifies the governance envelope — cognitive work type, behavioral constraints, evidence requirements, authority scope — and the execution layer translates that envelope into model-native configuration. This separation ensures that model changes, prompt engineering evolution, and tool configuration updates do not require governance architecture changes.

Execution Layer Contract

The execution layer satisfies a contract that maintains governance integrity:

Accepts: A confirmed Work Specification.

Translates: Cognitive work type → model configuration. Behavioral constraints → prompt instructions or tool configuration. Input evidence → model context.

Returns: Three categories of output:

• Outputs — Evidence artifacts produced by the AI actor for each component
• Execution metadata — Model used, tokens consumed, execution duration, confidence signals, tools invoked, errors encountered
• Completion status — Completed (all components produced outputs), Partial (some components produced outputs), or Failed (execution could not proceed)

Output Re-Entry

Outputs from the execution layer enter the substrate as Evidence (§4) with truth type Derived (§6). Every AI output carries:

AI outputs enter with promotion status awaiting_review. Promotion to Declared or Authoritative requires a human Decision with Authority and Account (§6). The promotion decision is itself a state transformation with lineage: who reviewed, what they found, whether they accepted or rejected, and on what basis.

§A2.5 Pattern Detection and Learning

Pattern Detection (Stage A+ Mechanics)

With sufficient interaction history, the substrate's pattern detection engine observes:

• Work type clusters — what interactions share characteristics, how frequently each type appears, what groupings emerge
• Quality patterns by context — acceptance rates, correction rates, common correction types per work context
• Cognitive type signals — retrospective classification of past interactions into AICAR cognitive work types (§A1)

Pattern detection activates at Stage A+ — the point where sufficient evidence exists for pattern recognition. The pattern detection engine is a substrate component, not an AI actor — its outputs are computational observations over accumulated interaction data.

§A2.5.1 Pattern Accumulation Minimums

Pattern detection requires accumulated evidence across four dimensions before signaling Stage A+ readiness: total interaction count, unique work-context diversity, human review decision count, and observation period duration.

Specific minimums are substrate-level defaults; implementations may configure higher minimums for elevated risk tolerance. No instance may configure lower minimums than the substrate defaults shipped with the implementation. Reference defaults: see ../reference-defaults/calibration-parameters.md §5.

Patterns as Derived Evidence

Detected patterns are Evidence (§4) with truth type Derived (§6). They are substrate-generated observations, not verified organizational knowledge:

Patterns enter with promotion status awaiting_review. Human validation is required before patterns inform routing decisions. An unvalidated pattern may be surfaced to a human reviewer as a recommendation; it may not alter routing behavior. Once a human validates a pattern (promoting it to Declared), the validated pattern becomes part of the routing evidence base and may influence graduation progression.

Learning Integration

Pattern detection is the sensor; the learning mechanism (§18, Learn stage) is the adaptive response. Pattern detection feeds the graduation evidence chain — accumulated, validated patterns provide the evidence basis for graduation transitions. The learning mechanism provides double-loop feedback: identifying systematic miscalibration in thresholds, surfacing structural adjustments, and producing reconfiguration directives that flow to the Configure stage.

§A2.6 Routing Proposals and Override Tracking

Routing Proposals (Stage B Mechanics)

At Stage B (Advise), the substrate generates routing proposals for human confirmation. Each proposal contains:

A proposal is a substrate recommendation, not a binding decision. The human may confirm (proposal proceeds as recommended), override (human selects a different actor or classification), or modify (human adjusts specific elements while accepting others). Every human response is a Decision with Account, producing lineage.

Override Tracking

When a human overrides a substrate proposal, the override is high-value lineage. Override patterns are themselves Evidence — they reveal where the substrate's routing model diverges from human judgment.

Systematic override for a particular work type signals one of two conditions: the routing model needs correction (the substrate is consistently misclassifying or misrouting), or the work type is genuinely unsuitable for substrate routing (the work requires human judgment that the routing model cannot capture). Both conditions are diagnostically valuable. Override patterns feed the learning mechanism and inform graduation decisions — a high override rate for a scope prevents graduation to Stage C for that scope.

Table A2.6.1: Graduation Transition Criteria

Specific threshold values per transition are substrate-level defaults; implementations may configure higher thresholds for elevated risk tolerance environments. No implementation may set thresholds below the reference defaults — these are floors, not ceilings. Reference defaults: see ../reference-defaults/calibration-parameters.md §6.

Each graduation transition is a Decision (§4) with Authority and Account. The transition records the evidence that justified advancement, the authority that approved it, and a rollback condition. Rollback conditions are expressions evaluated continuously — when a rollback condition is met (e.g., output rejection rate exceeds a configured threshold), the substrate automatically regresses to the prior stage and records the regression as a Decision with Account. Rollback condition reference defaults: see ../reference-defaults/calibration-parameters.md §7.

Graduation Invariants

• No stage skipping. Graduation proceeds sequentially: A → A+ → B → C. An organization cannot advance from Stage A to Stage C.
• Evidence-based advancement. Each transition requires evidence from the current stage demonstrating readiness for the next.
• Automatic regression. When rollback conditions are met, the substrate regresses and records why.
• Per-scope graduation. Different scopes — defined by AICAR cognitive type × decision type × domain namespace — graduate independently. An organization may be at Stage C for Citation in Cost decisions and Stage A for Reasoning in Risk decisions.

§A2.7 Behavioral Invariant Compliance

Work Orchestration operates within the ten behavioral invariants (§5). The orchestration engine introduces no new invariants — it composes existing ones. This table demonstrates how each invariant is preserved through orchestration.

Table A2.7.1: B1–B10 Orchestration Compliance Mapping

The governance floor never drops. From Stage A through Stage C, AI outputs are Derived, delegations trace to human authority, and lineage is maintained. The invariants are protocol requirements from day one, not Stage C requirements relaxed for earlier stages.

§A2.8 SDK Constraints Summary

Table A2.8.1: §A2 SDK Constraints