AIdeas: RTC — Runtime Trust Calibrator

Ever wished your LLM came with a speedometer for overconfidence? This AWS-native system adds structural risk scoring and adaptive inference-time controls to measure, calibrate, and regulate commitments before responses reach users—turning black-box AI into auditable, enterprise-ready infrastructure built on Amazon Bedrock and ECS Fargate.

Arijit Chatterjee

BI Architect at Sears Holdings India

Published Feb 20, 2026

Last modified Apr 9, 2026

AIdeas: RTC — Runtime Trust Calibrator

Making LLM behavior observable and controllable at inference time

One-line summary: RTC intercepts LLM responses at inference-time and applies a 4-stage governance pipeline so high-risk outputs are corrected or blocked before users see them.

Tags: #aideas-2025 #commercial-solutions #APJC

App Category

Commercial Solutions

RTC is built for teams deploying LLMs in production settings where response quality, reliability, and auditability directly impact business risk. Every enterprise shipping AI-powered features into regulated or customer-facing workflows faces the same challenge: how do you ensure that what the model says is not just fluent, but trustworthy? RTC is the answer to that question.

My Vision

There is a particular kind of failure that keeps me up at night — not the dramatic kind, where a model hallucinates a vivid lie that anyone can spot, but the quiet kind. The failure where the model says something that sounds completely reasonable, confident, and well-formed, and is wrong in exactly the way that causes a user to make a bad decision.

I call it a quiet failure.

And I built RTC to help mitigate the risks due to quiet failure.

Consider a user asking a medical assistant: "I have chest pain after exercise. What is it?" A poorly governed LLM might respond: "This is likely acid reflux or muscle strain. Take ibuprofen and an antacid. You'll be fine in a few days." No fabricated facts. No internal contradiction. Fluent, confident, helpful-sounding — and potentially dangerous. The model committed to a diagnosis without adequate grounding, expressed certainty it had no right to, and failed to surface the cardiac causes that a responsible clinician would immediately flag.

That is the problem space. And what makes it hard is that conventional quality checks miss it entirely. Static guardrails block explicit violations. Post-hoc moderation catches obvious harms. But neither mechanism operates at the moment when commitment is formed — during generation, before the response reaches the user. That gap is where quiet failures live.

My vision for RTC is built on a simple but important premise: an LLM response should not reach users unless it passes measurable, auditable quality gates. Not prompt-level heuristics. Not vague guidelines. Actual thresholds, actual scores, actual decisions — logged, explainable, and tunable by the teams who care most about the risk.

The Dual Benefit: Observability and Regulation

RTC delivers two distinct, compounding benefits that together solve what existing tools cannot.

The first is observability. LLMs are, by default, black boxes at inference time. You see the input. You see the output. What happens in between — how committed the model is, whether its certainty is grounded, whether it is drifting across turns — is invisible. RTC makes that visible through runtime metrics: commitment-risk scores, evaluative coherence indices, admissibility signals, and cumulative interaction risk. For the first time, teams can see why a response is risky, not just that it is.

The second is regulation. Observability without action is monitoring, not governance. RTC uses the same metrics it surfaces to actively shape, gate, and correct responses before delivery. The scores drive decisions. The decisions are enforced. The enforcement happens before the user ever reads a word.

Together, these two benefits transform the LLM from an opaque generation engine into a governed production system — one where behavior is measurable, decisions are auditable, and commitment is conditional on evidence.

Inference-Time Governance Flow. Reliable responses emerge from a simple ordering: evaluate internal support, inhibit premature commitment when necessary, and calibrate expression strength to match available evidence.

The goal of that governance has a name: AI Dignity.

A response that has AI Dignity is truth-respecting, uncertainty-calibrated, coherent, and non-manipulative. It says what the evidence supports. It acknowledges what it does not know. It does not inflate scope, fabricate authority, or drift under conversational pressure. AI Dignity is not an abstract aspiration — in RTC, it is a measured output. Every regulated response is evaluated against it, and the delta between baseline and regulated AI Dignity scores is the primary signal of governance quality.

Why This Matters

