One platform, four parts
A form designer, a workflow designer, the engine that runs what they publish, and an assistant that proposes but never decides. Every product line is built from the same four parts.
The form, as a definition
Form Designer
Fields, sections and help text, with sections that show, hide or lock depending on the step the record is in.
The person who owns the process builds the form: fields grouped into sections, help text where people hesitate, and the policy header your records already carry on paper.
Each section has a gate tied to the workflow: hidden until a step is reached, editable in one lane, locked once a decision is made. The form changes as the record moves, without anyone writing code.
The printed record is the same definition, laid out for paper.
Request
editable in the Requester laneIndependent review
hidden until SubmittedApproval
locked after ApprovedThe steps, drawn and checked
Workflow Designer
States, transitions and lanes on a diagram your reviewers can read, with a lint panel that checks the definition while you draw it.
Name the states a record can be in and the moves between them. Give each move a lane, so it is clear who acts, and bind it to a capability where the process needs a guard.
The lint panel runs as you draw: unreachable states, dead ends, approvals with no approver, a step with no clock. What it accepts is exactly what the publish gate accepts, so author time and publish time never disagree.
Export the diagram as text and paste it into a procedure, a review or an audit response.
- Passed: Every state reachable from Draft
- Passed: Approved and Closed are terminal
- Passed: Approve is bound to the Approver lane
- Warning: Returned has no clock; the requester can wait forever
- Passed: Four-eyes: the approver is not the reviewer
The framework that runs it
Workflow Engine
A versioned, guarded, role-checked state machine with a full audit trail, running inside your own application, against your own database.
Every record carries its definition version, its current state and an append-only history of every move: who, when, in which lane, and why.
Guards are structural: four-eyes, not-the-prior-actor, a capability on an edge, a clock that escalates when nobody acts. They are part of the definition, not of the code around it.
There is no central workflow service to couple every write path to. The engine is a library each application embeds, so one team's outage is never another's.
| When | Lane | Moved to | By |
|---|---|---|---|
| Tue 8 Sep, 09:12 | Requester | Submitted | R. Osei |
| Tue 8 Sep, 14:40 | Reviewer | In review | M. Chen |
| Thu 10 Sep, 11:05 | Reviewer | ReturnedMissing drawing reference. | M. Chen |
| Thu 10 Sep, 16:22 | Requester | Submitted | R. Osei |
| Mon 14 Sep, 09:00 | System | EscalatedNo action for 5 business days; escalated to the unit head. | clock |
| Mon 14 Sep, 10:31 | Approver | ApprovedFour-eyes satisfied: the approver is not the reviewer. | A. Okafor |
AI that augments, and never decides
Assist
Assist proposes a classification, a routing, a follow-up or a draft. It shows its sources and how confident it is. A person decides.
A proposal is a first-class object in the record: what was suggested, on what evidence, with what confidence, and what the person did with it.
Approve, edit or reject. The decision and the proposal are kept side by side, so an auditor sees both the suggestion and the judgement.
No timer and no model ever approves, returns or declines on its own. The statutory floor of a process is never delegated to software.
Classify as a temporary modification with a restore-by date of 30 days, route to the Reviewer lane for independent review, and open a follow-up for the affected procedure.
- Based on
- the request text, the change type definition, and the last two records of this type.
- Confidence
- High
How it works
Three parts, in the order you would do them.
Step 1: Design the form
Choose the fields, group them into sections, and decide which sections show, hide or lock at each step. Add the help text people need and the policy header your records already carry.
Step 2: Draw the steps
Name the states a record can be in and the moves between them. Give each move a lane, so it is clear who acts, and guards such as four-eyes or not-the-prior-actor where the process needs them. Add a clock where the process has one.
Step 3: Publish, then run
A check reads the whole definition first and refuses unreachable steps, dead ends and approvals with no approver. Published versions never change. Records already in flight finish on the version they started.
What a published definition looks like
A published definition. Lanes down the side say who acts; steps across the top say where the record can be. One marker per step, and a check that runs before anything goes live.
| Lane | Draft | Submitted | In review | Approved | Implemented | Closed |
|---|---|---|---|---|---|---|
| Requester | Requester acts at Draft | Requester acts at Submitted | ||||
| Reviewer | Reviewer acts at In review | |||||
| Approver | Approver acts at Approved | |||||
| Implementer | Implementer acts at Implemented | |||||
| Closer | Closer acts at Closed |
Proposed by the system, decided by people
The engine can propose: a classification, a next step, a follow-up. Every proposal shows its sources and how confident it is.
A person approves, edits or rejects, and the record keeps both the proposal and the decision. No timer and no model ever approves anything on its own.
If it has a form, steps, a decider and a clock, it fits.
Proposed by the system, decided by people. Bring the form and the approval chain you have today; we will show it running.