Composable AI Data Governance for Agentic Engineering

Disclosure: This article may contain affiliate links. We may earn a commission at no extra cost to you.

Readers will be able to assign the right governance pattern to each agentic AI use case, place controls at the correct decision boundary, and reduce compliance risk without defaulting to a one-pattern-fits-all architecture.

TL;DR

• Classify every AI use case by risk before design approval, then select a primary governance pattern using the default rule: high-risk to Enterprise Trust Fabric, medium-risk to AI Control Plane, low-risk to Federated AI Domains.
• This works because governance becomes a composed control system aligned to actual risk, data sensitivity, and delivery speed rather than an abstract enterprise standard.
• The main risk is misapplying the fast path everywhere or federating without enforceable architectural contracts, which creates fragmented controls and weak auditability.
• Track 100% production coverage for risk tier, pattern, and overlay status; maintain at least 90% risk classification accuracy; keep wrong-pattern post-deployment exceptions below 10%.
• Included asset: a Governance Pattern Selection Worksheet and Control Allocation Matrix for architecture reviews.

---

The Composed Governance Model for Agentic AI: Trust Fabric, AI Control Plane, Federated Domains, and Mandatory Overlays

Treat governance for agentic AI as a composed control system, not a single platform choice. The practical model has four parts: a trust fabric for governed data, an AI control plane for runtime mediation, federated domains for distributed ownership, and mandatory overlays for risk and external model boundaries.

Composition model

Layer	Primary role	Use when	Key control objective
Trust Fabric	Govern data before model consumption	High-risk workloads; regulated or high-sensitivity data exceeds 25% of context payload; full lineage is mandatory	Assure lineage, classification, and data quality upstream
AI Control Plane	Govern data in motion and model interaction paths	Medium-risk workloads; bounded enterprise data exposure; rapid iteration is required	Enforce masking, filtering, prompt safety, telemetry, and policy-as-code at runtime
Federated Domains	Distribute execution to domain teams under shared standards	Low-risk or domain-specific use cases; domains can meet central architectural contracts	Scale delivery without losing ownership, auditability, or access discipline
Mandatory Overlays	Modify every pattern based on risk and egress	Always for risk tiering; always for external model invocation	Prevent one-size-fits-all controls and unmanaged third-party exposure

How the layers fit

• Use the risk tier as the first decision boundary.
• High-risk → Trust Fabric
• Medium-risk → AI Control Plane

• Low-risk → Federated Domains

• Apply overlays to every design.

• Require 100% of production AI systems to have a documented risk tier, primary pattern, and overlay status before release.

• Require External AI Boundary Control whenever prompts, context, or tool outputs cross into third-party models.

• Allocate controls to the right governance surface.

• Put lineage, classification, and quality in the trust fabric.
• Put prompt filtering, masking, output validation, and usage telemetry in the control plane.
• Put ownership, stewardship, and local workflow controls in federated domains.

What breaks in practice

• Do not force Trust Fabric everywhere. That expands the governance surface beyond the actual risk envelope and stalls delivery.
• Do not let the AI Control Plane become a bypass around enterprise governance. Runtime enforcement without lineage is not enough for audit-heavy workloads.
• Do not federate without standards. If domains cannot show ≥95% conformance to central controls, you have fragmentation, not federation.

Concrete example: a customer-support agent using internal KB articles and CRM summaries may fit the AI Control Plane if the exposed data is bounded and runtime masking achieves <1% sensitive-attribute leakage with ≥99% policy enforcement success. The same agent moves into Trust Fabric territory once regulated claims data becomes a material part of context or full source lineage is required.

The operating rule is straightforward: choose the primary pattern by risk, keep overlays mandatory, and assign each control to one layer with one owner. If a control has no clear boundary, the architecture is not ready for production-grade deployment.

Figure 1: The governance model is a composed control system: risk determines the primary pattern, and mandatory overlays apply across every path.