The most damaging failures in commercial AI deployments are rarely catastrophic. They are incremental.
A customer-facing assistant gives confidently wrong guidance on a warranty policy. A legal research tool returns language that sounds authoritative without meeting jurisdictional specifics. A multi-turn conversation, across six or seven turns, gradually drifts from grounded reasoning into user-pleasing agreement — each individual step small, the accumulated result a complete betrayal of the user's trust.

These failures share a common structure: the model is not incapable. It generates fluent, coherent, contextually appropriate output. The failure is in how strongly that output is committed — certainty beyond evidence, scope beyond justification, authority beyond qualification. This is commitment inflation, and it is the mechanism through which most commercial AI failures actually happen.

Static guardrails are not equipped to handle commitment inflation. They operate at the output level, catching explicit violations. They cannot distinguish between a response that is appropriately confident and one that is dangerously overcommitted on weak grounding. Post-training alignment, while essential, optimizes for expected behavior over training distributions. The moment a real-world query drifts outside that distribution, alignment gains erode.

What RTC addresses is the inference-time governance gap: the absence of a systematic, measurable control layer that operates during generation, before commitment becomes irreversible and before output is delivered.

For enterprise teams, this gap translates directly into business risk. In healthcare, overconfident AI outputs can delay life-saving care. In legal and financial domains, fabricated authority exposes firms to liability. In customer-facing deployments, trust erodes the moment users discover that confident-sounding answers were poorly grounded. In multi-turn agentic systems, sycophantic drift means the system stops being a reasoning partner and becomes a mirror for whatever the user already believes.

RTC closes that gap — without retraining, architectural overhaul, or access to model weights.

Demo

Live demo (Under 3 mins): https://dzjolgrloe7tc.cloudfront.net/demo-videos/RTC_Demo_Narrated.mp4

Try it now: https://d2937dv12xi0pw.cloudfront.net/

How I Built This

System Architecture

RTC runs as an API-first service deployed entirely on AWS. The model provider is Amazon Bedrock, using Amazon Nova Micro as the primary inference engine for both baseline and regulated outputs. The backend is a FastAPI service containerized and deployed on Amazon ECS Fargate. The frontend — a Gradio evaluation and testing interface — is similarly containerized on ECS Fargate. Both services are routed through an Application Load Balancer and fronted by Amazon CloudFront for HTTPS delivery and edge caching. Amazon CloudWatch handles centralized logging and mechanism-level metrics. Amazon DynamoDB provides an optional, configurable audit trail for inference events. Amazon S3 stores all test-run artifacts by default, enabling persistent result analysis across runs.

The architecture is deliberately clean: the governance pipeline sits between the model and the user, with no model modifications and no LLM vendor lock-in. Bedrock handles inference. RTC handles regulation.

The runtime now supports a Strands-based execution engine that preserves the same governance order while improving observability and control. In Strands mode, baseline generation and swarm metric population run in parallel, and gate scoring consumes swarm metrics as the primary source with deterministic non-heuristic fallback only when required (timeout, invalid payload, or low confidence). This keeps governance decisions auditable while reducing end-to-end latency variance.

The Four-Stage Control Pipeline

The core of RTC is a four-mechanism pipeline, each mechanism addressing a distinct failure class, operating in strict invariant order: ECR → CP Type-1 → IFCS → CP Type-2.

Mechanism	Question Answered	Failure Class	Operation
ECR	Which continuation?	Selection failures	Comparative coherence scoring
CP Type-1	Whether to commit?	Illegitimate commitment	LLM-based admissibility gating
IFCS	How strongly to commit?	Commitment inflation	LLM-guided modality regulation
CP Type-2	Is the interaction drifting?	Interaction-level failures	Cumulative risk monitoring

Each mechanism addresses failures the others cannot. ECR cannot shape commitment — it only selects. CP cannot choose among candidates — it only gates. IFCS cannot ensure coherence — it assumes ECR has already provided a coherent candidate. CP Type-2 cannot see single-turn risk — it monitors accumulation. The decomposition is non-redundant by design

