Workflows in documents

Turn a procedure document into running processes — the builder reads your prose and separates it into the processes it describes, each with its own on/off switch.

Workflows in documents

A workflow is not a separate thing you build beside your procedure — it is built from what your procedure says. You write the process as you always have, in plain sentences; the builder reads that text and separates it into the processes it describes — one for every sentence that says when something happens. The document stays pure prose — nothing is inserted into your sentences — and the processes live in the Workflow panel, where you review them, accept them, and watch them run. An accepted process is on; its own switch is the one thing that turns it off.

One document, many processes

A procedure rarely describes one process. A procedure-management procedure might say what happens when a new procedure is created, how the catalogue is reviewed every six months, and who approves a procedure submitted for review — three processes that apply at different times. The builder keeps them apart by a simple rule: every sentence that states a start is its own process. A cadence ("every six months"), a record event ("when a procedure is submitted for review", "when a document is archived"), a change in a connected source, or "on demand" — each seeds one process. Sentences that only say what to do ("record the outcome", "if the review finds a gap, raise a risk") join the process whose start governs them; when it is not clear which one, the builder asks rather than guessing.

Each process has a name, taken from the sentence it starts on, and its own:

switch — on or off, and nothing else gates it. There is no publish step and no approval ceremony built into the product; if your own document-control procedure calls for an approval, write it, build it, and it becomes a process like any other. The switch sits on the process's row; while the change is being saved the row reads Switching…, and only then does it show the saved state — the words never run ahead of what the switch actually holds. A process that still needs something from the text — a bracket a template left for you, a question the builder could not answer from your sentences — says so on its row: Needs 2 answers. Its switch is greyed, and stays greyed until the document names what it needs; opening the process lists each answer in plain words with one door, In the text, which takes you to the sentence where it is written. You write the answer in the document, never in the panel, and the save that names it rebuilds the process from your sentence.
start, steps, and runs — a process opens in place, one at a time.
receipts — every run says which process ran, from which version of the document, and keeps that record even after the document is gone.

Not every sentence becomes a process, and that is the builder working correctly rather than missing something: a duty that is simply part of a role's day-to-day work, a definition, a line of background — none of them states a moment to run at, so none of them can start anything.

A build usually takes under a minute: the builder reads the whole document, and a long one takes longer. You watch it happen rather than wait in the dark — the panel counts the seconds until the first process is read, then shows each one as it arrives. A document too long for one reading is refused with that reason rather than a retry prompt — split it into shorter procedures and build each; retrying the same text would only fail the same way.

