Building Compliance-Approved Workflows, Step by Step

To build a workflow that your compliance team can approve, start with the process and its owner rather than the tooling, and then add human decisions, evidence and tests in a fixed order. The steps below are that order. They work for any process where an AI agent prepares something and a person must decide: a purchase, an access request, a refund, a vendor onboarding. Each step says what to do, why, and what is built in the Swfte platform versus what you must supply yourself. The short version is that the platform provides workflow human input steps, approval gates and a hash-chained run ledger, while approver separation, retention and the template for your specific process are your job today. For the product context see compliance workflows and governed workflows in Studio.

Who owns the process, and who decides what?

Step 1: Who owns the process, and what is it for?

Write down the process in plain language, one page at most, and name its owner. The owner is a person with authority over the outcome and the budget, not the person who happens to build the workflow. Add the trigger (what starts it), the output (what it produces) and the systems it touches.

Why first? Because every later question, such as who approves and how long records are kept, needs someone who can answer it. A workflow with no owner will stall in review or, worse, pass review because nobody asked.

Step 2: Which decisions are in it, and who may take each one?

List every point where something consequential is decided. For a refund process that might be: is the claim valid, is the amount within policy, does it need a second look. Next to each decision, write the roles allowed to take it. Keep the list of roles short and use job titles from your own organisation chart.

Be strict about the difference between a step the AI performs and a decision a person owns. An agent can gather, compare and draft. The decision belongs to a human when it affects money, access, a customer or a regulated record. Where that line sits is a judgement for you and your compliance team, not a setting in the software.

Step 3: What approval thresholds apply?

Agree with the process owner when a decision goes to a person and when a second person is needed. Thresholds belong to the owner, so set them together and record them with a date and a name. We deliberately give no numbers here. A figure borrowed from a blog post will not survive its first audit, and one that suits a bank will be wrong for a small shop.

Record the threshold in the workflow description as well as in the policy, so a reviewer looking at the workflow alone can see why a gate exists.

How do you build the gates?

Step 4: How do you build it with a human input step at each decision?

Now build. In Studio, a workflow can include a human input step: it pauses the run, is addressed to an assignee, carries a timeout, and offers approve and reject branches. A decision is consumed once, so an approval given to one gate cannot quietly approve a later one. Put one such step at each decision from step 2. See Studio for the builder.

Three build choices matter for the audit.

• Wire the reject branch deliberately. A denial cancels the run unless the graph has a deny branch. Choose which you want and make it visible.
• Choose what the approver sees. The gate should show the action and the data behind it, so that "what did they see" has an answer.
• Decide the timeout outcome. An expired gate must deny or park the run. It must never approve.

Policy enforcement is live only for runs with a policy attached, so attach one and confirm it. The reasoning is covered in why AI governance must run at runtime.

Step 5: Where separation of duties matters, who are the two approvers?

For decisions where one person should not be able to act alone, name two different approvers and chain two gates. This is a common expectation for payments, access grants and policy exceptions.

Here is the honest part. The platform does not enforce today that the approver differs from the requester, and it has no approver role model. Separation is something you build in by addressing the second gate to a person who is neither the requester nor the first approver, and then check by reading the ledger. It is designed for, not built. Say so in your process document, so a reviewer knows the control is procedural and where the evidence lives.

What evidence do you keep, and for how long?

Step 6: What evidence should each step capture?

Decide what record each step must leave: who acted, what they saw, what they decided, the time, and what happened next. The platform's run ledger is an append-only list of events per run, covering policy decisions, approvals and gates, where each event is hashed together with the previous one. A read call returns the events and a verify call checks the chain, so edits to individual events become detectable.

Two limits to plan around. The ledger is readable as JSON, but there is no dedicated export for an auditor yet, so decide how you will extract and store a sample. And an opt-in seal of the chain head exists to catch wholesale replacement, so ask whether it is enabled in your deployment. More on reading these records in AI observability for agents and workflows.

Step 7: How long do you keep the records?

Settle retention with your records and legal teams, per record type, and write it down. The platform has no retention policy object today: the period is yours to set and enforce. A library for removing ledger payloads while keeping the chain exists, but it is not exposed as a switch, so do not promise erasure on request until you have tested how it would work in your set-up. Retention for approval records, personal data in them, and any legal hold are separate questions and often have different answers.

How do you prove the gates hold?

Step 8: How do you test it, including trying to break it?

Test as an attacker would, and keep the results. A workflow that works on the happy path has proved little. Run these as negative controls, which means each should fail in the way you expect, and a pass here means a hole.

1. Try to skip the gate. Attempt to reach the output without a decision. The run should wait or stop.
2. Let a gate expire. Leave it unanswered. Confirm the outcome is deny or park, and that nothing downstream ran.
3. Reject it. Confirm the reject branch does what the design says, including cancellation if no branch is wired.
4. Answer twice. Two people decide the same request. Only the first should count.
5. Try approving as the requester. Do not assume the platform will refuse. As far as we know it does not check today, so this test shows whether your assignment of gates holds up. If the requester can answer, your design is wrong, or your process needs a compensating check.
6. Run the verify call, then keep the output with the sample.

Write each result into a short test record with a date and a name. That record is itself evidence.

Step 9: How cautiously should the first run go?

Run first at L1 Assist or L2 Approve: the agent recommends or drafts, and a human approves before anything happens. For this method, that means a human input step at every decision and no autonomous path. Move up only when the ledger shows the evidence you set as criteria. A caution: the autonomy levels are a way of describing and planning rollout. They are not a field the platform stores and enforces today, so you hold the level in your own records. The plan in controlled autonomy: a practical rollout goes through promotion criteria in detail, and the platform view is at controlled autonomy.

Who signs it off?

Step 10: What does the final review and sign-off look like?

Review the ledger for the first runs with the process owner and your compliance contact. Check the six questions an auditor would ask: who approved, were they allowed, what did they see, when, what happened next, was the record intact. Fix what is missing, then ask compliance to sign off the workflow, the thresholds, the retention decision and the test record. Sign-off is a human act that belongs to your organisation. It supports evidence for what you must show to regulators and auditors, and it does not make the workflow lawful by itself. The exact posture depends on your use case, jurisdiction, deployment and configuration, and this is not legal advice. For an evidence structure see building an AI Act evidence pack.

Is there a template for this?

Not for these processes. No template ships today for procurement approval, access review, change approval, vendor onboarding, DPIA intake, incident response, KYC review, policy attestation, customer refund approval or release approval. The compliance workflow templates page shows the planned shape of each, labelled as planned. The nearest shipped examples are solution templates built as workflows with human-accountable gates, such as legal contract review with conflicts clearance and senior counsel sign-off, and insurance claims intake with tiered sign-off. They are good places to study gate placement, not drop-in replacements.

What is built, and what is design intent?

Built in the product: human input steps with assignee and timeout, gates that never auto-approve, deny branches, policy enforcement on runs with a policy attached, and a hash-chained run ledger with a verify call. Designed for: approver separation enforced by the platform, approver roles and delegation, a retention policy object, autonomy levels as a stored setting, and templates for the processes above. In use at Swfte: owner-decided steps with the decision written down. A worked example of one of these workflows from Swfte's own operations is not published yet.