AI-ready company knowledge: procedure library preparation, a live chat assistant, access design and retrieval rules

Problem

A company wanted every staff member to read and edit its standard operating procedures from inside an AI assistant, with the option to narrow access to one team later, and it planned an internal question-answering assistant that would need the same procedures. The procedures had been written for people, not machines: spread across shared drives, wiki pages and spreadsheets, with inconsistent metadata, broken links, note syntax that an ingest cannot flatten, and no marking of which notes were for all staff and which were restricted. The newer Markdown library could only be reached through one desktop app.

Goal

Make the procedure library machine-readable and access-controlled by default, and design a secure, auditable way to connect it to AI assistants: everyone reads, a few write, and access narrows later by changing group membership with no rebuild. The same design doubles as the retrieval layer for the planned assistant, and it answers honestly whether a server is worth building yet.

My role

Sole architect, researcher and developer. I prepared the library for machine use: structured metadata on every note, broken links fixed, and every note read by hand to set its access tier after a keyword scan misclassified several. I wrote the lint gate, the server specification and the retrieval rules, ran a multi-agent research pass with independent skeptic agents re-checking each decision-critical claim, commissioned parallel cross-reviews from two other AI models and adjudicated their disagreements, and wrote the decision proposal and draft AI governance documents (acceptable use of AI assistants and a handover checklist for AI builds). I then designed, built, tested and deployed the question-answering assistant in the team's chat tool, including its publish step, its test set and its leadership approval flow.

Solution

Three parts: two built and one designed.

Built: an AI-ready procedure library. Markdown notes with a mandatory metadata header, access tiers that default to restricted, stub notes excluded from ingest, and a lint gate that blocks what the ingest cannot handle and tracks the library's growth against the point where retrieval should replace whole-library prompting.

Built: a question-answering assistant in the team's chat tool. Staff send it a private message and get an answer drawn only from procedures confirmed for their tier and approved by leadership, with the source note and its last-updated date on every answer. It is live, and the same service also answers through an internal staff portal under the same rules.

Designed add-on: governed access for AI assistants. A remote Model Context Protocol server that reads procedures from a git repository, signs people in with their company identity, takes roles from directory groups, gates writes by document class and protects edits with concurrency checks. The recommendation the research supported: ship a zero-infrastructure version first (a private repository, an assistant skill and guided onboarding), measure real adoption over a trial period, and build the server only when a named trigger fires, such as a requirement that procedures must not sit on laptops, sustained use hitting the simple version's limits, or a library that outgrows plain search.

How it works

The library (built).

Every note carries structured metadata: status, version, dates and an access tier.

The ingest reads only notes that are complete and tiered. A note with no tier is treated as restricted, and stubs are skipped, so unclassified material is invisible rather than public.

The lint gate fails on note syntax the ingest cannot flatten (embedded notes, block references and query blocks) and on notes with no tier, reports link and callout growth, and measures library size against thresholds that signal when to move to retrieval.

The question-answering assistant (built).

A publish step builds one fixed bundle per tier from the library in git. A note reaches staff only when it is active, tiered for staff and carries a record of who confirmed that tier and when. The step refuses notes with anything shaped like a password or key, and flags money amounts and hidden-instruction tricks (invisible characters and planted commands) for explicit sign-off.

Each new bundle version goes to a private leadership channel, listing what changed since the last approved version. Until a leadership member approves that exact version, staff are told answers are being updated.

Every incoming message is checked against the chat tool's signature, and only company accounts and named people may use it. The person's tier is decided in code from their identity, never by the model.

A keyword search ranks only the notes that person may see, and the best few whole notes go to a hosted language model with the question. The model must return the notes it used and one short exact quote; the server checks that the quote really appears in a cited note, and otherwise replies that it has no checked source. The source line is written by the code from its own records, not by the model.

A question about a procedure that is listed but not yet written gets a plain "not written yet" answer and who to ask. The question log keeps a masked copy of the question, the notes used and the outcome, never the answer text.

Leave requests go through the same assistant with no language model involved: plain code checks balances and dates, and a person in leadership decides every request.