Payoff + TL;DR: What Changes When You Align Governance to Risk Instead of Standardizing on One Pattern

Align governance to risk, and three things change immediately: delivery speed, control placement, and audit quality.

• Delivery speed improves because you stop forcing low-risk use cases through high-friction controls.
• Medium-risk workloads should clear governance in <15 business days.
• Low-risk domain tools can move under federated guardrails instead of waiting for enterprise-wide data remediation.
• Control placement gets sharper.
• High-risk systems push controls upstream into governed data products.
• Medium-risk systems enforce policy in the AI control plane.
• Low-risk systems stay domain-owned, but only if they meet central architectural contracts for logging, access control, and policy enforcement.
• Audit quality improves because controls map to the actual decision boundary.
• You can ask: was this dataset governed before model access, governed in motion, or governed by domain conformance?
• That is materially different from asking whether every team used the same platform pattern.

The practical payoff is not “more governance.” It is selective friction.

• Use the Trust Fabric when regulated or high-sensitivity data exceeds 25% of the context payload or when full lineage is mandatory.
• Use the AI Control Plane when the data surface is bounded and runtime enforcement can hold ≥99% policy enforcement success with p95 policy latency <150 ms.
• Use Federated Domains when teams can prove ≥95% conformance to central controls and remediate findings in <30 days.

A concrete example:

• A customer support copilot pulling from policy-approved knowledge articles does not need the same governance path as an underwriting agent reading regulated customer records.
• Standardize both on one pattern, and one of two things happens:
• you over-govern the copilot and slow delivery, or
• you under-govern the underwriting agent and weaken traceability.

TL;DR:

• Do not standardize on one governance pattern.
• Standardize on:
• risk tiering first
• pattern selection second
• overlays always
• The production-grade model is hybrid:
• high-risk → Trust Fabric
• medium-risk → AI Control Plane
• low-risk → Federated Domains
• If every production AI system has a documented risk tier, primary pattern, and overlay status before release, governance becomes an operating model instead of a bottleneck.

Patterns vs Anti-Patterns: What Scales, What Fragments, and Where Governance Programs Stall

Pattern	Anti-Pattern	Why It Matters
Enterprise Trust Fabric for high-risk workloads	Govern everything before any AI work starts	Use this pattern when regulated or high-sensitivity data exceeds 25% of the context payload, or when full lineage is mandatory. It scales for crown-jewel data because controls are applied before model interaction. It stalls when teams turn it into a universal prerequisite and expand the governance surface beyond the actual risk.
AI Control Plane for bounded, medium-risk AI flows	Treat the AI platform as a bypass around enterprise governance	This pattern works when runtime mediation is strong: ≥99% policy enforcement success, <1% unmasked sensitive-attribute leakage, and p95 policy evaluation latency <150 ms. It fragments when prompt filtering, masking, and telemetry live in a shadow stack with no lineage back to governed sources.
Federated AI Domains with central standards and domain accountability	Federation without standards	Federation scales only when domains can meet shared architectural contracts for policy enforcement, audit logging, and access control. Watch the conformance line: ≥95% policy conformance, 100% named owner and steward, <30 days to remediate audit findings. Without that, you do not have federation. You have drift.
Risk-tiered composition: high-risk → Trust Fabric, medium-risk → AI Control Plane, low-risk → Federated Domains	Select one pattern everywhere because it is operationally convenient	Governance programs stall when pattern choice follows org chart or platform preference instead of risk. Require 100% of production AI systems to have a documented risk tier, primary pattern, and overlay status before release. The decision boundary is risk exposure, not team ownership.
External AI Boundary Control on every third-party model call	External model usage without minimization and tokenization	External invocation always expands the governance surface. Apply redaction or tokenization to restricted classes with ≥99% coverage and maintain ≥95% audit-log completeness for high-risk transactions. Without boundary control, leakage is hard to detect and harder to prove after the fact.
Central policy with runtime telemetry and evidence collection	Policy centralization without enforcement telemetry	Programs fragment when policy exists only in review decks and exception registers. Production-grade governance needs evidence: enforcement success rates, exception aging, lineage completeness, and quarterly review completion ≥95%. If you cannot measure a control in operation, you do not control it.

