Workflows in documents and registers

A document and a register each have an agent — ask it something on a schedule, and every run is a session you can open and reply to.

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") 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 document the assistant creates arrives with no processes switched on. It is written from its process, so each section already reads as the process it describes; build them from the Workflow panel when you want them to run, exactly as for any other document. See Documents the assistant writes.

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. Your schedules are untouched by a save — what you asked, and when, is yours, not something re-read out of the words on the page.
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 save. Saving is what reads it: there is no Build button anywhere, because the text is the only statement of what runs. Your prose is read into the processes it describes: when each one starts, and which requirements it checks (What a process is made of, below). Reading a whole procedure is real work — it usually takes under a minute, longer for a long document — and the panel lists what it read when it is done. Every process it finds arrives switched off.

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 and the sentence of your procedure it came from. 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 its start unsaid, the builder asks instead of guessing: no cadence stated, no word on when the process runs. Each question rides the process it is about, as an answer that process still needs, in the builder's own words. Answer it the way you answer anything here — fix the prose and save.

A process the builder could place no start for yet 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.
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, 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, such as which document type a start is about — 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. There is no separate inbox and nothing to review in bulk; the list is the whole picture.

What a process is made of

A process is two things read from your text, and nothing else:

When it starts. A cadence ("reviewed every 12 months") is a schedule start: the first run lands one full period after the sentence is read, each later run one period after the last, and archiving the document stops it. "When a record is created, submitted for review or archived" is a record start — for documents you can narrow it to one document type, and archiving any other document is what runs a document-control procedure, never archiving the procedure itself. "When a form adds a row to a register" starts on every row that lands there. A sentence that says the procedure runs on demand ("may be run at any time") gives it a start a person presses.
What it checks. Every obligation the text states for that process — "every entry has an owner", "access is reviewed quarterly" — is a check, quoted in your own words, with the depth that has to be proved: documented, implemented or effective. A check can name the clause it answers for, and then the session's finding updates where you stand on that clause — see A check that answers for a clause below. Every check in a library template already names its clause; when your text cites one ("A.5.15") it is picked up from the text.

Everything between the start and the checks — who approves, who is told, what is updated, what happens when a check finds a gap — is not stored as steps. It is your procedure, and the agent that runs the process reads it as written, at run time, with the same tools the assistant has (see What the agent can reach below). Change a sentence and the next run follows the new sentence; there is nothing to rebuild.

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

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 read into a process and a changed paragraph has its process re-read, so a process always says 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; sessions already running finish on the text they opened with. There is nothing to configure outside your prose.

Running a process yourself

A process whose start is Run on demand runs when a person asks it to. What that means in practice is a sentence in your document — "a person may run the check at any time" — and the request comes from wherever that person already is, not from a button on the panel. The panel shows what happened; it is not a console.

One request runs a process that starts on a schedule too: Check now on Compliance, which runs the processes that check a topic or a standard now instead of waiting for their next date, each as a session you can open in Chat. A session that runs a process's checks carries the library's guidance for the topics those checks cover, and opens with one line naming the process that started rather than the instructions the agent was handed. A process that starts when a record changes is never run this way, because it has no record to run about.

Three things a request will refuse, and say so:

The process has no Run on demand start (or, from Run checks, no schedule either).
The process is switched off. Switch it on.
The document is archived, or has nothing to run.

When it runs, the procedure document is its own subject — a step that judges a requirement judges the document itself. That is what lets a control be checked by a workflow on its own page.

When a process cannot continue

A run that cannot do what the procedure says does not fail quietly and does not rewrite your document. It asks, in its own session: the Agent panel shows the session with a line saying what it is waiting for, and you answer by replying there or by changing the sentence in the document — the next run follows the new text. Nothing proposes amendments on its own, and nothing pauses a process for you: the switch stays yours.

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, an on-demand request 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 Agent panel

Every document has an Agent button among its panel doors, and behind it every document is an agent. There is nothing to create, build or accept: the document is the agent's instructions, and the panel shows the agent's settings and what it has done.

A register has the same button, and it is the same panel. Open a register and the Agent door sits in its row of panel doors exactly where a document's does, with the same two tabs, the same rows and the same switches. What differs is only what the agent reads: on a document, the document; on a register, the register's own tables and rows. Everything this page says about schedules, sessions and Send now is true of both — there is one agent, and the record is what you point it at.

The panel has two tabs: Schedules, what this record is asked, and Sessions, what has happened.

Schedules — what you ask, and when

A schedule is one request about this record plus a clock. You write the request the way you would type it into chat, once, and on its date it is sent to the agent as the opening message of an ordinary session.

A record holds as many schedules as there are things to ask of it. A policy might have a weekly check of one thing and a half-yearly review of another; an exception register might be asked every Monday to flag the rows past their review date. Each is its own row, its own clock and its own sessions.

