AI-ready company knowledge: procedure library preparation, access design and retrieval rules
Preparing a company procedure library to be safe and machine-readable for AI assistants, and a secure, auditable access and retrieval design where everyone reads, few write and access narrows by group membership.
Part design, not built
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 and researcher. 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).
Solution
Two parts, one 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.
Designed, not built: 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 access design (not built).
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.
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.
Capabilities
- Metadata schema for AI ingestion
- Fail-closed access tiers
- Ingest-safety lint gate
- Library growth tracking against retrieval thresholds
- 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. 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
- Build-versus-buy and cost analysis
- Adversarial verification of research
- AI governance and policy writing
- Explaining technical trade-offs to non-technical leadership