Governed AI-Assisted Delivery in a Public-Publishing Programme

Digital Sanctum used a governed AI-assisted delivery process to coordinate a public-publishing programme involving Sanctum Chat, Sanctum Compose, Sanctum Flow and the Digital Sanctum website.

The programme produced four versioned Compose publication snapshots, three sanitised and explicitly allow-listed Flow showcase derivatives, and a seven-route website experience. On 26 August 2026, a defined production sweep observed the expected routes, structured content, responsive presentation and no-JavaScript alternatives in the tested conditions.

The useful result was not autonomous delivery. Drafting, review, approval, execution and verification remained separate states. Human authority was retained for consequential actions. When evidence was incomplete, a candidate failed validation or a public integration behaved unexpectedly, progression stopped or the defect was isolated before a constrained correction was considered.

This is an internal dogfooding case study. It does not establish customer demand, customer outcomes, search performance, general productivity gains, security certification, accessibility certification or a repeatable return on investment.

The challenge

Digital Sanctum had already published guidance about AI workforce orchestration for professional services. The next opportunity was to make that guidance more useful by embedding structured checklists and governed process models in relevant articles.

That apparently simple reader experience required four connected surfaces to maintain distinct responsibilities:

The boundary mattered because a public derivative is not the same record as its editable source. Matching SHA-256 digests, calculated from separately obtained bytes, can support the conclusion that two participants handled the same candidate. A digest alone does not prove complete receipt, review, approval, authorship or the absence of harmful content. Structural field selection can reduce disclosure, but it cannot guarantee that sensitive prose has not been placed in a permitted field.

An active Compose snapshot remains retrievable until it is explicitly revoked. Disabling future publication does not revoke an active snapshot; an explicit revocation changes later origin retrieval to a gone response. Neither action can recall copies that have already been downloaded or cached.

The control cycle

The programme used a repeatable nine-step control cycle:

1. Prepare a clearly bounded work package.
2. Bind it to a revision and SHA-256 digest.
3. Review product accuracy, editorial quality, claims and operational readiness.
4. Ask an accountable human to approve an exact option and authority boundary.
5. Make only the approved change.
6. Read the resulting state from the system that owns it.
7. Stop and reconcile if delivery or state is ambiguous.
8. Verify the public experience separately from the deployment.
9. Preserve receipts, limitations and recovery references.

These controls were preventive, transactional, detective and recoverable. No single control supplied all four forms of assurance.

What did not go to plan

Lesson 1: prerequisites must come from authoritative state

An early deployment preflight consulted a non-authoritative configuration source. In another attempt, a read omitted the bounded state needed for the next safety decision. A later explicitly required read was not invoked at all.

The first two defects were corrected by making the authoritative source explicit and reducing read results to the exact evidence needed. The later missed read remained an unresolved deterministic-control gap, and no production retry was attempted. In all three events, assumptions were not substituted for the missing observation.

Lesson 2: approval does not override service validation

One action proposal did not appear through the required confirmation presentation. No decision or write followed. In a separate event, an approved process candidate reached the owning service and failed save-time validation without creating a record.

The lesson was that approval, transport and persistence are different states. The first correction restored the required confirmation boundary. The second preserved the failure, prepared a valid successor and required renewed authority because the production candidate had changed.

Lesson 3: deployment success is not public-experience proof

The first browser sweep found an incompatibility in the process-embed integration. The defect was isolated to that integration, corrected narrowly and followed by a rebuild, deployment and repeat browser verification.

This was detective control, not a claim that every earlier safeguard had prevented the defect. Retaining the failed sweep made the distinction visible.

Follow-on test of the same controls

After the launch, the programme applied the same control pattern to an internal knowledge-discovery exercise. Thirty article relationships and six evidence links were executed as separate controlled actions. The first relationship acted as a live canary. The resulting relationships and accumulated evidence-link set were read back before progression.

Two recoveries illustrate the no-replay rule. One request was rejected before any proposal or mutation because it did not satisfy the applicable authorisation policy. Later, a verification read lacked the detail required to prove exact state; execution stopped before the next link and resumed only after a corrected read supplied that evidence. Neither event replayed a completed mutation. The broader work item remained incomplete because the approved package did not authorise its completion.

Bounded production observations

On 26 August 2026, the defined production-verification procedure observed:

• four exact Compose publication snapshots responding as expected, including conditional retrieval behaviour;
• three exact, sanitised and explicitly allow-listed public Flow showcase derivatives while their authenticated source records remained unpublished drafts;
• seven website routes responding successfully;
• four structured article components rendering 11, 23, 12 and 10 items without JavaScript;
• three lazy process embeds with substantive static alternatives;
• no horizontal overflow, page errors or failed first-party requests in the final tested desktop, mobile and no-JavaScript sweep; and
• the Flow backend suite completing with 1,123 tests passed and 12 skipped at the verified revision.

These are dated, point-in-time operational observations. They do not constitute penetration testing, comprehensive authentication assurance, accessibility conformance, external-user usability evidence, a general availability commitment or proof that no vulnerabilities or production errors existed outside the tested routes and conditions.

Commercial discipline

The programme maintained governed internal value and time records so the capacity investment remained visible. Those records are management evidence, not realised revenue, independent market validation or a price promise for future client work.

Internal valuations, pricing and discount records, rates, work-item identifiers and detailed time records remain controlled. They are not part of the public case study.

What the programme demonstrated

Within its internal dogfooding boundary, the programme provides evidence that Digital Sanctum can:

• coordinate specialised AI-assisted work across several products and production surfaces;
• preserve human authority at consequential decision points;
• bind candidates, decisions and executions to exact evidence;
• distinguish prevented change, rejected change, missing evidence and post-release defect detection;
• expose reviewed public derivatives without directly exposing editable source records;
• preserve reader value when JavaScript or embedded diagrams are unavailable; and
• carry technical, editorial, claims and commercial evidence into a governed programme record.

It does not yet prove external adoption, customer value, revenue impact, search uplift, broad security assurance or a general reduction in delivery effort. Those outcomes require separate measurement and customer evidence.

Where this approach applies

This control pattern is most useful in professional-services work where AI can accelerate research, drafting, analysis or coordination but a person remains accountable for advice, client commitments, confidential information or production changes. It is particularly relevant when several specialists or systems contribute to one deliverable and the team must show which evidence supported each consequential decision.

The pattern is intentionally heavier than an ordinary low-risk drafting workflow. It should be scaled to the decision's consequences, reversibility and evidence needs rather than applied mechanically to every task.

Practical lessons

The programme left five practices worth carrying into other AI-assisted delivery work:

1. Give every consequential action an exact authority boundary.
2. Treat a matching digest as evidence that separately obtained bytes match, not as proof of approval or authorship.
3. Require authoritative readback after a controlled change.
4. Separate prevention, service validation, public verification and recovery evidence.
5. Preserve failures and limitations because they show where governance actually operated.

Evidence summary

The evidence classes below support the public account without exposing internal paths, work-item numbers, message identifiers, configuration details or confidential commercial records. The complete source register remains controlled internal evidence.

How to read this summary

The evidence supports the bounded observations and control lessons stated here. It does not extend those observations to other dates, routes, clients or customer settings. It also does not support claims of customer adoption, search or revenue uplift, productivity improvement, certification, comprehensive security testing, automatic sanitisation, autonomous approval, recall of distributed copies, or proof that matching bytes were reviewed or approved.