Add a schedule and you are asked three things:

What should the agent do? Your own words — "Check the retention periods in this policy against the records folder and tell me what is out of date." Nothing rewrites, shortens or interprets them: what you type is what the agent is sent. The record travels with the request as the thing the agent reads first, so you never have to restate what is already in it.
When. A cadence — every day, week, month, quarter, six months or year — or a record event, such as when a document is created, submitted or archived.
Permission. What the sessions this schedule opens may do on their own. Ask before it changes anything — the session reads, works the request out and reports back, and anything it would change it describes and waits for you. Do the work and tell me — it carries the request through and tells you what it did. Publishing, archiving and sending mail wait for you either way.

Each schedule is then one row: your message, the clock, and the last thing that happened, in a word. Its switch is on the right. Open the row and you land in the most recent session it opened.

A new schedule is saved off. Writing one describes what you want; turning it on is what lets it act unattended. Use Send now from the row's menu to see what it does first, then decide about the switch.

A schedule's sessions work the way a chat does. They carry the request out and report what they did; archiving a document, sending a version to a workspace that subscribes to yours, and sending a compliance reply still wait for a person, exactly as in chat. Between September 13th and 20th 2026 each schedule carried its own ask before it changes anything / do the work and tell me choice; that setting is retired along with the one in chat, because neither end of it was what anybody wanted. If you want a schedule that only looks and reports, write that — "tell me what is out of date" asks for a report; "fix the retention periods" asks for the work.

A scheduled session acts as the person who wrote the schedule. It holds your role and sees your teams, so where your request says to draft a register entry or update a record, it does exactly that — under your name, and refused exactly where you would be refused.

Sessions — what happened

Every session this record has opened, newest first, one line each: what it was, when it started, and where it got to — done, asking you something, waiting on an approval, or stopped. Open one and you are in the chat, where you can read every step and reply.

Who can see a session is the record's team. A session opened on a document appears to that document's team; one opened on a register, to the register's. Anyone who can see it can answer it, so a session that stops to ask something is not stuck behind one person.

An archived record's agent does nothing. Archive a document or a register and its schedules stop firing — they are not deleted, and turning the record back returns them. Delete a register outright and its schedules go with it; the sessions it already ran stay, because they are the record of what was done and deleting the request must not delete the answer.

What happened to the older agent switch

Documents used to carry one switch whose when was read out of your own prose — a sentence like "Every quarter, the Records Manager checks the retention of files" was treated as an instruction to the product. That row is gone.

A document's prose is a fact about the document, not an order to anybody, which is why nothing could say what the agent should actually DO when the date came round. You now write the request yourself, in your own words, and the clock only decides when to send it.

Nothing that was running stopped. A document whose switch was on kept its cadence exactly — the same day it was next due is still the day it is next due — and it now shows one schedule instead, with a plain request you can edit into your own words whenever you like.

A run you start acts as you. While it works it holds your role and sees your teams, so where the procedure says to create a risk, add a row to a register or update a document, it does exactly that — under your name, and refused exactly where you would be refused. A schedule's run now does the same, as the person who wrote it. If your role changes while a session of yours is waiting, the session picks up the change when it resumes; if you leave the workspace, it carries on reading and stops writing.

Two things it deliberately does not do:

It does not turn the agent on, and it does not need the agent to be on. Trying is not authorising. The switch's question is whether the agent may act unattended from now on, and pressing a button while you watch is not an answer to it — so the switch stays exactly where you left it.
It does not start a second session while one is already running. The row reads Running… until that session stops.

So the ordinary way to set an agent up is: write the sentence, check the schedule on the row, press Run now, read what it actually did — and then decide about the switch.

Sessions come next, newest first: the process's name, when it started, and one plain line of where it is. Working · checking it against section 3. Asking which system holds the retention schedule. Waiting on Quality Manager. Stopped · budget reached. Done · nothing to do. Nothing folds, and nothing is grouped or filtered — the list is the whole picture.

The footer carries the month's sessions, tokens and cost, and the one door to Billing, where your workspace's whole month lives.

Opening a session

Click a session and you are taken to Chat, with that session open — no popup. A run is a session and a session is a chat: the agent reads the procedure, does each step with the tools it has, and writes down what it did, in the same transcript your own chats use, with the rail of your other conversations beside it and the composer at the bottom.

You see the agent's opening words — including the sentence of your document it is following — a ticked line per finished step with how long it took, the tools it called and what came back, and, when it cannot continue, the question it is stuck on, asked in plain words. Files, registers and approvals it read or made appear as chips you can open. The conversation is about the document the agent followed, the same way a chat you start from a document is.