The pattern that scales is usually hybrid, not pure.

• Put governed data products at the core.
• Put runtime mediation at the AI interaction edge.
• Put domain ownership where risk is low enough and standards are enforceable.

Actionable takeaway:

• Start with risk tiering.
• Assign the primary pattern from that tier.
• Add overlays explicitly.
• Reject any design that cannot show where each control lives, who owns it, and what evidence proves it works.

Regulatory Alignment: EU AI Act and NIST AI RMF Mapping

The pattern composition above maps cleanly to the major AI governance frameworks. Use this mapping to defend pattern choice in audit conversations and to scope readiness work against published requirements.

EU AI Act mapping

EU AI Act requirement	Pattern coverage
Risk classification	Risk-Tiered Governance (mandatory overlay)
Data quality and bias	Enterprise Trust Fabric + AI Control Plane
Human oversight	AI Control Plane (HITL gates, output validation, approval enforcement)
Traceability and logging	Trust Fabric + platform monitoring
Third-party model risk	External AI Boundary Control (mandatory overlay)

NIST AI RMF mapping

NIST function	Pattern alignment
Govern	Enterprise Trust Fabric + central policy layer
Map	Risk-Tiered Governance + domain context
Measure	AI Control Plane (monitoring, evaluation telemetry)
Manage	Federated Domains + platform guardrails

If a regulator asks where in the architecture a specific control lives, this mapping is the answer. If a control has no clear pattern home, it does not have an enforceable owner — fix the architecture before the audit, not during it.

Implementation Playbook: Classify Risk, Select the Primary Pattern, Apply Overlays, and Allocate Controls by Boundary

Use a gated sequence. Do not pick controls ad hoc.

Preconditions

• Define one canonical model:
• Enterprise Trust Fabric
• AI Control Plane
• Federated AI Domains
• Risk-Tiered Governance overlay
• External AI Boundary Control overlay
• Assign a central policy authority and named domain owners.
• Stand up telemetry for:
• lineage completeness
• policy enforcement success
• audit-log completeness
• redaction/tokenization coverage
• risk classification accuracy
• Make release gating explicit:
• 0 production deployments without risk tier, primary pattern, and overlay status.

1. Classify risk before design approval

• Assign every use case to a risk tier before architecture review.
• Use hard triggers, not intuition:
• classify as high risk when regulated or high-sensitivity data exceeds 25% of context payload
• classify as high risk when full lineage to source is mandatory for audit
• Treat risk tier as the first decision boundary. Everything downstream depends on it.
• Verification check:
• 100% of production AI systems have documented risk tier before release
• classification accuracy is ≥90% in quarterly audit samples

2. Select the primary pattern

• Apply the default composition rule:
• High risk → Enterprise Trust Fabric
• Medium risk → AI Control Plane
• Low risk → Federated AI Domains
• Override only with written rationale and exception owner.
• Avoid the common failure mode: selecting the AI Control Plane everywhere because it is the fastest path.
• Verification check:
• post-deployment governance exceptions from wrong pattern selection stay below 10%
• first-pass architecture review acceptance is ≥90% when teams use the worksheet

3. Apply overlays as mandatory modifiers

• Apply Risk-Tiered Governance to every use case. No exceptions.
• Apply External AI Boundary Control whenever data crosses to a third-party model.
• Treat overlays as part of the architectural contract, not optional middleware.
• Verification check:
• external egress for restricted data achieves ≥99% redaction/tokenization coverage
• audit-log completeness for high-risk AI transactions is ≥95%

4. Allocate controls by boundary

• Place controls where they are strongest, not where the platform team happens to own tooling.
• Allocate by boundary:
• Trust Fabric boundary:
  • data classification
  • lineage
  • quality controls
  • governed data products
  • semantic layer / ontology (entities, relationships, valid state transitions, action constraints) — increasingly required for agentic Trust Fabric workloads
