Why This Exists
While building AI systems, I kept coming back to the same question.
When a model participates in a multi-stage workflow, what additional system components become necessary? Not what would be nice to have, but what the system actually needs to stay coherent, traceable, and reviewable.
I chose insurance investigations as the environment to explore this because the domain has the right structural properties. Claims move through defined stages. Evidence is uploaded and analysed. Decisions require human sign-off. Actions need to remain traceable long after they happen. That combination of lifecycle progression, evidence handling, role separation, and auditability made it a useful stress-test.
The approach treats this as a systems problem rather than a model problem.
What was Built
Platframe is organised into seven subsystems, each with a specific responsibility.
Claims owns lifecycle state. It controls how an investigation moves from Draft through Evidence Collection, Active Review, Submitted Review, and eventually to a Closed Outcome. Stage transitions are explicit and governed. Nothing else moves the workflow.
Evidence handles ingestion, storage, and workspace context for uploaded files. It provides the material that downstream subsystems operate on.
VAAS is a served model that performs integrity analysis on image evidence. It produces anomaly scores, localisation signals, and visualizations. Its scope is bounded to the evidence itself.
Infera sits between the platform and whatever model is running. It evaluates execution policy, selects a provider, and records that decision before any inference happens.
Governance enforces validation rules and policy decisions across the investigation lifecycle. It consumes signals from VAAS and Infera and makes its own determinations.
OpsMate provides contextual assistance to analysts and reviewers. It reads from the investigation but never writes to it.
Operational Replay reconstructs investigation history after execution. Every meaningful event across all subsystems is collected, sorted, and made available as a timeline.
Following A Claim Through The System
An investigation starts in Draft. The analyst uploads evidence into Evidence Collection. VAAS runs integrity analysis on any uploaded images. The investigation then enters Active Review, where a reviewer examines the case.
If the reviewer is satisfied, it moves to Submitted Review and eventually closes. If something needs revisiting, it returns to Returned Revision and goes back to the analyst.
Every one of those transitions is explicit. Claims owns them. The workflow progresses through stage transitions performed by analysts and reviewers, not through model inference.
That distinction turned out to matter more than I expected once I was actually building it.
Interesting Design Decisions
A few decisions shaped how the system came together. I am noting them here not as prescriptions but as things that became clearer once the system was running.
Claims owns progression, not the model. Something has to own lifecycle state in an operational system. If that responsibility is implicit or distributed, inconsistency accumulates across transitions in ways that are difficult to trace back to a cause. Making Claims the explicit owner of that removed a whole class of ambiguity early on.
VAAS produces scores. Governance reads them.
VAAS runs inference and produces three raw scores: a global forgery signal, a patch localisation signal, and a hybrid decision signal. An operational mapping layer translates those into human-readable indicators: integrity risk level, manipulation likelihood, whether review is required, whether escalation is recommended, and a payout confidence impact. Governance then reads those indicators and records its own decision.
The reason to keep those concerns separate is that each can be inspected independently. If a governance decision looks wrong, you can look at the operational mapping. If the mapping looks wrong, you can look at the raw scores. There is a clear chain rather than a single opaque step.
OpsMate assists. It does not decide.
OpsMate has six actions: claim summary, evidence summary, integrity findings, suggested next steps, runtime traces, and explain route decision. Every action passes through a governance check and a role check before any context is assembled. The response is structured and read-only. OpsMate never writes to the claim, the evidence, or the workflow state.
There is also a prompt guardrail that blocks out-of-scope terms at the input layer. It felt slightly awkward to build, but it became useful as a signal during testing. When OpsMate started responding to things it should not know about, the guardrail made the boundary visible rather than silent.
Replay was treated as a first-class requirement.
Every subsystem emits events during an investigation: lifecycle transitions from Claims, uploads from Evidence, execution decisions from Infera, analysis outcomes from VAAS, policy decisions from Governance, and runtime traces from everything. The timeline builder collects all of those, sorts them by timestamp, and produces two views. A continuity view surfaces only the high-signal moments. The full runtime history keeps everything ordered.
The continuity view was its own design decision. Not everything that happens during an investigation is equally worth surfacing. Building a priority classification into the event model meant replay could present a readable investigation narrative rather than a raw log dump.
Insights
A few things became clearer through building this rather than just thinking about it.
Separation is an operational tool, not just an architectural preference. The reason to keep evidence analysis separate from governance decisions is not elegance. It is that each can be inspected and reasoned about on its own terms. That becomes important when something does not behave as expected and you need to understand where in the chain things diverged.
State ownership needs to be explicit. In any system with multiple components that could plausibly advance workflow state, leaving that responsibility implicit invites inconsistency. The earlier I named an explicit owner for each piece of state, the less time I spent debugging unexpected behaviour.
Replay is not a log viewer. Treating it as a first-class requirement changed how I thought about what each subsystem needed to emit. Components designed with replay in mind tend to produce cleaner state boundaries than components where traceability was added afterward.
Assistance and decision-making behave differently in practice. The distinction between OpsMate supporting an analyst and OpsMate controlling an outcome felt abstract when I first designed it. In practice it shaped everything from the response schema to how governance interacts with it. Making that boundary structural rather than instructional was worth the effort.