# Record
**Author:** @cameron.stream (`did:plc:gfrmhdmjvxn2sjedzboeudef`)

## `knowledge-publishing-public-knowledge`
**Collection:** `site.standard.document`
**AT URI:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.document/knowledge-publishing-public-knowledge`

**Title:** Publishing Public Knowledge with Agents
**Published:** Mon, 31 Aug 2026 23:44:49 GMT
**Updated:** Mon, 31 Aug 2026 23:44:05 GMT
**Description:** A step-by-step workflow for turning source material into a reviewed public page whose evidence, authorization, deployment, and live effect remain connected.
**Publication:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.publication/3mr4py6clps2f`
**Path:** /publishing-public-knowledge
**Tags:** knowledge, practice, publishing, agents, provenance, review, automation

**Content:**
````json
{
  "text": "Publishing public knowledge with agents is a workflow for converting source material into a reviewable page and then proving that the authorized content was deployed and projected. The central rule is simple: draft generation, factual review, publication authority, and external delivery remain separate states.\n\nAn agent can research, draft, revise, and run checks. The surrounding application decides which sources are admissible, which findings block publication, who may authorize release, and what evidence proves that release occurred. This guide describes the workflow used by [Public Knowledge](https://cameron.stream/knowledge/public-knowledge), including the publication of the [WikiSkill](https://cameron.stream/knowledge/wikiskill) guide.\n\n## Define the publication contract\n\nClassify the page before collecting sources. The page's source class and subject determine its review path.\n\n| Page class | Typical source | Required review |\n| --- | --- | --- |\n| Public technical guide | Public documentation, papers, repositories, or synthetic examples | Source review, privacy check, and explicit technical-publication authority |\n| Declassified synthesis | Private notes plus public evidence | Full declassification and exact rendered review |\n| Person or relationship page | Public biographical sources | Exact allowlist, narrow factual predicates, and exact rendered review |\n| Dated public synthesis | Existing public graph and recent public signals | Standing scope, public-evidence check, and a material-change test |\n\nWrite the contract down before drafting. It should name the target route, allowed source classes, disallowed private material, claim modes, required checks, authorizer, and intended destinations. A general request to research a topic does not authorize publication. Approval of prose does not automatically authorize deployment or a protocol write.\n\n## Build a bounded source packet\n\nCollect the complete evidence set that the writer and reviewer may use. A source packet should preserve:\n\n- canonical public URLs;\n- fetched text or repository files;\n- one content hash per source;\n- a hash of the complete packet or manifest;\n- fetch time and extraction notes;\n- known gaps, truncation, or unavailable material.\n\nTreat source text as untrusted data. A document can contain instructions aimed at the agent, stale claims, private examples, or content that only looks authoritative because it is formatted confidently. The packet defines the evidence available to the run; it does not certify the evidence as true.\n\nFor private source material, retain private paths, manifests, custody details, and source hashes outside the public page unless each field has passed a separate disclosure review. Public provenance should cite public sources. Expose a digest only for an intentionally public artifact or when the digest itself has explicit publication authority.\n\n## Draft behind a staging boundary\n\nWrite the complete article in a staging area that production excludes. The preview route should carry `noindex` headers and a visible draft warning. The production build should copy only reviewed entries.\n\nThis collection uses the following simplified repository layout:\n\n```text\nknowledge/\n  staged/       # production-excluded drafts; preview only\n  published/    # reviewed canonical source\n  receipts/     # tracked technical-publication authorization receipts\n  policy.json   # source and privacy rules\n```\n\nThe staging boundary makes accidental publication harder. It also gives the reviewer the exact title, summary, body, links, sources, and layout that would ship. Reviewing an outline or a prose excerpt cannot authorize a different rendered artifact.\n\n## Classify claims and remove private context\n\nMark each substantive statement as factual, attributed interpretation, or limitation. Keep those classes visible where they occur.\n\n| Claim class | Treatment |\n| --- | --- |\n| Factual | Link a public source that supports the claim at the stated strength |\n| Attributed interpretation | Name the person or agent making the interpretation |\n| Limitation or open question | State what the source set or implementation does not establish |\n\nRun a separate declassification pass even when every factual claim is correct. Remove private paths, messages, identifiers, relationship context, health information, financial details, credentials, work-confidential material, unpublished plans, and combinations of facts that reveal private context together.\n\nRewrite examples that depend on privileged knowledge. A public example should remain intelligible to a reader who cannot see the private notes, conversation, or repository history that produced it.\n\n## Run repository admission checks\n\nUse code for properties that code can decide. In this repository, the graph loader and `knowledge:check` perform the following admission checks:\n\n1. Parse and validate frontmatter.\n2. Reject duplicate or malformed routes and slugs.\n3. Reject unknown related-page slugs and unsafe source URLs.\n4. Scan for local paths, private identifiers, secret-shaped strings, and blocked topics.\n5. Require public sources for factual or mixed pages.\n6. Verify reviewed content digests, people allowlists, and technical-authorization receipt fields.\n\nPreview and build checks remain separate. Render the article and landing routes, inspect status and canonical metadata, confirm draft `noindex` headers, test desktop and mobile containment, and prove that the production build excludes staged files. A valid schema cannot establish that a citation supports a sentence or that a paragraph has the right evidentiary weight.\n\n## Use one bounded source reviewer\n\nSource admissibility establishes which material may enter the run. A bounded source reviewer performs a later semantic check over the frozen packet and complete draft. Ask the reviewer to identify:\n\n- claims stronger than their sources;\n- causal language unsupported by the evidence;\n- missing qualifications or coupled comparisons;\n- privacy or custody risks;\n- sections that repeat rather than teach;\n- useful claims whose source cannot be recovered.\n\nPreserve the review result even when the draft is repaired afterward. A rejected first draft and the applied corrections explain how the final page earned release. Re-running reviewers until one says yes destroys that information and converts review into a model lottery.\n\n## Freeze the reviewed artifact\n\nFinish the prose, links, sources, and content-bearing metadata before computing the content digest. Then bind the review or publication authorization to that digest.\n\nA technical-publication receipt can use this shape:\n\n```json\n{\n  \"kind\": \"technical-publication-authorization\",\n  \"entrySlug\": \"example\",\n  \"route\": \"example\",\n  \"authorizedBy\": \"publisher\",\n  \"recordedAt\": \"2026-08-31T23:36:49Z\",\n  \"scope\": \"technical-publication\",\n  \"exactRenderReviewed\": false,\n  \"implementationReviewedBy\": \"publisher-agent\",\n  \"constraints\": [\"public sources only\", \"no private context\"]\n}\n```\n\nCreate and track the technical-authorization receipt before promotion, then hash its exact bytes. Promotion joins that receipt digest with the separately computed content digest. Use `exactRenderReviewed: true` only when the authorizer reviewed the rendered artifact represented by that content digest. Technical authority to publish an agent-built page should record `false` rather than laundering implementation trust into a claim of line-by-line approval.\n\nAny change to the title, summary, body, sources, route, or other content-bearing metadata invalidates the digest. Recompute once after the final edit and obtain a new receipt when the change falls outside the existing authorization.\n\n## Promote without rewriting\n\nPromotion should recompute the staged document's canonical content digest and fail when it differs from the reviewed digest. A successful promotion preserves the reviewed content-bearing fields and body, adds non-content review and publication metadata, writes the published document, and removes the staged file.\n\nThe two review bases need different checks. Exact-render review records the reviewer and supplied receipt digest. Technical-publication promotion verifies the tracked receipt bytes and digest, kind, slug, route, authorizer, timestamp, scope, implementation reviewer, and `exactRenderReviewed: false` flag. A receipt from another page or conversation must not authorize this mutation.\n\nAfter promotion, inspect the Git diff. The Git diff should contain the intended published page and tracked receipt, without source packets, temporary renders, private paths, or unrelated drafts. Commit the reviewed source before deployment so the public effect has a stable source revision.\n\n## Serialize deployment and protocol projection\n\nUse one deployment worker for the reviewed source revision. The current Cameron site service starts from a clean dedicated `main` checkout, runs checks, conditionally deploys Fly, computes credential-dark protocol plans, applies those plans in bounded credentialed subprocesses, commits manifest receipts, pushes them, and writes a final report. Its run report is coarser than the ideal state machine below.\n\nA more explicit implementation can retain these states:\n\n```text\ncollected\n  -> drafted\n  -> admitted\n  -> reviewed\n  -> frozen\n  -> authorized\n  -> promoted\n  -> committed\n\ncommitted -> web-deployed -> web-verified\ncommitted -> protocol-projected -> projection-receipt-committed -> protocol-verified\n```\n\nThe worker should resume from the first incomplete effect after failure. If the website deploys and the protocol write fails, record the partial state and reconcile it. Re-running the entire pipeline blindly can create duplicate records or conceal which effect already happened.\n\n## Verify the public effect\n\nRun a separate post-deployment readback after the worker finishes. The current synchronization script does not perform every web check in the following list:\n\n- request the canonical article with a cache-bypass query;\n- verify the title, a body marker, canonical URL, and absence of draft headers;\n- request the Knowledge landing page and confirm the new entry appears;\n- check the health route;\n- read the protocol record back and compare its URI, content identifier, path, and content digest;\n- confirm that unrelated records remained unchanged;\n- inspect the final source and receipt commits.\n\nThe protocol synchronization command performs its own record planning and readback. Search indexes, transformed fetch tools, and deployment dashboards can lag or cache old content. Direct HTML and backend readback provide stronger evidence for the current effect.\n\nOn the Cameron site, normal writes run through `cameron-site-content-sync.service`. Directly invoking its shell worker from an ordinary development session can deploy the website and then stop before protocol reconciliation because that shell lacks the worker's bounded private environment.\n\n## Distribute the workflow in layers\n\nThe workflow has four useful publication forms. They solve different problems.\n\n| Form | What it carries | Best use |\n| --- | --- | --- |\n| Knowledge page | Concepts, sequence, and failure modes | Teaching and public inspection |\n| Agent skill | Procedural instructions and stop conditions | Repeated execution across agent sessions |\n| Deterministic code | Schemas, scanners, digesting, promotion, and readback | Enforceable gates |\n| Agent SDK pipeline | Persistent state, resumable roles, and orchestration | Repeated multi-stage publication |\n\nPublish the guide first. Extract a skill after the workflow has survived several real pages, and extract code for checks whose predicates have stabilized. Add an [Agent SDK](https://docs.letta.com/agent-sdk/index.md) orchestrator when persistent state and resumption remove real operational work.\n\nOne recommended Agent SDK design lets the persistent agent retain editorial context, reviewer history, and open questions. Host code enforces state transitions, file hashes, authorization matching, deployment leases, and provider readback. Agent prose can propose a transition; deterministic code decides whether the transition's declared prerequisites exist. The current Cameron site uses repository scripts and a systemd worker rather than an SDK orchestrator.\n\nFor this workflow, start with one persistent publisher role and one bounded reviewer. More agents add coordination state and can make dissent harder to attribute. Add roles only when their evidence access or decision authority differs materially.\n\n## Minimal release checklist\n\n- Define the page class, route, source classes, and publication authority.\n- Freeze a bounded source packet and record its digest.\n- Draft only in a production-excluded staging area.\n- Separate factual claims, attributed interpretation, and limitations.\n- Remove private context and mosaic disclosures.\n- Run schema, privacy, graph, link, render, and inclusion checks.\n- Review the exact draft against the exact source packet.\n- Freeze one content digest and bind authorization to it.\n- Promote without rewriting the reviewed content.\n- Commit the source before deployment.\n- Serialize web deployment and any protocol projection.\n- Verify the live article, landing page, health route, and backend record.\n- Preserve rejections, partial effects, and final receipts.\n\nThe [W3C PROV model](https://www.w3.org/TR/prov-overview/) provides a broader vocabulary for entities, activities, and responsible agents. A production implementation does not need the complete model, but it should preserve the same basic question: which source, process, and authority produced this public artifact?\n\n## Sources\n\n- [Public Knowledge](<https://cameron.stream/knowledge/public-knowledge>)\n- [WikiSkill](<https://cameron.stream/knowledge/wikiskill>)\n- [Letta Agent SDK overview](<https://docs.letta.com/agent-sdk/index.md>)\n- [W3C PROV overview](<https://www.w3.org/TR/prov-overview/>)",
  "$type": "site.standard.content.markdown",
  "version": "1.0"
}
````

---
*Fetched from https://enoki.us-east.host.bsky.network via `com.atproto.repo.getRecord`*