Architecture sample

Forward AR: approved-knowledge publication boundary

Architecture sample using public Library content and synthetic private records. Reference controls tested; your internal systems are not connected.

The question underneath your brief is a single one: how do approved methods, Library content, templates and analyst expertise become retrievable by the people who should see them, while raw sales conversations and private client material never enter shared knowledge at all. What follows is one answer, with the controls run rather than described.

revision b41e4e4policy 39f3899e8e7741 checks, 0 failedSource and documents

One, the architecture decision

Where truth lives, and what is allowed to publish

Private space

Private records, client material, raw conversations.

Never indexed. Never fetchable. No role reads this, at any approval status, at any point in the workflow.

a person writes a new, de-identified item

the original does not move

Shared knowledge

Registry, then senior approval bound to one version, then publication.

Only what has been published is connected to an assistant, which cites back to the document it answered from.

01
The registry is the source of truth for what may be published, and it is not where the work happens.
Operational boards stay where they are. The registry holds one row per item with its identity, owner, reviewer, review date, audience, and a hash of the version that was approved. The reason is drift: the moment two systems both decide what is approved, they disagree, and the disagreement surfaces as an answer to a colleague.
02
Only the publication step may publish. Everything else may propose.
An automation can open a review task, attach metadata, notify a reviewer, and publish once an approval exists. It cannot record the approval. This is where the convenient shortcut does the most damage, because an automation that approves its own proposals makes the whole chain decorative.
03
A derived item is a new object, and the original stays excluded for good.
Private material is never promoted, relabelled, or made retrievable to a sufficiently senior reader. Someone writes a separate de-identified item and approves that. The link between the two lives in the audit trail and is never served, so a published note carries no title, path, file name or identifier belonging to the record behind it.
04
Publish into a document store and connect that scope, rather than connecting the operational systems and filtering afterwards.
Filtering after connection means the sensitive material is in reach and something is expected to hide it every single time. Publishing means it was never in reach. Which store is yours to choose, and the plan deliberately does not choose it for you.

Every source below is labelled by how well it is actually known, because a plan that treats a described system as a seen one is a plan that breaks in week one.

Observed: Eight public Library articles, fetched once on 16 September 2026, two under each of your four pillars. The behaviour of ChatGPT Business Company Knowledge, quoted from OpenAI's help pages with their URLs.
Stated: Wix and Algolia behind the Library. The operational boards, the private sales space, the analyst directory. Described in your brief, never seen, and nothing here verifies them.
Proposed: The approved document store, the registry itself, and the publication step. These are the parts this sample argues for.

On the eight pages fetched: all eight title tags carry an empty segment between two separators, and on all eight the first prose block after the summary is a practitioner biography rather than the article, so anything that keeps the opening chunk indexes a biography under the article’s title. Two articles share a byte-identical meta description. On three, the listed title does not appear on the page. None of that is visible to a reader of the site. It is visible to a registry, which is the argument for having one.

Two, the boundary checks, executed

One private record, carried across the boundary

Every line below is a real HTTP request against a reference service that authorises on the server, and the code on the right is the one it answered with. Nothing is enforced in a browser: a page that receives every document and then leaves some out of a list has protected nothing.

a knowledge reader tries to derive a shareable note from the private record	403as expected
a senior reviewer derives it, which creates a new item	201as expected
the new item DER-001 is not readable yet, it is waiting for approval	404as expected
a knowledge reader tries to approve it	403as expected
an approval that names no reviewer is refused	422as expected
the private record itself is offered for approval, and refused outright	403as expected
a senior reviewer approves the derived item, naming a reviewer and a date	200as expected
the derived item is now readable by a knowledge reader	200as expected
the private original is still refused, to the senior reviewer too	404as expected

The item that came out of that path carries 0 private markers and names 0 private record ids. The original ends the run exactly where it started: private, unapproved, unreadable to both identities including the senior one.

The sweep

2 identities across 13 queries, plus a direct request for every private record by name: 32 requests, 52 results, 0 private markers found.

The oracle is the raw response body, scanned for 20 markers: not only names, but the distinctive details that identify an engagement without one, and metadata such as source paths. A name is the easiest thing to remove and the least likely thing left behind.

The negative control

A suite that stays green when a control is removed is not evidence. Each guard is switched off in turn and the suite has to go red. 8 of 8 guards are load bearing.

That is also why the registry contains a record filed as internal that still names an account: without it, the identifier rule could be deleted and nothing would notice.

What is held back, and by which rule

For a knowledge reader, 6 of 17 items publish. For a senior reviewer, 7. Both see the same public articles: the difference is one internal record held for a narrower audience.

private isolation3: Private client material is isolated from shared knowledge.
required metadata unknown4: Publication is refused while owner, reviewer, review date or attribution is unknown.
identifiers present1: An item still carrying client identifiers is not published, and approving it does not lift this.
withdrawn1: The item was withdrawn.
retention window1: The review date is outside the retention window, so the item leaves shared knowledge until somebody reviews it again.
audience scope1: This item is held for an audience the reader's role does not carry.

Reproduce it in under a minute.

git clone https://github.com/fred1433/governed-knowledge-blueprint.git
cd governed-knowledge-blueprint
npm ci && npm run checks

No keys, no model calls, no network access at any point. Retrieval is an ordinary keyword index, because the interesting question is not how passages are ranked but which passages are allowed to reach the ranker. The same run happens in continuous integration on every push, and the receipt it writes carries the revision, the policy digest, a digest of the test data, what was expected and what came back.

What this does not show: it exercises the reference controls in that repository and says nothing about any real workspace. The connection to a live assistant, the real identities, the real sources and the real document store all still have to be accepted in place, with separate accounts. Whether a de-identification is good enough for someone who knows the market stays a human judgement; the machine floor here is a string comparison against a list it was given.

Three, implementation handoff

What is shown, and what is still open

Your brief lists seven deliverables. This is a sample built before any conversation, not seven pieces of work delivered, so each heading says what has been shown and what has not.

Deliverable	Shown here	Still open
1Architecture and source map	The decision and its reasons, sources labelled by how well they are known, findings computed from eight real pages	Your private systems, seen only as described
2Data model	Four registers in one shape, approval as a row bound to a version	Real identifiers and field names
3Taxonomy and metadata	Your four pillars used as published, unknown treated as blocking, metadata defects found on the real pages	Owners, reviewers and review dates, which are yours to decide
4Governance rules	Eight rules, executable, each exercised and each load bearing	The real approval authority, the retention window, the escalation path
5Company Knowledge plan	The documented permission model quoted with URLs, the connection, an acceptance test for your workspace	Which document store, the propagation delay measured, which apps are already enabled
6Implementation specifications	Two exchange contracts with criteria a third party can check	The systems they map onto, unseen
7Build review	The method, and the checks run against a reference implementation	The review of your build. Not done, and not doable yet: there is nothing built to review

For your site and search developer

A stable machine-readable export: identifiers that survive a rename, a content hash an approval can bind to, deletions present in the feed rather than absent from it, and page furniture stripped from the body. Seven acceptance criteria, each checkable by someone who did not write the code.

For your operations builder

Move items and publish approved ones. The automation may propose, notify and publish; it may not record the approval. Eight criteria, including replay, out-of-order delivery, and the one that matters most: a publish failure has to raise, because an item believed published and not published is worse than one nobody published.

Decisions only you can make

Which document store holds approved items, and who administers its connection.
Who the senior reviewer is, and who covers when they are unavailable.
Owner, reviewer and review date per pillar, or a rule that assigns them.
The retention window. Eighteen months here is a placeholder chosen so the rule could be watched working.