The access design (designed add-on).

The notes live in a git repository and are loaded into memory at cold start, kept fresh by a short time-to-live re-pull plus a push webhook, so the server holds no disk or clone state.

Each person adds the server to their assistant once and signs in with their company account. The server checks the hosted-domain claim inside the verified ID token, never a request parameter that could be spoofed, and resolves the role (reader, editor or admin) from directory groups, falling back to "company member equals reader" if a group does not exist yet.

Tools are task-shaped: search, read, list, history and edit. Authorisation applies on every operation: inside search before ranking, on direct reads, and in caches, citations, logs and error messages. Logs record who read what, never the note text.

Every read returns the note's content hash and every edit must present it, so a stale edit is rejected.

Operational procedures commit directly, with the staff member as author and a bot application as committer, so nobody needs a code-hosting account. Controlled documents open a review request instead, and their version and date must be bumped.

For the question-answering assistant, only active, approved notes of allowed types with no open review flag are eligible. Documents are chunked on their natural rule boundaries rather than by length, every chunk carries its source, version and owner, answers drawn from a rule that has an exception route must say that an approved exception may exist, and retired notes leave the index. The built assistant applies the eligibility rules today and searches whole notes, which suits the library at its current size; the design sets when to add meaning-based search.

Technical challenges

The company identity provider cannot act as the protocol's authorisation server (no dynamic client registration, no resource indicators, basic scopes only), so tokens cannot be audience-bound without a small login service in front, and the server must publish protected resource metadata or the client silently omits the resource parameter.

Group-driven access from day one, because per-person static tokens would turn narrowing access into a manual re-issue.

Two design principles, each confirmed by independent cross-reviewers: a git clone has no per-file access control, so restricted content belongs behind an access-checked server rather than in a clone on every device; and a merge only counts as approval when branch protection is enforced, which is why serving an immutable validated release is the stronger control.

A desktop sync service as a competing write path.

Staff-editable notes as a prompt-injection surface.

A fast-moving protocol ecosystem, answered with pinned versions and a small tool surface.

Making unclassified notes invisible rather than public, and finding the note features that silently break when flattened for a model.

For the live assistant: replying inside the chat tool's few-second limit while the real work runs in a queued step, handling each message once even when the chat tool sends it again, and stopping the model from inventing a source by checking its quote against the note text.

Giving leadership an approval step without asking them to use git: a button in their private channel that marks the exact version the assistant may load.

A hosted model service that could not search the library in a usable way or be called as a saved agent, which is why search, tier checks and citation stay in our own code and the model can be swapped.

Capabilities

Metadata schema for AI ingestion
Fail-closed access tiers
Ingest-safety lint gate
Library growth tracking against retrieval thresholds
Question-answering assistant live in a team chat tool
Answers only from approved, tier-confirmed procedures
Server-checked quotes and code-written source lines
Leadership approval of each knowledge version
Publish checks for secrets, money amounts and hidden instructions
Design of a remote tool server for AI assistants
Single sign-on with domain verification
Group-based roles that can be narrowed later
Optimistic concurrency on edits
Write gates by document class, with human review for controlled documents
Retrieval eligibility rules and rule-level chunking
Build-versus-hold cost and adoption analysis
AI governance policy drafting

Technology

Impact

The procedure library became a governed source an internal assistant can ingest safely, with restricted material excluded by default, and the question-answering assistant built on it is now live in the team's chat tool. No usage figures are claimed. Leadership received a decision document showing that hosting was a minor cost next to AI seat licensing, and that adoption and content, not hosting, were the real constraints. The staged recommendation avoided committing to a multi-week build before demand was proven, and the retrieval rules were settled while they were still cheap to change. The server was designed and recommended, not built, and no claim is made that it was adopted.

Skills demonstrated

Solution architecture
Identity and access design
Secure-by-design thinking
Retrieval-augmented generation design
Knowledge management for language models
Building and running a production chat assistant
Testing language model answers for safety and grounding
Build-versus-buy and cost analysis
Adversarial verification of research
AI governance and policy writing
Explaining technical trade-offs to non-technical leadership