Sessions are the team's. A session belongs to the document, and the document belongs to a team, so every member of that team sees it — under Sessions in their own Chat rail, with the same one-line state the panel shows — and any of them can open it. Nobody outside the team sees it, and your own chats stay your own. A session cannot be pinned, renamed, archived or deleted: the document owns it.

You can answer it there. The composer at the bottom is an ordinary reply. You can also answer by naming the thing in the document and saving; a save resumes every session of that document that was waiting on the text.

Replying in a session

A session that has stopped on a question — its line reads Asking … — is waiting for exactly one thing: an answer. Type it in the session's composer and send. Your message lands in the transcript at once, and the agent resumes from it after the reply is on screen: it re-reads the procedure as it is now, takes your answer as the missing fact, and carries on with the next step. What it does appears in the same session as it happens, under your message.

Two things to know. Only someone on the document's team — or a workspace administrator — can answer a session, because the agent acts as that team (or, for a session someone started with Run now, as that person). And a session that is not asking (finished, stopped, or waiting on an approval in My Approvals) treats your message as a note in its transcript: nothing resumes, because nothing was waiting on you.

What the agent can reach

The agent has the same tools the assistant has in chat: your documents, registers and sheets, and — for reading — every system connected under Connections. A procedure that says check the open tickets in our tracker or find the retention schedule in the drive can be followed as written when that system is connected, and each read is a line in the session's ledger. A system the procedure names that is not connected ends the session asking, with the question in plain words, rather than guessing.

What it can change in a connected app. The same as the assistant in chat, under the same choice: a connection's tools start on Auto or Ask the way its app marks them, and you set any tool, or the whole connection, to Ask under Connections. A change on Ask waits for your yes in the session; one on Auto runs when the procedure asks for it, and every change is written to your workspace's history with the connection it went through.

Four more things a procedure keeps asking for, and the agent can now do:

Open a file by its link. A sentence that pastes a link to a file or page in a connected system is followed as written: the agent opens that file through the connection, live. A link to a system that is not connected is said so, never guessed at.
Read a public web page — a regulator's page, a vendor's status page, a published amendment list — as it is right now, so a session cites what is on the page today rather than what it remembers.
Find who holds a role. The agent can look up your workspace's members by name, email, role and team, so an ask or an approval can go to the person the procedure means rather than to everyone on the rung. Job titles are not a field in Alchex, so a phrase like the Quality Manager is resolved by name or team, or asked.
Come back later. Check again in two weeks schedules one more session on the same document, with a note for it. It runs only if the agent is switched on, and the session says so if it is not.

When the procedure needs a person's decision, the agent files it in My Approvals — the same door you already use — and the session waits. Deciding there resumes it. The panel shows where sessions are; it never asks you to decide anything.

A document whose workflow was accepted before processes existed shows it as one process under the label This document's process; the next reading 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. 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.

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 session's finding — it does not change the record, open a risk, or stop the run. When you want a gap to do something, write it in the procedure ("if the review finds a gap, raise a risk"): the agent reads that sentence and does it, and the act is a line in the session you can read, 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.

This holds however the procedure runs. When Alchex works through the steps itself, it is told which checks name a clause and records each verdict the same way, but only for a clause your steps actually name, so a run can never count towards a clause the procedure does not check.

Naming a clause is optional and leaving it unset is the ordinary case — a 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 is the clause's current answer, and no finding is ever lost. The last run to check a clause is what your compliance page shows today, along with the document it read and when, and its finding travels with its verdict, so a row can never show one check's result explained by an older check's words. Every finding is also kept, one per run, and never changed afterwards: when two documents check the same clause both findings are there, and so is every earlier run's.
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.

What a run keeps

A run's own session carries a finding per check: its verdict, why, and the evidence it was read from, with the model and token count of each 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.

Which account a run uses

A procedure runs as a person — whoever pressed Run now, or the person who wrote the schedule that woke it. That already decided what the run may write inside Alchex. It now also decides which account it uses to reach a connected app.

So when a step reaches a connected app, it does so with that person's own connection to the app if they have one.

Two consequences worth knowing before you rely on it:

A person who has not connected their own account stops rather than borrowing someone else's. The step fails and says so — the person this run acts as has not connected their own Slack account — and connecting theirs under Settings → Connections is the whole fix. It does not fall back to the account that set the connection up, because a message really would go out under that person's name.

The exception is a connector with no personal account to connect, such as one that signs in with a shared key. There is nothing for you to connect there, so those keep using the workspace's connection and nothing changes.

What this never does is widen reach. A step still refuses what the person running it may not do. Connecting your own account changes which account asks the app, not what you are allowed to ask for.

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

An approval a procedure asks for appears 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.
The document's own Workflow panel lists its runs as sessions, and opening one shows its whole transcript with what each step cost. A check that proves a requirement also puts its finding on Compliance, with a link back to the session.
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.