Stage 1: ECR — Evaluative Coherence Regulation
ECR generates multiple candidate continuations — K candidates, where K scales adaptively with structural risk (K=1 for low, K=2 for mid, K=3 for high-risk contexts). Each candidate is evaluated across five coherence metrics: evaluative variance bound, contradiction rate, trajectory smoothness, expectation stability, and policy divergence. These are aggregated into a Composite Coherence Index (CCI), and the highest-scoring candidate is selected.
This is the selection gate. Before any further processing, ECR ensures the response entering the pipeline is the most internally coherent one available. Responses that oscillate in confidence, reverse internal commitments, or drift semantically across reasoning steps score low and are discarded.
Stage 2: Control Probe Type-1 — Admissibility Gate
The Control Probe evaluates whether commitment is even admissible. It computes an evaluative support estimate σ(z) and compares it against an adaptive threshold τ (ranging from 0.62 for low-risk contexts to 0.72 for high-risk). If σ(z) < τ, the output is blocked entirely. No shaping, no softening. The response does not reach the user.
This is the hard gate. Fabricated facts, premature closure, capability misrepresentation — these fail the admissibility check and are suppressed before any further processing.
Stage 3: IFCS — Inference-Time Commitment Shaping
IFCS addresses the gray zone: responses that are admissible but dangerously overcommitted. It computes a commitment-risk score across five dimensions — evidential insufficiency (ê), scope inflation (ŝ), authority cues (â), commitment markers (m̂,) and tone pressure (t̂) — combined into a weighted risk functional:
R(z*) = λ₁·ê(z*) + λ₂·ŝ(z*) + λ₃·â(z*) + λ₄·m̂(z*) + λ₅·t̂(z*)
This gives stronger separation between harmless stylistic variation and true over-commitment risk.
When R(z*) exceeds the adaptive threshold ρ (0.42 default; 0.33 for high risk domains like medical / legal domains), IFCS applies a shaping operator that weakens universal claims, surfaces implicit assumptions, attenuates authority cues, and flattens early authority gradients — all without altering factual content. The model's what remains. The how strongly becomes honest.
Domain sensitivity emerges naturally from the scoring structure: medical and legal queries inherently lack context for definitive claims, so evidential insufficiency scores rise without any keyword matching or explicit domain classification. A strict heuristic-free runtime policy is enforced for regulation decisions: no regex keyword gating, no text-comparison shortcuts, and no fuzzy string matching in gate firing logic. If external metrics are unavailable, fallback remains semantic/statistical and conservative.
Stage 4: Control Probe Type-2 — Cumulative Interaction Risk
The final gate monitors the full interaction history, not just the current turn. It computes a cumulative risk score across all prior outputs and triggers a halt-and-reset when that score exceeds the adaptive threshold Θ (1.2 for low-risk contexts, 0.8 for high-risk). This catches sycophantic drift, semantic position reversal, and circular non-progress — the slow failures that no single-turn gate can see.

End-to-end request flow through the RTC stack.

AI Dignity as the Governing Metric

Across all four stages, the governing concept is AI Dignity: a response property defined by four dimensions — truth-respecting (claims are grounded), uncertainty-calibrated (confidence matches evidence), coherent (reasoning is consistent), and non-manipulative (no sycophancy, no authority inflation). Every regulated response is scored against this framework. The AI Dignity delta between baseline and regulated outputs is the primary signal of whether governance improved anything — and it is displayed directly in the UI alongside every test result.

Adaptive Thresholds and the 36-Case Taxonomy

Static thresholds fail across diverse prompt types. RTC uses structural risk tiers — low, mid, high — to adaptively set every threshold across all four mechanisms. Validation was conducted against a comprehensive taxonomy of 36 quiet failure modes spanning inference-local failures, interaction-level failures, and lifecycle failures, that I derived after collecting drifts and biases causing quiet failures and selecting those which can be mitigated at inference time.

The table below maps all 36 failure modes to their governing gate. Each mode has exactly one primary owner. No two mechanisms compete for the same jurisdiction.

