Standards knowledge

The assistant answers from a knowledge base that ships with it, and that knowledge base holds three kinds of thing. Keeping them apart is what stops a recommendation being sold to you as a requirement, and a requirement being waved away as a suggestion.

Three 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 controls 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.

Ask about a clause and you get all three at once: the requirement, the guidance that informs it, and the regulation articles mapped to it. Ask for a guide section or a regulation article by name and you get that directly, labelled for what it is.

Where it shows up

• In chat, a recommendation cites its guide and section; an obligation cites its regulation and article.
• When the assistant drafts or edits a document, requirements become "shall" sentences and guidance becomes "should" sentences, kept visibly distinct.
• 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 placing it in the shared source folder your workspace was given, one subfolder per framework or guide; the read-only identity that serves that folder holds no other access. 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. Regulation texts from official publishers are checked every week: when the published text changes, only the changed articles are rewritten and reviewed. 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, a scan whose text did not survive — it is dropped and named for the reviewer, together with what it actually was. 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 is never allowed to fill an empty section to satisfy a shape. That cuts both ways: a section that is merely hard to read is still rewritten, with the unreadable points dropped and the result marked low-confidence for your review.

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 draft is kept and corrected rather than discarded, so one wrong sentence does not send your source back to the beginning. Nothing reaches you until the corrected draft 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.