• AI Control Plane boundary:
  • prompt/context filtering
  • masking
  • output validation
  • usage monitoring
  • policy-as-code onboarding
• Domain boundary:
  • ownership
  • local process controls
  • conformance evidence
  • remediation
• Build a control allocation matrix with one owner and one evidence source per control.
• Verification check:
• 100% of controls mapped to an owner
• duplicate ownership and evidence gaps are resolved before release

5. Enforce pattern-specific thresholds

• For Trust Fabric, require:
• lineage completeness ≥95%
• PII classification coverage ≥98%
• critical data quality rule failure rate <2%
• for agentic Trust Fabric workloads: ≥95% of agent actions map to defined state transitions in the ontology; <5% free-form actions in production
• For AI Control Plane, require:
• policy enforcement success ≥99%
• unmasked sensitive-attribute leakage <1%
• p95 policy evaluation latency <150 ms
• ≥90% of AI data sources onboarded through automated policy-as-code gates
• For Federated Domains, require:
• 100% of AI products mapped to a named owner and steward
• ≥95% conformance to central controls
• audit remediation in <30 days

6. Review exceptions and recalibrate

• Close exceptions on a clock:
• high risk: <7 days
• medium risk: <14 days
• Reassess risk when scope, data sources, or model behavior changes.
• Run quarterly reviews. Static tiering is an anti-pattern.
• Verification check:
• quarterly control review completion ≥95%

Rollback guidance

• Move the workload to a stricter pattern if evidence is weak.
• Example: shift from AI Control Plane to Trust Fabric when lineage or sensitivity assumptions fail.
• Disable external model egress if redaction/tokenization coverage drops below threshold.
• Freeze new domain releases if conformance falls below 95%.
• Hold release when control ownership, overlay status, or audit evidence is incomplete.

The operating rule is straightforward: classify first, compose second, enforce at the right boundary, and measure the result in production.

Figure 2: Use a gated sequence: classify risk first, choose one primary governance pattern, then apply overlays and allocate controls by boundary.

Metrics & Instrumentation: Coverage, Lineage, Enforcement, Leakage, Latency, Conformance, and Review Thresholds

Treat instrumentation as part of the architectural contract, not a reporting afterthought. If you cannot measure a control at the decision boundary where it operates, you do not have a production-grade control.

Core governance metrics

Metric	Threshold	Alert condition	Review cadence
Production AI systems with documented risk tier, primary pattern, and overlay status	100% before release	Any production deployment missing one	Per release, weekly rollup
Risk classification accuracy against audit sample	≥90%	<90%	Quarterly
First-pass architecture review acceptance	≥90%	<85% for 2 consecutive review cycles	Monthly
Post-deployment governance exceptions caused by wrong pattern selection	<10%	≥10%	Monthly
Time-to-govern new medium-risk use case	<15 business days	>15 business days	Monthly

Trust fabric instrumentation

• Measure lineage completeness from source to AI-consumed data product.
• Threshold: ≥95%
• Alert: any high-risk workload below threshold
• Measure PII classification coverage on in-scope datasets.
• Threshold: ≥98%
• Alert: any restricted dataset below threshold
• Measure critical data quality rule failure rate before AI consumption.
• Threshold: <2%
• Alert: sustained breach for 24 hours
• Apply this pattern when regulated or high-sensitivity data exceeds 25% of context payload, or when full lineage is mandatory.

AI control plane instrumentation

• Measure policy enforcement success on AI-bound requests.
• Threshold: ≥99%
• Alert: <99% daily or any sustained enforcement gap
• Measure unmasked sensitive-attribute leakage in sampled prompts and context windows.
• Threshold: <1%
• Alert: any spike above threshold
• Measure policy evaluation latency.
• Threshold: p95 <150 ms
• Alert: p95 above threshold for 3 consecutive intervals
• Measure source onboarding through policy-as-code gates.
• Threshold: ≥90%
• Alert: manual onboarding trend rising month over month