Failure Mode	ECR	IFCS	CP-1	CP-2	Lifecycle
Point-in-time concept drift	✓	—	—	—	—
Data / covariate drift	✓	—	—	—	—
Embedding drift	✓	—	—	—	—
Compositional drift †	✓	—	—	—	—
Causal confusion †	✓	—	—	—	—
Availability bias	✓	—	—	—	—
Frequency / false-consensus bias	✓	—	—	—	—
Framing bias	✓	—	—	—	—
Implicature violation †	✓	⚠	—	—	—
Partial concept drift	—	✓	—	—	—
Fragile RAG grounding	—	✓	—	—	—
Temporal grounding failure †	—	✓	—	—	—
Anchoring bias	—	✓	—	—	—
Early authority gradient	—	✓	—	—	—
Halo effect	—	✓	—	—	—
Confidence miscalibration †	—	✓	—	—	—
Ambiguity collapse †	—	✓	—	—	—
Domain-specific overconfidence †	—	✓	—	—	—
Stereotype activation †	—	✓	—	—	⚠
Value smuggling †	—	✓	—	—	—
Fabricated facts	—	—	✓	—	—
Premature closure	—	—	✓	—	—
Capability misrepresentation †	—	—	✓	—	—
Ignorance masking †	—	—	✓	—	—
Context retrieval failure †	—	—	✓	—	—
Behavioral drift	—	—	—	✓	—
Semantic drift	—	—	—	✓	—
Value drift	—	—	—	✓	—
Boundary drift (role accretion)	—	—	—	✓	—
Authority laundering	—	—	—	✓	—
Sycophancy	—	—	—	✓	—
Circular non-progress	—	—	—	✓	—
Training data bias	—	⚠	—	—	✓
Benchmark overfitting	—	⚠	—	—	✓

† = failure classes identified and formalized during framework development. ✓ = primary governance responsibility.

⚠ = expression constraint only — the mechanism can attenuate surface manifestations but cannot fix the root cause.

Lifecycle failures originate outside inference-time and require training-time correction.

The framework achieved 100% boundary compliance across all 36 cases. Observed commitment reductions in IFCS-triggered cases, especially cases with high risk

Key Development Milestones:

Built the core trilogy pipeline with ECR, Control Probe, and IFCS orchestration
Added adaptive thresholds tied to structural risk tiers across all mechanisms
Fixed rollback and gate-trigger calibration issues identified through taxonomy testing
Implemented the full 36-case suite runner with live progress display and stop control
Added default S3 export for all suite run artifacts
Built the Analysis dashboard driven by the latest test-results JSON from S3
Deployed frontend and backend to ECS Fargate with CloudFront HTTPS delivery
Rebuilt runtime orchestration on a Strands-compatible execution path with backward-compatible API output.
Added parallel swarm metric population with primary metric consumption for CP-1, IFCS, and CP-2.
Added deterministic fallback policy for swarm timeout/error/low-confidence scenarios.
Added per-stage timing telemetry: baseline_ms, swarm_ms, ecr_ms, cp1_ms, ifcs_ms, cp2_ms.
Hardened LLM prompts across IFCS, ECR, and CP-1 to reduce semantic degradation while preserving gate intent.
Enforced us-east-1 region lock and Bedrock Nova in-region inference checks in runtime/deployment paths.

Results & Roadmap: The "Defense in Depth" Validation

RTC achieved a 100% mitigation rate of targeted 'Quiet Failures' across our 36-mode taxonomy, demonstrating the practical efficacy of the Invariant Order ($ECR \rightarrow CP \rightarrow IFCS$). Empirical data validates the system as a robust multi-layered defense: local gates (ECR and CP-Type 1) successfully neutralized 80.6% of inference-time instabilities and blocked 36.1% of underspecified responses, effectively preventing the LLM from issuing low-substance 'shallow' answers. In high-stakes multi-turn interactions, CP-Type 2 (the Interaction Gate) proved its value as a session-level fail-safe, correctly terminating 71% of scenarios where cumulative user pressure triggered sycophancy or stance-drifting (notably in Test 4.1 and 4.5). However, this level of exhaustive governance currently incurs a performance trade-off, with an average processing latency of 17.1 seconds. This identifies a clear engineering roadmap: the next iteration will focus on parallelizing the IFCS scoring logic via AWS Lambda to improve real-time responsiveness. Furthermore, we intend to refine the CP-Type 2 thresholds ($\tau$) to better distinguish between harmless stylistic shifts and dangerous value drift, ensuring that the 'AI Dignity' delta remains high without impacting user experience in lower-stakes conversational contexts.

The screenshots below walk through the key views of the RTC evaluation interface.

Screenshot 1: Hero view and pipeline overview

Screenshot 2: Single test case — mechanism firing trace

Screenshot 3: Baseline vs regulated comparison

Screenshot 4: All-36 suite run in progress

Screenshot 5: Analysis dashboard

