Governed workflows
Workflows where the approval gate, the evidence and the record are part of the workflow itself, so the people who must approve are in the loop and the proof is a by-product.
The word "approved" here means each decision in the workflow is taken by a named person who is allowed to take it, and recorded. It does not mean the workflow is certified by anyone. We build for compliance-by-design: the technical controls and evidence that can support an organisation in meeting its own obligations.
A normal workflow moves work from step to step. A compliance-approved workflow also decides who may take each decision, holds the work until they have, and keeps a record of who decided what and on which evidence. The agent does the preparation: collecting, checking, drafting, comparing. The person does the approving.
The design goal is that an auditor, a regulator or a colleague can read the run afterwards and answer the usual questions without reconstructing them from email: who approved, were they the right person, what did they see, when, and what happened next.
Four properties, each with its status shown in the table below.
A human-input step pauses the run, names an assignee, offers approve and reject branches and carries a timeout. A gate can be nudged, escalated to a named fallback and parked. It does not approve on its own.
Each run writes policy decisions, approvals and actions to a ledger, chained so that tampering is detectable, with a call that verifies the chain.
Two different people for request and approval. A platform check for this is designed for. Today you enforce it by assigning the gates to different people.
Decide, with your records team, how long each record is kept and when it is erased. Erasure tooling exists in the platform but is not exposed as a feature yet, and legal hold is limited to chat records today.
The same shape applies to a refund, a change, a vendor or an access review.
A request arrives from a form, a ticket, a schedule or an alert.
An agent collects the inputs, checks them and drafts the recommendation. It cannot act on it.
The workflow stops at a human-input step addressed to the right approver.
The approver approves, rejects or sends it back. The decision, the decider and the time are recorded.
Only after an approval does the workflow take the action, or hand it to the system that does.
The ledger holds the whole run. You read it as an auditor would.
Swfte provides the technical controls, governance mechanisms and evidence required to deploy AI within an organisation's applicable regulatory, security and policy requirements. The exact posture depends on the customer's use case, jurisdiction, deployment and configuration.
Concretely: we do not tell you that a workflow is compliant. We give you gates, records and a way to verify the records, and we show you in this page where the platform does not yet do what you may expect. Whether a given workflow meets a given obligation is for you and your counsel to decide, and this page is not legal advice.
Our own content pipelines are defined as Swfte workflows: a writer agent, an AI fact-check reviewer, an editor and a second review. Those review steps are automated quality checks, and there is no human approval step in the definitions, so we do not present them as a compliance workflow. The decisions we hold for people are the ones in our story: signing a release, and keeping a live payment test. A worked example of a workflow with a human gate that we run on ourselves is not published yet: <real example of an approval Swfte routed through Nexus - founder to fill>.
Built means the product can do it today. Designed for means it is the intended design and is not built yet. We give no dates.
| Practice | Status | What we can point to |
|---|---|---|
| Human-input step with assignee, branches and timeout | Built in the product | Pauses the run and resumes on a decision. A decision cannot approve a later gate. |
| Gate escalation: nudge, escalate, park | Built in the product | Gates are addressed to a person with a named fallback. Auto-deny and auto-approve are refused. |
| Run ledger with hash chain and verify call | Built in the product | Seal of the chain head is opt-in. No dedicated export yet. |
| Human attestations against controls | Built in the product | The certification feature records a person signing a statement about a control, with signed certificates and an evidence hash. |
| Templates for the processes on this page | Designed for | Two shipped examples with human gates exist. The ten processes named here are starting points or designs. See the templates page. |
| Platform-enforced segregation of duties | Designed for | No check that the approver differs from the requester. Approver roles and delegation are also not built. |
| Retention policy and legal hold on workflow records | Designed for | Retention periods are <retention period - set by the customer, not by Swfte>. An erasure routine exists as a library and is not exposed. Legal hold exists only for chat records. |
| One approval inbox across the platform | Designed for | Approvals exist in several parts of the platform with separate models. |
How to read the status
One workflow written as Can, Cannot, Requires approval and Records. Eleven more are on the templates page.
A refund recommendation is approved by a person for amounts above the threshold, and every refund has a record.
Workflows have a human-input step with approve and reject branches, and a customer-support agent sample exists. The refund policy and the payment hand-off are yours to add.
| Can | Cannot | Requires approval | Records |
|---|---|---|---|
|
|
|
|
A governed workflow produces records that an organisation can use as evidence in its own compliance work. The table says what each framework asks about, what the records can support, and what they do not do.
| Framework | What it asks about | Supports evidence for | What it does not do |
|---|---|---|---|
| EU AI Act | Record-keeping and human oversight for high-risk systems (Articles 12 and 14). | Approval decisions with decider, time and options; a per-run ledger with a verify call. | Does not classify your system or decide whether the obligations apply. That is for you and your counsel. |
| GDPR | Accountability and records (Article 5(2) and Article 30); impact assessment where required (Article 35). | The DPIA intake record with the officer’s sign-off; who accessed what, in the ledger. | Does not decide lawful basis or reach the assessment conclusion. Erasure tooling is not exposed as a feature yet. |
| NIS2 | Risk-management measures and incident handling (Articles 21 and 23). | Incident timeline, with approvals for containment and communications. | Does not file reports with authorities or decide your entity status or deadlines. |
| DORA | ICT incident management and third-party risk for financial entities. | Incident timeline; vendor onboarding records and sign-offs. | Does not keep a register of information or classify an incident as major. |
| ISO 27001 | Change management, access control and supplier relationships (Annex A controls). | Change approval and access review records; vendor onboarding sign-offs. | Does not replace your management system or your audit. |
| SOC 2 | Logical access and change management criteria. | The same records, as supporting evidence for your own controls. | Does not produce a report. That depends on your auditor. |
This table is a map of evidence, not a statement of compliance. The exact posture depends on your use case, jurisdiction, deployment and configuration. It is not legal advice.
Procurement, access review, change and release approval, vendor onboarding, DPIA intake, incident response, KYC review, policy attestation and refund approval, plus two shipped examples with human gates. The page says which exist today and which are designed.
A workflow where each decision is taken by a named person who may take it, the work waits until they have, and the decision and its evidence are recorded. The agent prepares and the person approves. It does not mean any third party has certified the workflow.
No, and we do not claim it. It produces records and controls that can support the evidence you need for your own obligations. Whether it is enough depends on your use case, jurisdiction, deployment and configuration, and on your counsel.
Not yet. A check that the approver is a different person from the requester is designed for and not built. Today you enforce it by assigning the request and the approval to different people, and by reading the ledger to confirm it.
A gate does not approve on its own. It is nudged, escalated to a named fallback and then parked, and it keeps waiting for a decision. Check the timeout behaviour of the step you use, and test it before relying on it.
You can read a run’s events and verify the chain through the API. A dedicated ledger export is not built yet. For a Model Vault there is a CSV export of its audit log. Ask us how your auditor’s format would be met.
Two shipped examples with human gates exist: a contract review with senior sign-off, and tiered sign-off for claims. For the ten processes named on this site, none ships as a ready-made template. Some have a starting point and some are designed only.
We map the records a workflow produces to the control families these frameworks ask about, and call it supporting evidence. We do not claim that a workflow satisfies them. The table on this page shows what each supports and what it does not do.
Start with one entry point. Add intelligence, agents, workflows and infrastructure as you prove value.
One platform for the agents, models and workflows your team ships. Free to start, no card required.