Federated domain instrumentation

• Map every domain AI product to a named owner and steward.
• Threshold: 100%
• Measure conformance to central policy controls.
• Threshold: ≥95%
• Measure audit finding remediation time.
• Threshold: <30 days
• Alert: any overdue high-severity finding

External boundary and review thresholds

• Measure redaction/tokenization coverage for restricted data sent to external models.
• Threshold: ≥99%
• Measure audit-log completeness for high-risk AI transactions.
• Threshold: ≥95%
• Measure quarterly control review completion.
• Threshold: ≥95%
• Enforce exception closure SLAs.
• High risk: <7 days
• Medium risk: <14 days

The operating rule is straightforward: if coverage is incomplete, lineage is weak, enforcement is unverifiable, leakage rises, latency breaches the operational envelope, or domain conformance drifts, stop treating the system as governed and route it back through review.

Pitfalls & Edge Cases: Mis-Tiered Risk, Shadow Governance Stacks, Domain Drift, and Unmanaged External Model Egress

Pitfall: Mis-tiered risk assigns the wrong primary pattern to the workload. The common failure is medium-risk by assumption, when the actual context payload contains regulated or high-sensitivity data above the 25% threshold. → Detection: Risk classification accuracy drops below 90% in quarterly audit samples; post-deployment governance exceptions from wrong pattern selection exceed 10%; teams request exceptions after release rather than before design approval. → Mitigation: Make risk tier a release gate. Re-run classification when data scope, model behavior, or external integrations change. Use the default composition rule: high-risk to Trust Fabric, medium-risk to AI Control Plane, low-risk to Federated Domains.

Pitfall: Shadow governance stacks emerge when the AI platform becomes a bypass around enterprise controls. Runtime filters look strong, but lineage, ownership, and policy consistency break at the boundary. → Detection: Runtime policy enforcement is high, but lineage completeness stays below 95%; duplicate policy definitions exist in data and AI layers; audit findings cluster at handoff points. → Mitigation: Treat the AI platform as a control plane, not a separate governance system. Define a control allocation matrix. Map each control to one owner, one evidence source, and one decision boundary.

Pitfall: Domain drift turns federation into fragmentation. Teams keep the local autonomy but stop honoring shared logging, access, and policy contracts. → Detection: Conformance to central controls falls below 95%; audit findings remain open beyond 30 days; ownership metadata is incomplete or inconsistent across domains. → Mitigation: Centralize standards, not delivery. Require every domain AI product to name an owner and steward. Freeze new domain releases when conformance drops below threshold.

Pitfall: Unmanaged external model egress exposes restricted data to third-party processing paths. This is the fastest way to expand the governance surface without noticing it. → Detection: Redaction or tokenization coverage for restricted data falls below 99%; audit-log completeness for high-risk transactions falls below 95%; sampled prompts show sensitive-attribute leakage above 1%. → Mitigation: Apply External AI Boundary Control as mandatory, not optional. Minimize payloads before egress. Disable external calls when coverage drops below threshold.

Pitfall: Static governance decisions outlive the workload that justified them. Agent systems drift by accretion: new tools, new connectors, new memory, same old classification. → Detection: Architecture review passes, but operational evidence no longer matches the original assumptions; exception volume rises while design docs stay unchanged. → Mitigation: Review quarterly. Re-certify pattern selection whenever the operational envelope changes. In practice, most production-grade estates end up hybrid; the mistake is pretending they are not.

Asset: Governance Pattern Selection Worksheet and Control Allocation Matrix

Use this worksheet to force one decision early: which governance pattern owns the primary control path, and which controls sit at each boundary. Do not let teams answer this with org-chart logic or tool preference. Set the decision boundary on risk, data sensitivity, and egress.

Pattern Selection Worksheet

Copy-paste and complete for each AI system before design approval.