The clearest procedure ends with one short section that says how it runs — its review cadence, what each review verifies, and what happens when a gap is found (the marketplace's documents close with exactly such a "How this … runs" section). That is the builder's best input: if the workflow the builder proposes looks complicated, the fix is the text — state the loop plainly in one place and build again.

Processes that arrive with a template

A process does not have to be built. A marketplace procedure template can ship with its processes already written — the same shape, the same switches — and adopting the template installs them with your copy, bound to whatever its brackets already say. The document's activity records that the template installed them, and which answers (if any) a process still needs from the text before it can be switched on. From then on they are ordinary processes: switch them, run them, read their receipts, or rebuild the workflow from the prose and replace them. See Templates and the marketplace.

Your processes follow your text

You never have to keep the processes in step with the procedure by hand. Saving the document updates its processes and its agent. When your edits settle — you pause for half a minute, or leave the document — Alchex saves a checkpoint and re-reads what the text now says:

The agent reads the new text at once. There is no publish step and no "sync": the chat agent and every run read the current text, and the document's searchable index is refreshed from the same save.
A process follows its paragraph. A process is anchored to the sentence it was built from, and the paragraph around that sentence is the unit Alchex watches. After a save each process is sorted:
- nothing in its paragraph changed (a fixed comma, a capital letter, a changed full stop count as nothing) → the process carries on untouched;
- anything in its paragraph changed — the sentence itself ("every 6 months" became "every 12 months"), a sentence added beside it that names the approver it was missing, a bracket filled in, a sentence removed → the builder reads the whole paragraph again and the process is rebuilt from it: the same process, its steps now matching the text, whatever it still needs listed as before. It keeps its switch only when its own sentence is unchanged and the paragraph gives it everything it needs; otherwise it comes back off, for you to switch on. Nothing runs on a reading you have not switched on;
- its paragraph was deleted → the process is retired: its definition goes, every run and receipt is kept, and any decision one of its runs was waiting on is closed as superseded, with a note to the person who was asked;
- a new paragraph that states a start ("every quarter…", "when a supplier is onboarded…") → a new process is built from that paragraph and arrives switched off, like any process the builder proposes.
Only the changed paragraphs go to the builder, never the document — that is the one step that spends from your AI allowance, a few cents per paragraph, and only on saves that touch a paragraph a process lives in. Until the builder has answered, the process you had stays exactly as it was, so a save can never leave you with nothing.
The panel follows the save. When the re-read comes back, the Workflow panel updates on its own: a process that read Needs 1 answer turns into its built state the moment your text gives the answer, with no reload.
Leaving a paragraph is finishing it. You do not have to wait out the pause: the moment you start writing in a different paragraph, the one you just left is read. The pause only ever covers the paragraph still under your cursor.
Runs already in flight finish on the text they started with. A save never changes a run half-way through; the next run reads the new text. A run that was waiting on a decision for a sentence that has since changed is closed as superseded, and the person asked is told.
A process built before this rule catches up on its next save. It is read once from its paragraph, so a document written earlier shows what its processes still need the first time you save it again — no Build again.
Every outcome is written to the document's history — carried, rebuilt, retired, born — so "why did this process change" is always answered by the Activity feed.

When a save could not read a paragraph — the workspace's AI allowance is spent, the AI service could not be reached, or the document is too long to read in one pass — the panel says so once, above the list: what went wrong, why, and a Try again button. It does not quote your text back at you; your document is on screen, and each process that is waiting says Your text changed · reading it again on its own row instead of a start your document no longer supports. Those processes keep running on their last reading until then, so a save can never leave you with nothing, and both the notice and the row clear themselves once the reading lands.

Build again (on an open process) re-derives every process from the whole procedure at once, for when you have rewritten a section rather than a sentence and do not want to wait for the next save; the assistant does the same on request — turn this procedure into processes.

Building the workflow from your prose

You do not have to place steps by hand. Write the procedure the way you think — "reviewed every 12 months", "the leaver list is kept in our HR system; check every leaver's access is revoked", "if the review finds a gap, raise a risk" — and press Build from the text in the Workflow panel. The builder reads your prose and proposes the steps it describes, using only what your workspace actually has: the step kinds on this page, your connected sources, your record kinds' real fields, your team's roles. Reading a whole procedure is real work — a build usually takes under a minute, longer for a long document — so you watch it happen rather than wait in the dark: each process appears in the panel the moment the builder has composed it, greyed out, with the number of steps read so far. Those greyed rows are a progress report and nothing more — they have no switch and cannot be turned on, because the builder has not finished checking them against what your workspace can actually do. When it finishes, the checked processes replace them all at once.

A build does not ask you to accept it. What it read is stored straight away and listed in the panel — each process with its name, the sentence of your procedure it came from (Show scrolls the document to it), its start phrased the way the panel phrases it, and its steps. There is no plan to approve and nothing to tick.

Every one of them arrives switched off. Nothing the builder read can act until you turn it on, because the switch is the only lever there has ever been. A line above the list says what just happened — how many processes were read, and that they are off.

Where the procedure leaves something unsaid, the builder asks instead of guessing: no cadence stated, a system named that is not connected, a person it cannot identify. Each question rides the process it is about, as an answer that process still needs, in the builder's own words. Answer them the way you answer anything here — fix the prose, or connect the system, and save.

A process the builder could compose nothing of yet — every step it proposed needed a value your text does not give, such as a system named in a bracket nobody has filled in — is still listed, by name, with what it needs. Its row reads Needs 1 answer, its switch is greyed, and opening it shows the answer and its door into the text, with nothing to unfold or run. It is never dropped and never printed above the list: the list is the whole picture, and the missing parts are the way to complete it.

Your text is untouched: the processes are kept with the document, not written into it. Building spends from your workspace's AI allowance; storing what it read is free.

When a sentence is too unclear to build from

The builder only composes what your text actually says. Where a sentence stops it — because it does not say enough, or because it says two things — it does not guess, and it does not rewrite the sentence for you. It tells you, on the process, that the sentence is one of the answers the process still needs.

Two shapes of the same problem:

It does not say enough. "This is reviewed periodically" states no cadence, so nothing can be put on a schedule; an approver left as a template placeholder cannot be asked to approve.
It says two things. One section says every six months, another says annually. The builder had to pick a reading to make the process at all, and it tells you which sentence made it choose.

Either way it reads exactly like a blank: the row says Needs 1 answer, the switch is greyed, and the open process names the problem in plain words with one door, In the text, which takes you to the sentence. You fix the wording in your document — the panel has no field for it — and save; the process is rebuilt from your sentence and its switch comes back.

The builder never proposes a new process, and never adds a step, from a wording problem or anything else. Processes come from your text and only from your text.

Where a gap has no sentence to fix — a choice only you can make, a system nobody has connected — the same rule applies. The question becomes an answer the process still needs: its row reads Needs 1 answer, the open process names it in plain words, and In the text takes you to the sentence to write it in. That holds even when the gap stopped the builder composing any step at all: the process is listed with no steps and its answers, and is built the moment your text gives them. There is no separate inbox and nothing to review in bulk; the list is the whole picture.

The step kinds

Steps reach a workflow one way: the builder proposes them from your prose — Build from the text on a document with no processes, and the save itself from then on — and you accept. (Hand-placing steps in the text — chips from the / palette, and later the panel's Add the first step button — is retired: the document is prose, and the workflow is kept beside it. A document that still carries chips from that era keeps running on them, and its next accepted build replaces them with the stored workflow and clears them from the text.) These are the step kinds the builder composes from, on every governance document, a control's own procedure included:

When a record… — a trigger. The workflow starts when a record of the kind you choose is created, submitted for review, or — for documents — archived. The archived start is how a document-control procedure follows "obsolete versions are withdrawn": archiving any other document runs it, with the archived document as the record the run is about. Archiving the procedure itself runs nothing on it, and restoring a document is not a start. For documents you can narrow it to a single document type — chosen from the same list of types your documents already use, or left as Any document type — so one procedure can govern every record of that type.
Ask for approval — a person decides here. The run files a request in that person's My Approvals and waits; only a person can decide it, never the system.
Set a field — updates one field on the record the run is about, exactly as if a person edited it (the record's own history shows the change). The field is picked from the record's own fields, never typed from memory.
Create a risk — opens a risk in your register: numbered like any other, with its own history, and linked back to this procedure so the register says where it came from. You can have it act always, or only when a check finds a gap — a minor or major non-conformity from a Check a requirement step earlier in the run. A check that could not tell (needs evidence, cannot assess) never opens a risk. A dry run creates nothing.
Read a connected source — fetches the current records behind one of your connected sources (picked from your connections, then the source — never typed) and attaches them to the run, so every Check a requirement after this step judges them too. This is how "we keep the data in another system — observe it, check it" becomes a procedure: read fetches, check judges, and the run's receipt records exactly what was read (the source and a fingerprint of its content). Reading changes nothing in the connected system. If the source cannot be fetched when the run reaches it, the run fails and says so — a check never quietly judges less than the procedure promised. A run reads at most eight sources.
Notify someone — an inbox notice to the record's owner, a team role, or a specific person. Like Create a risk, it can be set to act only when a check finds a gap.
Send a Slack message — post into a channel of your connected Slack: pick the connection, find the channel by its real name, write the message (it can carry fields from earlier steps, like a notice can). This step writes into your Slack, so it holds itself to three rules: it runs only over a connection you have granted write access — a read-only connection makes the run refuse with the reason, never send quietly; a dry test run never sends — its receipt shows what would go; and a real send's receipt records the message's own id, so what left is on the record forever (a sent message cannot be unsent — to put a person between the run and the send, place an Ask for approval step before it).
Only if… — the run continues past this point only when a field of the record matches the value you set. The field is picked from the record's own fields, like Set a field.
If it was approved / if it was rejected — the fork after an Ask for approval step, driven by the decision the person recorded. This is how "if it is rejected, notify the owner and raise a risk" is written: put the rejected steps behind the rejected fork and the normal path behind the approved one. Place it after the approval it reads. (A separate check-driven fork used to sit beside this one; it is no longer offered — route a check's outcome through the approval it feeds, and Create a risk / Notify someone still carry their own act-only-on-a-gap setting. Procedures that already use the old fork keep running unchanged.)
Classify — put the record the run is about into ONE of the categories you declare, in your own words. The answer is exactly one of your category names — or none, when the record genuinely fits nothing you declared; it is never invented. One real AI call, judged against the record plus anything Read a connected source fetched before it.
Read fields — pull the facts you declare off the record the run is about, as named fields: give an instruction and list the fields you want (each one text, a number, a date, or one of the values you allow), and the run's receipt records each field's value. A field the material does not answer is left empty and named on the receipt — it is never guessed. One real AI call, read from the record plus anything Read a connected source fetched before it. In the step editor this is the same AI box as Check a requirement and Classify — write the instruction, then choose what it should answer with.
If it was classified… — the fork after a Classify step: each category gets its own fork, and the steps behind it run only when the record was placed there. A record placed in no category follows no fork.

Two forks make two paths in one list: the steps after a fork belong to it until the next fork re-decides. A dry run evaluates the forks too, so its report shows exactly which path would run.

Run on demand — the workflow starts when a person presses Run now, with no record event involved. Use it for a procedure you want to run when you decide to, like checking a control. It has nothing to configure: anyone who can edit the procedure can run it.
Every… — the workflow runs itself on a cadence: every N days, weeks or months. This is the trigger review sentences are written in — "reviewed every 12 months" becomes one step. The first run lands one full period after you accept the step, and each later run one period after the last; the run judges the procedure document itself, exactly as a Run on demand run does, and leaves the same receipts. Re-accepting without changing the cadence keeps the clock; changing the cadence starts it fresh from that moment. Archiving the document stops it.
When a form adds a row… — the workflow starts when a row is added to one register you pick. An intake form's submissions land as rows on its register, so this is how "when someone submits the intake form" becomes a start — and any row landing on that register starts it, whichever door it came through.
When a source changes… — the workflow starts when one of your connected sources serves different content. The system re-checks the source every hour and starts the workflow only when the content actually changed — the first check after you accept just records what the source currently serves, so accepting never fires a run by itself. Checking reads the source the same way Read a connected source does and changes nothing in the connected system. If a check cannot reach the source it is reported and simply tried again the next hour.
Check a requirement — write one obligation in your own words and say which depth has to be proved: that it is documented (written down), implemented (actually done) or effective (working). When the run reaches it, the requirement is judged against the record the run is about and the verdict lands on the run's receipt. You can also say which clause the requirement answers for, and then the verdict updates where you stand on that clause — see A check that answers for a clause below.

Each step reads as a short phrase — "When a risk is created", "Ask the admin role to approve" — derived from its settings, so the panel stays readable.

One rule holds for every start: a workflow's own writes never start another workflow. A run that creates a risk or sets a field cannot set off a second run (or itself) — only what people do, the clock, and your watched sources start workflows, so two procedures can never chase each other in a loop.

A later step can use what an earlier step produced

The steps of a run are not islands: a step that writes text — a notice's message, a risk's name or description, the value an Update a field step sets — can carry fields from earlier steps and from the record the run is about. You never type these as syntax: the editor offers an Insert a field menu listing exactly what the steps above have declared — each value a Read fields step will read, a check's verdict, the category a Classify step chooses — plus the record's own fields.

Three rules keep this honest:

Checked when you save. A reference must point at an earlier step that really declares that field. Point it forward, at a removed step, or at a field that no longer exists, and the save refuses with the step named — never a silent blank. Reordering steps re-points your references for you.
Empty is empty. A field the material did not answer resolves to nothing — it is never guessed — and the step's receipt names which references came back empty.
The receipt shows what was actually said. A notice's receipt carries the resolved text, values filled in, so the run reads as evidence.

So "read the certificate's issuer and expiry, then tell the owner" becomes two steps: a Read fields step declaring issuer and expiry, and a notice whose message uses both — filled with what was really read, at the moment it ran.

Changing the workflow

The workflow is changed the way it was made: change the text. State the new cadence, the new approver, the extra check in the procedure's own sentences: when the document saves, a new start paragraph is built and a changed paragraph has its processes rebuilt from it, so the steps always say what the text says. A process whose own sentence did not change keeps its switch as you left it; one whose sentence changed comes back off; a new one lands off; runs already in flight finish on the steps they started with. There is nothing to configure outside your prose, and the same guardrails hold either way: a step may only name a field its record actually has (accepting a plan that does not is refused, naming the step and the fields it may use), and only a connected source your workspace really holds. (A register record's columns are your own, so there the field stays free text and a wrong name is reported by the run.)

Accepting is what puts the processes into service. From the next matching event on, the steps you accepted are the steps that run.

Running a process yourself

A process whose start is Run on demand gets a Run now button in its open card in the Workflow panel. Pressing it runs that process's steps straight away and the result appears under the card's recent runs and in Runs, with the same receipts every other run leaves.

Three things it will refuse, and say so:

The process has no Run on demand start. Add one and accept the build.
The process is switched off. Switch it on.
The document is archived, or has no steps to run.

When it runs, the procedure document is its own subject — a Check a requirement step in it judges the document itself. That is what makes a control procedure able to check its own control.

When a process keeps failing, the document proposes its own fix

A live document does not only act — it notices when reality has drifted from what it says, and proposes the amendment itself. Three things start this:

A process fails repeatedly. Three runs in a row that end in failed (the count is a workspace setting; three is the default — one failure is never enough, because a single transient fault is not a fact about your text).
A check flips to a gap. A Check a requirement step that answered met on the previous run and a non-conformity on the latest one.
A cited source changes. A When a source changes start fires because the content of the source your sentence relies on moved on.

Each of these names the sentence the process was built from and the evidence — the run ids and their reasons, the two verdicts, the source change — and the assistant is asked one narrow question: what is the smallest edit to that sentence, or is the text not what is wrong? It answers one of two ways, and both are honest:

A proposed amendment. The rewritten sentence appears as a held-back proposal in the document's Proposals panel, pinned to the sentence, with the evidence in its note and Apply / Discard beside it. Nothing is applied on its own — the document never edits itself; a person decides, exactly as for any other proposal the assistant makes.
No edit, with a reason. When the evidence is about the machinery rather than the words — a connection that expired, a credential, a field the record does not carry, a provider outage — rewriting the procedure would be the wrong fix, and the loop says so instead of inventing prose.

Either way the act is recorded on the document's history, with the evidence, so an auditor can see what the document noticed and what it did about it. The loop runs unattended (with the rest of the prepared work the assistant delivers overnight) and is capped at one amendment per document per day, so a process failing every hour cannot turn the panel into a feed. It also runs on demand: a workspace member who may propose changes to the document can ask for it straight away, which is the door the live playtest drives.

A process that keeps failing has paused itself, and someone is told. When a process's latest runs have all failed (three in a row, by default), or it failed on a connection that is itself broken, the process is marked Needs attention. That is a state, not a guess: the run that tipped it writes it onto the process together with its own receipt, so the panel and the notice can never disagree about it. Its row reads Needs attention with a red dot, and opening it shows what happened in the run's own words.

The document's owner — or, when the document has no owner record, the team's owners — receive one notice naming the process and the reason. One notice per condition, not one per run: the same broken connection does not page anyone twice, and a streak that grows longer does not page anyone again.

A single failed run never sets it — that is a receipt in the run history, not a state. The process is not switched off for you, either: the switch is yours. A run that succeeds clears the state, and so does flipping the switch in either direction — you have seen it — and the document's activity records that the flip cleared it.

The switch is the only lever — archiving is the document-level off

A document is active from the moment you create it. There is no draft state it has to leave and no publish step that switches it on: once you accept a process, it is on, and from the next matching event on its steps run. Accept a new build and the next run follows it; runs already in flight finish on the steps they started with, and their receipts say exactly which version they ran — the same plain-number label the document header shows (v3, never a dotted form), so a receipt and the history read alike.

Each process carries its own switch. Switch one off and its start is ignored from that moment — a schedule stops firing, a record event no longer starts it, Run now refuses — while the other processes of the same document carry on untouched. Its runs and receipts are kept, and its schedule keeps its place: switch it back on and it resumes where it left off. Every flip is recorded on the document's history with who did it, like any other change to the document.

Archiving the document is the one thing that stops all of its processes at once. Archive a procedure and it stops acting the same moment, with no window in which a retired document still fires; restore it and its processes resume on their next start.

Versions and approvals are still yours to use — a document carries a version number, and can carry an approval — but neither is a switch. They record what the procedure says and who agreed to it; they do not decide whether it runs.

Whether it can fire is never a guess. Every read of a document's workflow now carries its liveness — whether the engine actually holds trigger rows for it (armed), and for a scheduled workflow, when the next fire is due. A workflow on a cadence does nothing until its first period elapses; the next-fire time makes that silence a stated date instead of a mystery.

The Workflow panel

Every document has a Workflow button among its panel doors, whether or not it has processes yet. On a document with none, the panel says so — No processes yet — in three short parts: the title, one sentence saying to describe how the procedure runs in the text, and the way in, Build from the text, which reads your prose and stores the processes it describes, every one switched off. One line under the button says what to expect: nothing runs until you switch a process on; while a build runs, that it is reading your document and takes about a minute; once processes start arriving, that they appear as they are read. That is the only place a standing Build button exists: from then on, saving builds.

The panel is one list, and nothing else: one row per process, with its name, one line of status, and its switch. There are no tabs, no filters, no search box and no groups — the list is the whole picture.

The status line is the process's whole state in a few words. Every quarter · next 1 Dec or When a request is submitted · ran 12:37 for a process that is on; Every month · off for one that is not; Waiting on Quality Manager · 2h while a run of it waits on a decision; Needs 2 answers when the text has not yet given it everything it needs; Needs attention when its recent runs all failed.
The switch is on the row, and it is the only lever. It is greyed while the process needs answers, because the server refuses that flip until the document names them.
A row opens in place, one at a time. A process that needs answers lists each one in plain words with one door, In the text, which scrolls the document to the sentence where the answer is written — you write it there, save, and the process follows. Every open process says what it does as short numbered lines (a fork is a heading over the steps it governs, so a branching process never reads as a misleading flat list), then Run now where its start is on demand, when it last ran, and the door to its runs.
The footer carries the two numbers that matter — how many processes are running of how many, and how many answers the text still owes — and the one door to Runs.

Runs replaces the list while it is open (Processes brings the list back). It lists what actually happened across every process, newest first, grouped by day and filtered by process and outcome. Each row names its process, when it ran, and its outcome — completed, nothing to do, waiting on a decision, failed — with one line from its receipts. A run opens in place: how it started, the document version it ran from, every step's receipt (a Check a requirement step's carries its verdict in full), and the doors — the approval it waits on, the record it was about. The panel shows where runs are; deciding an approval stays in My Approvals.

A document whose workflow was accepted before processes existed shows it as one process, switched on, under the label This document's process; the next build separates it.

What a check actually looks at

A check reads the record the run is about — a document's published text (its draft, if it has never been published, and the receipt says which), a register row's cells, or the fields of a risk record — plus whatever the run's Read a connected source steps fetched before it. It does not search the rest of your workspace. That bound is deliberate: a check answers "does this record meet this requirement", and one that quietly reached further would answer a question you did not ask. A connected source is never a quiet reach — it is a visible step the procedure itself placed, and the run's receipts say what was read.

One more thing worth knowing about connected sources: they are always judged at their current content. A run that waited on an approval re-reads its sources when it resumes — and leaves a receipt saying it did — rather than judging records fetched before the wait.

Its verdict is one of:

Met — the evidence shows the requirement is satisfied at the depth you asked for.
Minor or major non-conformity — it is not, and why.
Observation — a weakness worth recording that is not yet a non-conformity.
Needs evidence — there was nothing readable to judge. This is an honest "I could not tell", never a quiet fail: a check that found nothing says so instead of accusing the record.
Cannot assess — the check could not run (the AI service was unreachable, or the workspace has no AI allowance left), or it produced a finding that cannot be followed. Again, not a fail.

A finding has to point at something you can open. When a check quotes its evidence, every quote is matched against the material the check was actually given. A quote that matches nothing there is dropped; if a check's quotes were all unmatched, the verdict itself becomes cannot assess rather than standing as a result you could not check. This is deliberately never turned into a fail — a finding nobody can trace is not proof that anything is wrong, only that this run cannot be relied on. Re-run the check, or attach the material it expected. A check that quoted nothing at all is left exactly as it came back.

A check records; it does not act on its own. The verdict goes on the run receipt — it does not change the record, open a risk, or stop the run. Steps after a check run exactly as they would have. When you want a gap to do something, that is its own step, placed after the check: a Create a risk or Notify someone set to act only when a check finds a gap. The acting is always a step you can see in the sentence, never a side effect of judging.

The two things a verdict does reach are described below.

A check that answers for a clause

A requirement is written in your own words, so nothing about it says which part of a standard it satisfies. When it does answer for one, say so: the check's editor offers your standards and then that standard's clauses, as two lists to pick from.

Naming a clause changes one thing. As well as landing on the receipt, the verdict is recorded as where you stand on that clause — so the clause shows as conforming, as a gap, or as needing evidence on your compliance page, and your readiness moves with it. That is how a document you wrote counts towards a standard without anyone auditing it separately: the procedure that governs the document checks its clauses, and the number knows.

The whole finding is kept, not just the verdict. What the check said — its reasons in its own words, the requirement sentence it judged, how deeply it looked, anything it quoted, and which material it read — is stored beside the verdict and shown on the clause's row, with a link back to this run. So a row never says only that something is missing: it says what the check looked for and what it found instead. The verdict is still what your readiness counts; the finding is what tells you where to start.

Naming a clause is optional and leaving it unset is the ordinary case — a control's procedure grading its own obligations usually has no clause to name, and its checks simply leave receipts as before.

Three things bound it:

The three verdicts that are not a pass are recorded honestly. A minor or major non-conformity, and an observation, all record the clause as a gap — a clause with a live weakness is never shown as passed, whichever surface found it. Needs evidence records that the clause still needs proof, which is not the same as never having been looked at.
A check that could not run records nothing. If the AI service was unreachable or your workspace has no AI allowance left, the clause keeps whatever it last knew. An outage never lowers your compliance number.
The most recent check wins. One clause holds one answer — the last run to check it is what your compliance page shows, along with the document it read and when. The finding is replaced with the verdict it belongs to, so a row can never show one check's result explained by an older check's words.
A finding that fails must quote what it read. When a check decides a requirement is not met, it has to name the sentence it relied on and say what is missing in the requirement's own words. If it quotes something that is not actually in the evidence, the answer is recorded as cannot assess rather than as a failure — a specific accusation nobody can trace is worse than an honest "I could not tell".
Two checks that disagree make the answer uncertain. A failing verdict is checked a second time. If the two readings differ, the clause is recorded as uncertain, both readings are kept, and it asks a person to settle it rather than picking a side. Only failing verdicts are checked twice: it is the answer that accuses somebody, and re-asking every check would spend your allowance many times over for answers that already agreed.
What you have accepted before is taken into account. If someone on your team accepted a passage for a clause (this is fine — remember it), later checks of that clause are shown it, as a guide to the standard of evidence your organization was satisfied by. It is not treated as evidence for the new check: the documents in front of it still have to say what the requirement asks for. Accepted passages never leave your workspace.

The other thing a verdict reaches is described below, and only from a run you started yourself.

Two limits worth knowing: every check spends from your workspace's AI allowance, and one run evaluates at most sixteen checks — beyond that the receipt says the step was not judged rather than silently skipping it.

Running a control's own procedure

If the procedure you run is a control's document, the run also files an audit report against that control, made from its check verdicts.

The report is a draft, recorded on the control's record — the Workflow panel says so as soon as the run finishes, and the run's own receipts in Runs carry a finding per check step: its verdict, why, and the evidence it was read from. Every AI step's receipt also keeps its machine record — the verdict a check reached, the category a Classify step chose, each value a Read fields step answered (an unanswered field shows as empty, never guessed), and the model and token count of the call — so a run is evidence you can re-read, not just a status word. Nothing a workflow run decides is published on its own — a check that names a clause updates that clause's standing, and everything else is a record, not a status change.

Three things bound this, and they are worth knowing:

Only a run you started files a report. A workflow triggered by a record event never does — it fires once per matching record, so it would file a fresh report every time anything passed through the procedure.
Only a control's own procedure files one. Running any other document's workflow files nothing, which is the ordinary case and not an error.
If the report cannot be written, the run is unaffected — its receipts are already saved. You lose the report, never the run.

From the chat

Everything the Workflow panel does, the assistant can do in conversation, on your word. Ask what does this procedure run? and it lists the processes with their starts and switches; ask did the catalogue review actually run this year? and it answers from the runs' receipts. A process that starts on demand can be run by asking, once you confirm; a process can be switched off or on by asking; and turn this procedure into processes builds them and switches them on, each anchored to the sentence it came from. When you describe a new obligation instead — remind owners every quarter — the assistant adds the sentence to the procedure and builds its process in the same reply, so a process never exists without the wording behind it. How the assistant decides when to offer a procedure, and why it never acts before you say so, is on AI review and assistance.

Where you see it

A record whose kind or type a workflow listens to shows a Workflow row in its details, naming the governing procedure — derived automatically; there is nothing to configure.
Approval steps appear in the decider's My Approvals, like any other review — with a line naming the procedure that is stalled on the decision, because deciding is also what resumes the run.
Notifications land in the inbox, named after the procedure that sent them.
Every run, across every procedure, appears in the compliance record's Activity tab — runs that are waiting on a person and runs that did not finish are pinned above the feed, and any run opens into its receipts. The document's own Runs tab shows the same receipts for that one procedure, each AI call recorded as a suggestion with its token cost. Detail in The compliance record.
Every run is a line of your team's Activity — open the team from the sidebar: the process on the document, what it did, when, newest first, the document linked. That feed is the team's run history; see Teams.
A run's receipt is kept forever, even if the procedure is later deleted outright: the receipt keeps the procedure's code, name and version and stays readable in the activity feed. Archiving keeps everything anyway; a permanent delete removes the document, never its evidence.