Screenshot 6 — The Analysis tab reads the latest suite results from S3 and displays aggregate governance metrics. Every metric has an info button showing exactly how it is calculated — making the governance layer fully auditable, not just observable.

What I Learned

Building RTC taught me things I could not have arrived at theoretically. Some of the most important lessons came directly from how I used AWS — not just as a deployment target, but as active infrastructure that shaped what the governance system could actually do.

Observability Is Not Optional — And CloudWatch Made It Real
My first instinct was to build the governance mechanisms and think about monitoring later. That order was completely wrong. Until I could see what each mechanism was actually doing at runtime — which gates fired, at what rate, on which query types, with what threshold margins — I had no basis for calibrating anything. Every threshold I set blind either over-fired or missed the cases that mattered most.
Amazon CloudWatch became the feedback loop that made calibration possible. Gate firing rates, mechanism decision traces, risk score distributions across test runs — all of it streamed to CloudWatch and queryable in real time. When IFCS rollback logic was miscalibrated, the firing rate drop was immediately visible. When CP-1 was over-blocking on appropriately hedged responses, the admissibility threshold adjustment was obvious from the CloudWatch data. Without this visibility, I would have been debugging a governance system with no view into the governance. The lesson: you cannot regulate what you cannot observe, and observability infrastructure needs to come first.
Amazon Bedrock Eliminated the Inference Integration Problem
Integrating LLMs via vendor APIs introduces a web of latency, reliability, and versioning concerns that can completely swamp a research-engineering project. Amazon Bedrock abstracted all of that. I got a stable, managed inference runtime for Amazon Nova Micro without managing model endpoints, handling rate limits manually, or worrying about API version drift mid-development.
This mattered more than it sounds. The governance pipeline has strict ordering requirements — ECR must complete before CP-1, CP-1 before IFCS. Introducing latency unpredictability at the inference layer would have made it impossible to reason about pipeline timing and threshold calibration. Bedrock's consistency let me focus entirely on the control logic, knowing the inference layer was reliable underneath.
ECS Fargate Made Reproducibility a Correctness Requirement
The frontend and backend are separate ECS Fargate services, each containerized independently. This turned out to be one of the most consequential architectural decisions I made. When the IFCS shaping logic needed updating, I could redeploy only the backend without touching the frontend or interrupting ongoing inference runs. When a frontend task failed, ECS replaced it automatically. When I needed to scale the backend for 36-case suite runs, I did it without reconfiguring anything on the frontend side.
For a governance system where subtle calibration differences between runs would invalidate comparisons, reproducibility is not a convenience — it is a correctness requirement. Every Fargate task starts from the same image, in the same environment, with the same configuration. That consistency is what makes cross-run comparisons meaningful.
ALB and CloudFront Serve Distinct Stability Purposes
The separation between the Application Load Balancer handling origin routing and CloudFront handling HTTPS delivery turned out to matter in ways I did not anticipate. When I needed to push a frontend fix mid-run — a display update during the 36-case suite — I could invalidate the CloudFront cache without touching the ALB or interrupting any in-progress inference requests. The two layers serve different jobs: ALB maintains consistent backend routing, CloudFront maintains a stable, low-latency, always-HTTPS-accessible user-facing URL.
For a competition demo that needs to work reliably for evaluators at any time, this separation is essential. The live CloudFront URL has remained stable through multiple backend and frontend deployments.
S3 Turned Result Analysis Into an Iterative Engineering Practice
The 36-case suite generates substantial structured output: before/after commitment scores, gate firing traces, AI Dignity deltas, timing data. Early on, I was saving results locally — which meant every new run wiped the previous results, and comparing threshold configurations across calibration iterations was nearly impossible.
Switching to default S3 export for every suite run changed how I worked. I could run the full suite with one threshold configuration, archive to S3, adjust a threshold, run again, and pull both result sets into the Analysis tab for direct comparison. S3 became the persistent substrate for iterative calibration, not just a storage target. The Analysis dashboard reads directly from S3, which means evaluators can review the latest results from any browser without re-running anything.
Parallel governance only works when fallback behavior is explicit and measurable.
Running swarm metrics in parallel with baseline generation improved responsiveness, but the real gain came from strict fallback contracts: when swarm confidence is low or latency budget is exceeded, the system records why, switches to deterministic internal scoring, and still preserves gate semantics. Prompt quality in LLM-assisted gates also mattered more than expected; tightening rewrite constraints to preserve factual scope and certainty boundaries reduced real degradations without suppressing legitimate corrections.
Kiro Turned Research Specs Into Production Code
RTC began as a research framework — formal definitions, mathematical scoring functionals, mechanism taxonomies. The gap between that and a deployed, testable system is where most research projects stall. Kiro closed that gap.
Using Kiro's spec-driven development model, I could translate the formal architecture — the invariant pipeline ordering, the threshold configurations, the mechanism boundary contracts — directly into structured implementation requirements. Rather than holding the design in my head while writing code, Kiro kept the spec and the implementation in sync. When I added the LLM-guided IFCS rewriting module or the cumulative risk tracking for CP-2, Kiro's agent hooks automatically propagated those changes into the README and deployment documentation, so the documentation never drifted from what was actually running.
The result was a compression of the prototype-to-production timeline that would have otherwise been the bottleneck. The research was ready. Kiro made the engineering match it