• System name: ______
• Business owner: ______
• Technical owner: ______
• Risk tier: Low / Medium / High
• External model invocation: Yes / No
• Regulated or high-sensitivity data in context payload: ____%
• Full lineage to source required for audit: Yes / No
• Bounded subset of enterprise data exposed to model: Yes / No
• Domain team can meet central architectural contract for policy, logging, and access control: Yes / No

Select primary pattern (one only):

• [ ] Enterprise Trust Fabric — high-risk; regulated or high-sensitivity data >25% of context payload; full lineage mandatory
• [ ] AI Control Plane — medium-risk; runtime mediation available; ≥90% of sources can onboard through policy-as-code gates
• [ ] Federated AI Domains — low-risk; mature domain ownership; domain can sustain ≥95% conformance to central controls

Apply overlays:

• [ ] Risk-Tiered Governance — mandatory for all systems
• [ ] External AI Boundary Control — mandatory for any third-party model call

Control Allocation Matrix

Control	Trust Fabric	AI Control Plane	Federated Domain	Control Owner	Evidence
Data classification	Primary	Reference	Consume	Data governance	Classification report
Lineage to source	Primary	Link only	Reference	Data platform	Lineage graph, audit trail
Data quality gates	Primary	Validate ingress only	Local checks	Data product owner	DQ scorecard
Prompt/context masking	Support	Primary	Consume	AI platform	Leakage sample rate
Output filtering and safety	No	Primary	Local extension	AI platform/domain	Policy logs
Access control	Primary policy	Enforce at runtime	Local role mapping	Security/platform/domain	Access audit
Audit logging	Source events	Runtime events	Domain events	Shared, named owners	Log completeness report
Exception handling	Central review	Central review	Domain remediation	Governance office + owner	SLA tracker
Semantic layer / ontology	Primary	Validate at action boundary	Consume domain semantics	Data governance + AI platform	Action coverage report (% of agent actions mapped to defined state transitions)

Acceptance criteria

• Require 100% of production AI systems to have:
• documented risk tier
• primary pattern
• overlay status
• named control owners
• Reject release if any control has no owner.
• Revisit pattern choice if post-deployment exceptions exceed 10% or classification accuracy drops below 90%.

Decision Matrix by Failure Mode

The risk-tier rule is the default for new systems. Use this matrix when you are remediating an existing estate and the symptom is more obvious than the risk classification — pick the pattern that closes the actual gap.

Symptom or failure mode	Threshold or signal	Primary pattern	Add-on	Avoid
Auditability is the main failure	Evidence retrieval >4 hours; lineage <95% on regulated flows	Enterprise Trust Fabric	AI Control Plane	Runtime controls without lineage
Unsafe runtime behavior is the main failure	<90% deployments through gates; policy violations >2% of sessions	AI Control Plane	External AI Boundary Control	Policy documents without enforcement
Organizational scale is the main constraint	5+ autonomous domains; >3 business units deploying AI independently	Federated AI Domains	Shared Trust Fabric + AI Control Plane	Centralized-only ownership
External model usage is material	Sensitive data crosses third-party model or tool boundary	External AI Boundary Control	API-management-inspired AI gateway	Direct-to-model bypass
Mixed-risk portfolio in one pipeline	High-risk and low-risk workloads share a single review path	Risk-Tiered Governance	Federated execution where appropriate	One-size-fits-all governance
Agent tool calls produce semantically invalid actions or unsafe state transitions	Free-form actions >5% of agent action volume; tool effects not specified as state transitions	Enterprise Trust Fabric with ontology layer	AI Control Plane action validation	Output filtering as the only safety net

Use the risk-tier composition when starting a new system from scratch. Use this failure-mode matrix when fixing what already exists.

The worksheet is not paperwork. It is the mechanism that prevents fragmented controls, shadow governance stacks, and runtime-only governance where pre-consumption controls are required.

What this Field Manual does NOT yet prove

