Skip to content
Clause 7 — The Stitching Mechanism

Clause 7 — The Stitching Mechanism

7. The Stitching Mechanism

(Normative)

7.1 Bidirectional Interface

The Intent Stack and BPM/Agent Stack connect through a bidirectional interface. The two specifications are peers — neither is subordinate to the other. They meet at a clean boundary where governance context becomes actionable execution specification, and where execution evidence feeds back into alignment assessment.

Downward flow (Intent to Execution). Intent Stack L2 (Specification) produces authorized Key Tasks — the actionable specifications derived from discovered, formalized intent. These authorized Key Tasks become the entry point for governed processes in the BPM/Agent Stack. The governed process model IS the execution specification — it defines HOW authorized work gets executed with structure, roles, decisions, exceptions, and accountability.

Upward flow (Evidence to Alignment). BPM/Agent Stack execution produces structured evidence: audit trails, performance metrics, exception records, decision logs, and completion artifacts. This evidence flows upward to Intent Stack L1 (Runtime Alignment), which performs closed-loop assessment of whether execution outcomes align with governing intent. Evidence quality is a primary execution governance concern — the BPM/Agent Stack SHALL produce evidence of sufficient structure and fidelity to support alignment assessment.

7.2 Primary Stitching Point

The primary structural joint between the two specifications is the Key Tasks primitive (fifth of five Intent Primitives) operationalized at Intent Stack L2 (Specification).

Key Tasks defines what work the agent is authorized to perform at each governance interface. It scopes authorized work by inclusion and exclusion. At Intent Stack L2, the governance context asks: “Given this intent, what SHALL we actually do?” This is where governance intent becomes actionable direction.

The BPM/Agent Stack enters at L2’s output. Each authorized Key Task, as operationalized through L2’s specification process, becomes the entry point for a governed process in the BPM/Agent Stack. The governed process model IS the actionable specification — it defines HOW authorized work gets executed with structure, roles, decisions, exceptions, and accountability.

The BPM/Agent Stack then provides execution governance infrastructure across its three concerns:

  • Orchestration — swimlanes, subprocesses, and message flows SHALL govern multi-agent coordination;
  • Integration — the Systems attribute on governed activities SHALL map to governed tool/API/MCP access;
  • Execution — process instantiation SHALL run the governed process with assigned participants, live state, and audit trail.

7.3 Evidence Return Path

The BPM/Agent Stack SHALL provide structured evidence to Intent Stack L1 (Runtime Alignment) through the following channels:

Evidence Type Source L1 Use
Audit trail Version-controlled process history (Clause 10.5) Alignment assessment over time
Performance metrics Value Stream Mapping attributes (Clause 8.3) Efficiency and value-add analysis
Exception records BPMN event taxonomy (Clause 9.4) Drift detection and escalation analysis
Decision logs DMN decision table evaluations (Clause 10.3) Deterministic decision audit
Completion artifacts Process outputs with typed deliverables End State alignment assessment
Boundary compliance Propagated constraint enforcement records Boundary integrity verification

This evidence return path closes the governance loop: intent flows down from governance context through the stitching mechanism into execution; evidence flows up from execution through the stitching mechanism into alignment assessment.

7.4 Boundary Propagation

The Boundaries primitive (third of five) provides a secondary stitching mechanism that operates in parallel with the Key Tasks primary stitch. Boundaries SHALL accumulate monotonically through governance interfaces and propagate into the BPM/Agent Stack through multiple channels:

Target Propagation Mechanism
Policy links Boundary documents become linked policies on process activities
Vocabulary constraints Boundary-defined terminology becomes enforced vocabulary
Gateway conditions Boundary constraints become conditions on decision gateways
Event triggers Boundary violations become escalation events
Activity restrictions Boundary constraints scope authorized activity types, systems, and participants

Invariant. Monotonic accumulation SHALL be preserved: downstream processes inherit upstream constraints and can only tighten them. A subprocess SHALL NOT authorize what its parent process prohibits. This invariant maps directly to the Intent Stack’s Boundaries monotonicity (§5.3 and Annex C.3 of the companion specification).

7.5 Additional Stitching Intersections (Exploratory)

The visualization analysis that informed this specification revealed that the primary stitching point (Key Tasks at Intent Stack L2) carries the entire structural weight of the two-specification architecture. This raises an architectural question: are there additional stitching intersections where the remaining primitives connect independently to the BPM/Agent Stack?

Boundaries propagation (§7.4) is already documented as a parallel mechanism. Three additional potential intersections merit investigation:

Primitive Potential BPM/Agent Stack Intersection Status
Purpose Process-level purpose alignment — does each governed process serve the delegated Purpose? Unexplored
Direction Activity-level approach guidance — does the execution approach reflect the delegated Direction? Unexplored
End State Process completion criteria — does the process’s end condition align with the delegated End State? Unexplored

If these intersections exist as independent stitching mechanisms (not merely downstream of Key Tasks), the two-specification architecture is more robust than a single-point connection suggests. If they are genuinely downstream of Key Tasks, then Key Tasks is correctly identified as the unique structural joint. This is an open question.

NOTE — The reclassification of execution governance concerns from the Intent Stack to the BPM/Agent Stack (v1.1/v1.2) does not change the structural analysis of stitching intersections. The stitching point remains at the boundary between governance context and execution governance, regardless of which specification document those concerns reside in. The four-layer Intent Stack and the three-concern BPM/Agent Stack meet at the same structural joint as before.

7.6 Trust Calibration at the Process Level

The Intent Stack’s trust calibration model (Clause 10 of the companion specification) extends to process execution. Trust calibration determines the governance configuration of each process:

Trust Level Process Configuration
Low trust (corrigibility) Frequent User Tasks (human checkpoints), narrow gateway conditions, many escalation events, tight subprocess boundaries
Moderate trust (calibrated autonomy) Mixed User and Service Tasks, structured gateways with human override at critical points, escalation for uncertainty
High trust (wide autonomy) Predominantly Service Tasks, automated gateway routing, escalation only for exception conditions, wider subprocess authority

The process model SHALL adapt based on the trust calibration at the governance interface. Higher-trust agents execute within wider process authority; lower-trust agents execute within narrower process constraints. The process structure IS the operational expression of trust calibration.