Standards knowledge

The assistant answers from a knowledge base that ships with it, and that knowledge base holds three kinds of thing about your standards, plus a library of how businesses actually run each process. Keeping them apart is what stops a recommendation being sold to you as a requirement, and a requirement being waved away as a suggestion.

The kinds of knowledge

• Requirements are what your framework demands. When the assistant tells you something must be done, it is reading the framework's own clause and the auditable statements under it.

• Guidance is how organisations meet a requirement well. Every framework in your catalog can have implementation guides beneath it; the assistant reads those sections, names the guide and section when it recommends something, and always frames it as recommended practice. Guidance never becomes a requirement — not in the advice itself, and not in the summary that introduces it. Where a guide describes something as obligatory, it is quoting the framework or the law, and says so.

• Obligations are what the law requires, article by article, in the jurisdictions it applies to. The assistant maps each article to the clauses in your framework that answer it, tells you which jurisdiction it belongs to before treating it as something you must do, and keeps deadlines exactly as the text states them.

• Methods are the ways a business actually runs a process — for internal audit, a risk-based programme, process-based audits, audits done remotely or in short sprints, and whether your own staff, one auditor or an outside firm does them. They are not filed under a standard. Each process keeps its own methods, researched from professional bodies and practitioners, and each method says which kind of company it suits, how it runs, who does what and how often, the effort, and where it usually fails. A method is never a requirement: the clause is what is required, the method is one way to meet it, and the assistant says so.

Ask about a clause and you get the requirement and the guidance that informs it. A clause does not tell you whether a law applies to you, so laws are not attached to it: ask about the law, and the assistant checks whether it applies to your organisation and what it requires. Ask for a guide section or a regulation article by name and you get that directly, labelled for what it is.

Asking without a clause number

You do not need to know where in your framework something lives. Ask the way you would ask a colleague — "do we have to keep a record of who enters the server room?" — and the assistant searches the whole knowledge base by your words, across requirements, guidance and obligations at once. It brings back the passages that match, each labelled for what it is and carrying its citation, and then reads the leading requirement in full before it tells you whether something is required. A search result on its own is never the basis for a verdict; the clause it points to is.

That search runs over the knowledge base itself, the same text the assistant cites, so it is never behind it.

The same search now finds the document templates in your library's catalog. Ask for a document by whatever you call it, or by what it is for, and the assistant matches your words against each template's name, its other names, what it covers and the decisions it asks, then fetches the authored template by its code and builds from it exactly as before. Nothing about how a document is generated changes; only how the right template is found.

Where it shows up

• In chat, a recommendation cites its guide and section; an obligation cites its regulation and article; a method is named as a method. A requirement cites its clause: reading one hands the assistant the citation ready-made, so the clause travels with the answer rather than being reconstructed from memory — see When you ask whether something is required.
• When the assistant drafts or edits a document, requirements become "shall" sentences and guidance becomes "should" sentences, kept visibly distinct.
• Ask how to do something — run internal audits, assess risk, find a root cause — and the assistant answers like an experienced practitioner: it reads the ways that process is run, matches them to what it knows of your organisation, offers the ones that fit and recommends one. If nothing it holds fits, it says so rather than inventing a method.
• When several guide sections touch the same requirement, the one written about that requirement is quoted first, and sections that only mention it in passing are left out of the answer entirely. You get the section that answers your question, not everything in the guide that happens to name it.
• Ask what a framework requires and you are answered from the framework itself, never from a guide that happens to discuss it at length. A guide is written about a requirement, so it can say the framework's name more often than the requirement does; that never lets it stand in for the requirement.
• On the framework picker, the guides sit under the framework they serve, so you can see what the assistant is drawing on.
• Kits of templates carry the guidance and regulation articles they were written from, so the assistant can say why a set is the set.

How the knowledge grows

New guides and frameworks come in through a review, never at run time. You supply a source either as a public link or by adding the file to the private source folder kept beside the knowledge it becomes, named for the framework or guide and its edition year — the name is all the pipeline needs, and a guide of a framework it already knows needs nothing more than that (a guide that is also certified as an extension of its framework is read once, as a guide, and offered as a standard from that same reading). A listing of the folder says, for every file, what it will be read as, whether it has already become knowledge, or why it was refused — so what is still to be processed is never a guess. The source texts themselves never reach the assistant: the assistant is built without the folder, and a check fails any change that would let it read one. Only the rewritten knowledge reaches it. A copy is supplied as text, and a table of controls in it is read row by row, so a control arrives with its code, its title and its wording together; a section number is recognised however the copy writes it, with or without a full stop after it — and every run lists any section it could not find in that copy, together with where it looked, so nothing goes missing in silence. A source you supply is read and rewritten in the assistant's own words, section by section, with its provenance recorded; the result is reviewed before it reaches you, and an automatic check fails any page that carries more than 25 consecutive words of a source. A new copy of a framework the assistant already knows is fitted to the shape it already has — an annex printed without its prefix, or sub-clauses beneath a clause, land where the existing knowledge lives, and the framework's entry in your catalog is left exactly as it was — and a copy that yields only a fraction of the framework's sections is refused rather than silently replacing part of it. The assistant never copies a source text into the product.

Only a source's own numbered sections become knowledge. A published document usually carries matter that looks like sections but is not — a scope and terms section at the front, an annex at the back, and tables that map one edition's numbering onto an earlier one. When the guide already has a known list of sections, anything outside that list is skipped before it is read, so a numbering table is never rewritten as advice and a renumbered clause is never quoted back to you under the number it used to have. What was skipped is listed for the reviewer, so a section a new edition genuinely adds is visible rather than silently lost.

A document new to your catalog has no such list to check against, so the reading itself has to hold the line. Where a section turns out to carry no requirement at all — a cross-reference table, a contents list, a page of front matter — nothing is written for it. A requirement your framework does not impose is worse than a missing section, because you would act on it, so the rewriting never fills an empty section to satisfy a shape.

The rewritten text is checked automatically before anyone reads it — that guidance never states an obligation, that every section it claims to inform really exists, that provenance is recorded. When a check finds a problem, the page is corrected and checked again. Nothing reaches you until it passes those same checks and a person has read it.

If something you need is not in the knowledge base, the assistant says so rather than guessing, and the gap is recorded so the source can be added.

When you ask how to run a process the assistant holds no methods for, it says so plainly.