The AWS Stack as Governance Infrastructure

Looking back, what I built on AWS is not just a hosted application. It is governance infrastructure — where every layer contributes to the reliability, observability, and auditability of the governance pipeline itself. Bedrock governs inference consistency. Fargate governs deployment reproducibility. CloudWatch governs mechanism visibility. S3 governs result continuity. CloudFront and ALB govern delivery stability.

The governance of LLM outputs and the governance of the infrastructure running the system are, in this architecture, the same problem approached at different layers. That is not a coincidence — it is what good AI governance infrastructure looks like when it is built deliberately.

Possible Next Steps:
"NREC (Non-Redundant Expression Control) — a between-turn feedback layer currently in design that closes the remaining governance loop. After each turn, a deterministic sidecar LLM consumes the full metric vector from RTC and generates a governance context injection for the base LLM's next turn — proactively reducing commitment risk before it accumulates, complementing CP-2's reactive halt. Dynamic Bedrock Guardrails integration — when RTC detects a sustained confidence gap across turns, it programmatically shifts the Bedrock Guardrails configuration from exploratory to restricted mode at runtime, without any human intervention."

Closing

RTC is a practical answer to a real problem: LLMs in production say things with more confidence than the evidence supports, and no mechanism between generation and delivery is designed to stop that. The result is a class of failures that are quiet, plausible, trust-eroding, and — in high-consequence domains — dangerous.

The dual benefit of RTC addresses this at both levels. First, it makes LLM behavior observable — turning commitment risk, evidential sufficiency, scope inflation, and authority cues into measurable, queryable runtime signals that break open the black box. Second, it uses those signals to actively regulate what reaches users — shaping, gating, and correcting before delivery.

RTC now exposes governance as runtime evidence, not just narrative claims: execution_engine, metrics_source, swarm_metrics_used, swarm_metrics_confidence, swarm_metrics_latency_ms, swarm_metrics_fallback_reason, and per-stage timings are emitted with each regulated run. This makes governance decisions inspectable at the same granularity as model outputs, which is what enterprise trust programs require.

The governing concept across both is AI Dignity: the property of a response that is truth-respecting, uncertainty-calibrated, coherent, and non-manipulative. Every response that exits the RTC pipeline is evaluated against it. Every deployment decision is made in service of it.

If you are shipping LLM features in production, baseline quality is not enough. Runtime governance is the missing control layer.
By thinking explicitly about stability at inference time — across selection, commitment, and expression — we move toward systems that are not merely fluent, but predictably reliable.

Not louder.
Not more cautious.
Just proportionate.

And that’s what enterprise deployment actually requires.

# aideas-2025 # responsible-ai # asia-pacific # APJC # commercial-solutions

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

AIdeas: RTC — Runtime Trust Calibrator

Arijit Chatterjee

AIdeas: RTC — Runtime Trust Calibrator

App Category

My Vision

The Dual Benefit: Observability and Regulation

Why This Matters

Demo

How I Built This

System Architecture

The Four-Stage Control Pipeline

Adaptive Thresholds and the 36-Case Taxonomy

Key Development Milestones:

Results & Roadmap: The "Defense in Depth" Validation

What I Learned

The AWS Stack as Governance Infrastructure