Growing Teams Hit an Evidence Problem
A five-person team runs approvals in Slack and tracks refunds in a spreadsheet. The story lives in one person's head.
That works until it does not. A customer asks "who approved that refund?" Nobody can answer without digging through three systems.
The problem gets worse as teams add AI to triage. It gets worse when plugins trigger actions in Stripe or an ERP. It gets worse when a second shift works tickets that started in a Slack thread they never saw.
At some point the team needs one place where the work happens. Approvals are enforced there. Evidence survives there.
Most teams try to solve this with one of three tools. Each covers part of the problem. None covers all of it.
Three Common Approaches Fall Short in Different Ways
Approach 1: A ticketing system (Zendesk, Jira, Freshdesk). Ticketing systems are the operational workhorse. They handle intake, routing, queues, and human workflows. But they have no approval steps on sensitive actions. They do not enforce which operators can trigger which downstream changes. The audit trail lives in text comments. The operator writes "processed refund" in a ticket note. There is no structured evidence of what was approved or what was executed. There is no record of what Stripe returned. The work happens. The evidence is scattered.
Approach 2: A governance or compliance platform. These systems manage policy, risk registries, and compliance reporting. They operate above the work. They confirm three things: the system is approved, the operator is credentialled, the policy is active. They cannot tell you what the AI recommended on a specific ticket. They cannot tell you what the operator chose. They cannot tell you what the downstream system returned. Most startups do not have a governance platform yet. It is not even on their radar. The underlying need for provable decisions is.
Approach 3: An AI copilot. Copilots excel at what they do: generating summaries, classifying work, suggesting next steps. But they have no execution boundary. There is no gate between the AI's recommendation and the operator's action. No record shows what the AI recommended or what the operator did. No record shows what was blocked or what was approved. If the operator acts on a recommendation that turns out to be wrong, there is no structured evidence of the decision point.
Each of these is a real product category. Each solves part of the problem. None alone solves the problem that emerges when decisions lead to sensitive actions across system boundaries. Those actions must be provable later. A manager asks "what happened?" An auditor asks the same question months later.
A category of operational software is forming at this intersection. This post defines what the category is and what it is not. It explains why the category exists.
This Category Combines Five Capabilities on One Record
The runtime control layer combines five capabilities into one operational surface.
First: Unified intake that preserves context across channels. Tickets arrive from email, other ticketing systems, API signals, forms, or manual entries. The system consolidates them into a single operational record. Context travels with the ticket through handoffs, reassignments, and escalations. The record is the ticket — not a pointer to a ticket in another system. Context does not get lost in a handoff. There is nowhere else for the ticket to live.
Second: AI recommendation with policy-bounded execution. AI assists with classification, prioritisation, summarisation, and suggested next steps. AI outputs are bounded by policy. Some recommendations are advisory only. Some require human review before any action can proceed. Some are blocked entirely based on ticket type, risk tier, or operator role. The boundary between "AI suggests" and "operator acts" is explicit and enforceable. It is not implicit or aspirational.
Third: Approval and role enforcement attached to the ticket, not a separate system. Approval logic lives on the ticket workflow itself. The operator sees what they are authorised to do. Actions that require additional approval are gated at the point of execution. Denied and blocked actions are recorded as evidence. They are not swallowed silently in a log somewhere else.
Fourth: External action execution with result capture. The operator can trigger sensitive downstream actions from inside the ticket — payment reprocessing, entitlement changes, service modifications, escalation workflows. The system captures what was requested and what was authorised. It captures what actually executed and what the downstream system returned. The action result writes back into the ticket timeline. It does not disappear into a separate system's logs.
Fifth: Immutable, ticket-linked audit trail. The complete operational history stays on the ticket record: intake, AI recommendations, operator decisions, approval events, blocked attempts, external action results, status changes. The trail is append-only. It is not reconstructed after the fact from screenshots, chat messages, or operator memory.
The defining characteristic is that the ticket record is both where the work happens and where the evidence lives. These are not two systems connected by an integration. They are the same system.
This is what separates the category from its neighbours. Governance platforms manage policy above the work. Ticketing systems manage tickets without governing the actions. AI copilots recommend without bounding execution. The runtime control layer does intake, govern, execute, and prove on one record.
This Category Is Not Four Adjacent Tools
Four adjacent categories overlap with the runtime control layer. They are different things.
It is not a GRC platform. Governance, Risk, and Compliance platforms manage AI registries, policy libraries, risk assessments, and compliance reporting. They sit above the operational layer. They answer questions like these: "Is this AI system approved?" "Who is the risk owner?" "When was the last review?" They do not handle tickets. They do not execute actions. They do not preserve runtime evidence. GRC platforms map to ISO 42001 Clause 8, NIST AI RMF Govern and Map functions, and EU AI Act Articles 9 and 10 conformity assessment requirements. A runtime control layer needs a GRC platform above it. The GRC platform cannot substitute for the runtime layer.
It is not a workflow automation tool. Workflow automation platforms, iPaaS systems, and orchestration engines can trigger actions across systems. They route work based on rules and chain steps together. But they do not enforce approval boundaries at the point of execution. They do not attach role-based access to specific ticket actions. They do not preserve denied paths as evidence. They do not keep the audit trail on the ticket. A workflow automation tool might sit behind the runtime control layer as an execution engine. The engine does not provide the governance surface.
It is not an AI agent framework. AI agent frameworks let developers build systems where AI reasons and plans. Those systems execute tool calls autonomously or semi-autonomously. They work well for building AI capabilities. But they are not designed to preserve ticket-level evidence of each decision. They do not enforce human approval gates on sensitive actions. They do not produce audit trails that survive regulatory scrutiny. An AI agent framework might power the AI inside a runtime control layer. The framework alone is not the layer.
It is not a ticketing system with plugins. Traditional ticketing systems handle intake, routing, assignment, and status tracking. Some support plugins or integrations that extend functionality. But the plugin model typically pushes execution outside the ticket. The operator clicks a button. They switch to another system. They perform the action. They switch back. They type a note. The audit trail is whatever the operator remembered to write down. A runtime control layer keeps execution inside the ticket. It captures structured evidence. It does not rely on free-text notes about what happened elsewhere.
Adjacent Categories Sit Above, Beside, and Below the Layer
The runtime control layer does not exist in isolation. It sits within a broader operational and governance stack.
Above: Governance and compliance platforms. These manage the approval layer: AI registries, risk assessments, policy libraries, release packets, review cadences. They map to ISO 42001 Clause 8, NIST AI RMF Govern and Map functions, and EU AI Act Articles 9 and 10 conformity assessment requirements. The NIST AI RMF treats approval and monitoring as integrated parts of one lifecycle. That is architecturally correct. In practice, most organisations implement them in separate systems. The runtime control layer depends on governance platforms for policy inputs and implements the policies they define. It does not replace them.
Beside: AI observability and monitoring tools. These watch model behaviour at the system level: performance metrics, drift detection, anomaly detection, latency, error rates. They map to ISO 42001 Clause 9, NIST AI RMF Measure function, and EU AI Act Articles 12 and 26 logging and monitoring requirements. The runtime control layer generates evidence that observability tools can consume. Observability tools do not capture ticket-level decision context. They do not know why a specific operator made a specific choice on a specific ticket.
Below: Execution engines and external systems. These are the downstream systems where actions actually happen: payment processors, CRM systems, entitlement databases, communication platforms. The runtime control layer calls them and captures their responses. It writes the results back to the ticket. The execution engine does the work. The runtime control layer governs and records it.
Overlapping: MLOps and model management platforms. These manage the model lifecycle: training, versioning, deployment, monitoring. They answer "Which model version is in production?" and "How is it performing?" They overlap with the governance layer on model versioning. They overlap with the monitoring layer on performance tracking. The runtime control layer consumes model outputs. It does not manage model lifecycles.
Who Needs This: Not Every Workflow Does
Not every workflow needs a runtime control layer.
You probably need this when:
- Decisions lead to sensitive downstream actions — refunds, vendor changes, account modifications, escalations — and someone might ask "who approved that?" later.
- Operators handle tickets where AI recommends and humans decide. The decision must be provable afterward.
- Workflows cross system boundaries. The action happens in Stripe, an ERP, or an internal API — not in the same tool where the ticket lives.
- The team is growing. What one person could track in their head now needs to be visible to a manager, a second reviewer, or a new hire.
- AI capabilities are changing. New models, new prompts, new retrieval sources, new plugins appear regularly. A static configuration document cannot describe what the system did on a given day.
You probably do not need this when:
- The AI system is a stable batch pipeline with well-defined inputs and outputs — document classification, OCR extraction, data enrichment. Simpler approval and monitoring may be sufficient.
- AI is purely advisory with no downstream action. An operator reads a summary, but all execution happens manually in other systems with their own audit trails.
- The workflow is internal-only with no customer or financial exposure.
- The team is small enough and the workflow is stable enough that the current process (even if it is Slack and spreadsheets) genuinely works.
This is not a maturity spectrum where every team eventually needs the full stack. Some workflows genuinely do not require ticket-level control. The category exists because some workflows genuinely do. Sensitive actions, multiple systems, and the need to prove what happened create a problem that no single adjacent tool solves alone.
Latch Fits as One Implementation of This Category
Latch is one implementation of this category.
It maps to the five core capabilities. Unified triage consolidates email, tickets, and operational signals into a single ticket record. AI recommendations are bounded by policy — advisory, reviewable, or blocked depending on workflow configuration. Approval and role enforcement attach to the ticket. Operators see what they can do. Actions require appropriate authorisation. External action execution happens from inside the ticket. The system captures what was requested and what was authorised. It captures what was executed and what was returned. The audit trail stays on the ticket record. It is append-only and ticket-linked. It survives after the action completes.
Latch does not manage AI model inventories. It does not run conformity assessments. It does not store enterprise risk treatment documents. It does not provide system-level observability dashboards. Those responsibilities belong to the governance, compliance, and monitoring layers that sit above and beside it.
The point is not that Latch is the only way to build this layer. The point is that this layer needs to exist. Teams who try to fill it with only a governance platform, only a ticketing system, or only an AI copilot will find the gaps when an auditor, a manager, or a regulator asks what actually happened on a specific ticket.
Continue Reading
- How Four AI Governance Frameworks Handle Approval vs. Runtime Evidence
- Governance-First Approval Systems for AI: What They Prove, What They Miss, and Where Runtime Evidence Fills the Gap
- AI Triage Needs a Control Plane, Not Just Better Prompts
- Case Records Should Be Systems of Action, Not Just Systems of Record
- See Approvals in Latch
- See Auditability in Latch