Platform.
The governed stack, in detail.
For readers who already know what they need, this is the depth behind it.
Where this picks up
You already know the problem.
This page assumes the diagnosis has already happened and that governance emerged as part of the answer, so it does not re-argue the case.
Instead it documents how the system is constructed underneath, in sufficient detail to argue with.
If that conversation has not happened yet, the assessment is a more productive starting point than this architecture.
The one claim that matters
Rules live in the data.
Business rules are enforced in the database itself, through triggers, functions, and row-level policy, and that is the whole architectural bet.
It is also the only claim on this page worth arguing about.
Rules written in an application can be bypassed by anything that talks to the database directly. Rules written as database triggers bind every writer, including the service account the application runs as.
The system operates with no AI whatsoever, and when AI is introduced it runs on top, inside the same triggers and policies as every other writer.
Rules in code can be bypassed. Rules in triggers bind every writer.
What governance means here
Every edge is a decision.
A state machine advances work from one state to the next, and every one of those transitions is an edge.
In most systems an edge is merely plumbing, but here every edge is a decision with an owner, a reason, and a durable audit record.
The same discipline applies on every consequential edge, whether a human, a rule, or a model proposed the change, because governance is not a review step appended afterward; it is the shape of the transition itself.
How much a model is allowed to do
Autonomy is earned.
Every orchestrator starts fully deterministic and stays there until something measurable says otherwise.
The levels below are the ladder a model has to climb, and the status shown on each level is current.
Most of them say not yet, which is deliberate, because an unclimbed ladder, shown honestly, is the accurate picture of the system today.
Autonomy ladder · earned, not bought
Level 0 floorin place
Deterministic and rules only: the orchestrator runs by manifest while the mirror watches the work and learns the way, and no model writes touch the substrate.
Model+++ gate to Level 1standard, being authored
A measurable validity standard, and the first gate any mirror has to pass to leave Level 0. Validity is tested against outcomes rather than vendor decks, and bias is evaluated and published. Every decision that matters carries a rationale a human can read, and the standard is open to outside audit before the dial moves.
Level 1 suggestnot yet
The mirror proposes and humans dispose: it drafts inside the orchestrator's manifest, and the operator and the orchestrator review every draft before anything lands.
Level 2 assist in scopenot yet
Named operations inside a named scope. The mirror executes a defined subset of the orchestrator's allowed operations, and every transition is reversible or has a compensation procedure on file.
Level 3 operatenot yet
Day to day work inside the envelope. The mirror runs the orchestrator's routine work while exceptions and approvals still route to humans, and the audit trail still tells the whole story.
Level 4 earned latitudenot yet
The mirror proposes additions to its own manifest, Number One reviews them, the operator signs off, and the Compass still rules above it all. Approval and exception handling remain human, permanently.
The five guarantees
What holds on every decision.
These guarantees apply to every consequential action in the system, and the application’s own service account is bound like any other writer.
A named human holds it
Every consequential decision has a named person attached to it, and the system never acts alone on anything that matters.
An explicit confirm step
Nothing commits without an explicit accept or override from that person, and there is no silent path around the confirmation step.
A durable audit trail
Every confirmed action lands as a queryable row in the audit trail, so you can ask the record questions months or years later.
A worker-readable reason
Any decision affecting a person carries a plain-language reason, written where the person it affects can actually read it.
Rules in the data
Enforcement sits in the database itself, so an AI cannot write outside the rules it was given, and switching that enforcement off is a change to the database rather than an application call.
How it sits in your stack
Keep, replace, add.
You do not have to choose between one suite and best of breed, because Cassion sits underneath the systems you already operate.
Keep what is working
Payroll, background check, and license verification remain where they are, and Cassion orchestrates them rather than replacing them, because they continue to earn their place.
Replace the front-office seats
ATS, VMS, and CRM seats can migrate to lighter Pedagogue applications on a shared governance backbone, and the savings there are seat savings, which is precisely how we scope them.
Add the governance layer
The governance layer is the component no current vendor offers today, and the component every AI deployment eventually discovers it needs.
The products.
Cassion
The governed data foundation and the system of record for the entire staffing lifecycle, from application through payment.
Compass
The rules layer for matching, where the rules are yours and policy authority remains with you rather than with the model.
Almanak
One product across phone and web, where what a person sees follows their role and their context rather than their device.
Next step
Bring us the hard part.
If you want to argue with the architecture, that is a good conversation and we would rather have it early.
Talk with us.You will be asked your name, your role, and what brought you here.