The framework above is opinionated, and the specific numerical thresholds throughout are operational defaults from advisory practice — they have produced safe rollouts in the engagements we used them in, but they are starting points, not industry consensus. We are calling that out explicitly so readers can apply the patterns with calibrated confidence:

• The 25% context-payload threshold for routing a workload into Trust Fabric is the heuristic we use to force an explicit conversation about regulated data exposure. The directional rule (more regulated data → stricter governance pattern) holds; the precise percentage may not generalize across industries. Calibrate against your own audit profile.
• AI Control Plane SLOs (≥99% policy enforcement success, <1% sensitive-attribute leakage, p95 <150 ms policy evaluation latency, ≥90% sources onboarded through policy-as-code) are runtime targets that have held in advisory engagements. They depend heavily on how mature your masking, classifier, and policy-as-code stack already is — measure your own baseline before adopting them as release gates.
• Federated domain conformance thresholds (≥95% conformance to central controls, 100% named owner/steward coverage, <30 day audit remediation) are starting points for federation that actually federates rather than fragments. Mature governance estates often run tighter; immature ones cannot meet these on day one and should phase in over 1–2 quarters.
• Trust Fabric data quality thresholds (≥95% lineage completeness, ≥98% PII classification coverage, <2% critical data quality rule failure) are operational defaults; the right floor depends on the data domain and the cost of a downstream model decision based on a misclassified record.
• Exception and review cadence (<7 day high-risk exception closure, <14 day medium-risk, ≥95% quarterly control review completion, <15 business day medium-risk governance clearance, 24-hour sustained DQ breach alert window, 3-consecutive-interval policy-latency alert) are SLA defaults from advisory practice. Adjust to your incident volume and remediation capacity.
• External AI Boundary Control thresholds (≥99% redaction/tokenization coverage for restricted egress, ≥95% audit-log completeness for high-risk transactions) are floors, not ceilings — high-stakes regulated workloads frequently require tighter coverage than these defaults.
• Classification and review-acceptance targets (≥90% risk classification accuracy, <10% post-deployment wrong-pattern exceptions, ≥90% first-pass architecture review acceptance, ≥85% alert threshold over 2 review cycles) are goal states to drive into, not release gates. Real-world early-stage governance programs frequently land lower; treat these as direction-of-travel signals.
• The decision-matrix failure-mode triggers (>4-hour evidence retrieval, <90% deployments through gates, >2% policy violations of sessions, 5+ autonomous domains, >3 business units deploying AI independently) are diagnostic shortcuts for remediating an existing estate, not formal classification rules. Use them to start a pattern-fit conversation, not to settle one.
• Ontology as a Trust Fabric primitive for agentic workloads. The framework treats the semantic/ontology layer as an emerging Trust Fabric sub-component — schemas describe data, ontologies describe what’s real and what’s a valid state transition. The threshold for when a workload requires an explicit ontology layer (vs relying on classification + lineage alone) is not yet calibrated against action-space breadth, tool-call diversity, or regulated state-transition workflows. See Bal Bhandari’s “Palantir’s Real Secret Sauce” for the directional argument; build your own threshold against your action-space breadth.

We are building a public reference implementation that exercises the composed-governance model end-to-end. Until that ships, this Field Manual is principles-with-citations, not principles-with-deployable-proof. Use the framework, but verify in your own environment before betting on the specific thresholds. If you measure something different in your own workload, trust your number — and tell us.

---

Share This:

Hook: “Stop standardizing AI governance on one platform pattern; standardize on risk-tiered pattern selection instead.”
– Use Trust Fabric for high-risk workloads, AI Control Plane for bounded medium-risk flows, and Federated Domains only where teams can meet central architectural contracts.
– Avoid runtime-only governance for audit-heavy data and avoid federation without measurable conformance, ownership, and remediation discipline.
– Metric to watch: 100% of production AI systems should ship with a documented risk tier, primary pattern, and overlay status before release.
Asset: Pattern Selection Worksheet → [link]