Compliance

Compliance in the sidebar opens one page that answers one question per requirement: is it proven, and by what? For owners and admins it is also where Alchex opens after you sign in, on its Overview; members, who do not see this page, open on Chat. The page does no checking of its own. Every status on it is the result of the newest check of that requirement: what the check found, the reason in one sentence, and what it read.

A check is a control running: a short instruction with a clock, set up on one of your documents. When it is due, a chat opens with that instruction, reads what the control names — the document, a register, a connected app — and records passed, failed or couldn't run for each requirement the control proves. Each document has a check that its text says what the standard asks, and, where an app or a register can show it is really done, a check of that. You set controls up by asking the assistant which ones to set up on a document.

You can also ask the assistant directly, in any chat whether you comply with one clause of a standard you work to, such as "Am I compliant with clause 7.5?" It reads what the clause requires and how each part of it is judged, reads your documents, registers and connected apps, shows you what it found, and records passed or failed for that requirement on this page, linked to the chat. A gap is recorded with what is missing. Members who can only read can ask, but the result is not recorded.

The chat is the proof

Each check's chat shows its own evidence. Before it records a result, the assistant writes in the chat what it read and shows it: the rows from the app or register, or the exact sentence from the document, quoted. Then it says what that shows. Reading the chat should be enough to see that the result is right. With the result it writes a short report for the requirement's page: the finding in one sentence, what it rests on, and what to do.

How much a result proves depends on what the chat actually read, not on what the assistant says:

• if it read a connected app or a register, a pass shows the rule is really done;
• if it read only documents, a pass shows the rule is written down, not that it is done yet (Written, not proven yet);
• if it read nothing, Alchex refuses the pass and the assistant is told to read the evidence first.

When a pass rests on a document, the assistant must quote the sentences that show it, and Alchex looks for each sentence in the documents the chat actually opened. A quote that is not there, word for word, is refused, and the assistant is told to copy the sentence exactly or record that the document does not say it. So when a chat says "the procedure says …", the procedure really says it.

Every requirement's page has See the check in its chat, which opens the chat that gave it its status.

The five states

When two checks of the same requirement disagree, the worse of their newest findings decides.

The page

Each standard you work to is a tab, with how many of its requirements are proven out of how many apply. Under the tab are two views.

Overview (where the page opens) answers "are we compliant?":

• The answer — a ring of proven, failing and waiting requirements, one sentence saying yes, not yet, or not known yet (fewer than half checked), and the latest sessions that checked the standard.
• Five numbers — requirements proven (and the change over four weeks), how much of that is proven by evidence from an app, register or record rather than by documents alone, sessions this week, requirements failing now (and how long the oldest has been open), and the median days a gap took to fix.
• Problems — what is failing or waiting for you, worst first, each with its latest results and since when it has been in that state.
• Twelve weeks — requirements proven, failing and waiting week by week (click a week to see the page as it stood then), and the gaps found and fixed each week.

Requirements is the full list:

• The headline — how many requirements are proven, and how many gaps were found this week and how many were closed.
• Requirements — one list, with a filter for each view:
  • Needs attention (where the list opens) — the gaps first, then what needs you;
  • one filter per state, with its count — only the requirements in that state, newest first;
  • All — every requirement once, in the standard's own order.

Every requirement opens its own page.

A requirement's page

A requirement's page is the report of its newest check:

• its code, name and state, when it was checked, and See the check in its chat;
• the report the check wrote: what it found in one sentence, what that rests on (the document and section it quotes, the register row or app fact), and what to do when something is open. A check made before reports existed shows its one-line reason instead. Under it, what the check read, each document a link;
• Earlier checks — every other check of the requirement, newest first, with its date, state and one line. Open one to read its own report and its chat.

Your standards

A workspace that has added no standard opens on Add a standard; afterwards the same button sits beside Showing and lists every standard your plan includes that you have not added yet. Each standard shows its own requirements: a requirement of one standard is never proven by a check of another.

Looking back

Pick a date under Showing to see the page as it stood at the end of that day, rebuilt from the checks and decisions recorded by then.

When checks run

The page runs nothing itself. Each control runs on its own clock and its result appears here when it finishes.

Adding a standard sets up the checks it requires: each process's document check, on that process's document, and each evidence check whose app is connected or whose register you keep. A process with no document yet gets its checks when its document is written. Every other control in the library is yours to choose: add it on the Controls page, choosing the document it runs on, or ask the assistant which ones fit a document and it sets up the ones you pick. A check of your own — a name and what to check, in your words — is added on the same page. See Workflows.

See the check in its chat on any earlier check opens that check's chat.

When a requirement does not apply

On a requirement's page, choose Doesn't apply to us: you are asked why, and the reason becomes its line in your Statement of Applicability, with who decided and when. The requirement then reads Not applicable and leaves the count. Management-system clauses get a note first, because auditors rarely accept excluding them. Applies takes the decision back.