In this field report
A new agent conversation needs a trustworthy starting point, not an enormous transcript presented as timeless truth. The September 8, 2026 Jarvis knowledge design used ordinary Markdown to solve a practical handoff problem: keep current operational records small, retain the reasoning and evidence behind them, and generate a bounded attachment that another session can actually consume.
The architecture is deliberately less magical than “the agent remembers everything.” It does not train model weights, automatically synchronize conversations, or guarantee that yesterday's verified state is still true. It makes the loaded knowledge version visible and gives updates a reviewable path.
Put different kinds of knowledge in different lanes
The canonical entry point routes readers to current state, goals, decisions and one relevant topic pack. Detailed domain records remain behind that small core. Existing historical ledgers are retained rather than automatically moved, rewritten or promoted.
The trust model distinguishes verified facts, plans, historical evidence and unknowns. A plan describes desired state; it does not prove deployment or grant authority. A session note records what a conversation attempted, observed, changed and left open. It is evidence about that session, not a self-updating description of the infrastructure.
Accepted architecture belongs in a decision log. When the architecture changes, the system calls for a new decision with a supersession note, preserving the earlier rationale. Reconciled operational facts belong in current state; owner intentions belong in goals. This prevents a confident handoff summary from silently becoming an authorized implementation plan.
Canonical promotion requires explicit owner approval or an explicitly designated librarian. Routine agents may prepare historical session drafts without authorizing their own promotion. The resulting boundary is both epistemic and operational: what is believed, how it was established, and who may make it canonical are separate questions.
Freshness needs metadata—and restraint
Canonical pages carry frontmatter for status, verification time, update time, review interval, ownership, topics and sensitivity. Mixed pages separate verified facts, desired state and provenance into labeled sections. A historical page can have no live verification timestamp at all.
The builder records source freshness relative to the knowledge snapshot it compiles. A review interval is therefore a policy signal, not a background monitoring service. An old attachment cannot check the present wall clock, contact a server or repair a stale fact by itself. Before a risky operation, the reader still needs current read-only evidence and current authority.
The entry-point protocol asks an agent to state the newest verification timestamp it actually read and whether live state has been revalidated. The retained September 8 distribution uses a 16:30 UTC knowledge timestamp even though building and deployment happened later. A later file-transfer time must not be mistaken for later observation of every fact inside it.
Generate context; do not hand-edit the output
Reviewed canonical Markdown is the source. The build derives a master context, smaller topic packs and manifests. Configured character limits bound the master and topic packs so growth cannot silently consume an entire model window. These are character budgets, not promises about an exact token count for every tokenizer.
The source fingerprint incorporates configuration and source-file hashes. A build receipt records the generated version, file sizes and SHA-256 digests. Generated output is not an alternative editing surface: corrections go to the smallest canonical page, followed by validation and a new build.
Retained receipts also show why provenance needs honest bookkeeping. One tree was built in a sibling staging directory and then renamed to its canonical location. An immutable addendum corrected the receipt's resulting path references rather than rewriting the original receipt. It also clarified that a prospective prior-output backup directory had not been created because no prior output existed.
A receipt is valuable when it accurately records what happened, including what did not happen. It should not turn a proposed backup path into a claim that a backup actually exists.
Stage, verify, then publish the pointer
The Windows refresh implementation downloads a selected generation into a guarded staging directory using strict pinned host-key verification. It first reads the version pointer, then fetches the master, bootstrap prompt and optional selected topic pack. Each chosen file must match the pointer's authorized SHA-256 and byte size before publication.
Hash comparison checks content integrity; it does not establish whether an operational statement is true or current. In this review, the retained Windows master and bootstrap prompt both matched their recorded hashes and sizes. That is a real integrity check of the saved handoff, not a fresh infrastructure census. Microsoft Get-FileHash documentation.
Original architecture diagram. The pointer is published last; the diagram does not imply model training or automatic conversation ingestion.
Before replacing managed local files, the refresh backs up existing files and the prior pointer. Old topic packs are held aside so an unselected stale pack cannot linger as though it belongs to the new generation. Content is published first and the pointer last as the commit marker. The script restores the prior generation when its publication error handler runs.
This ordering is not a claim that several file copies become one indivisible filesystem transaction, or that every possible power-loss failure has been tested. Readers must respect the committed pointer and verified generation. Individual atomic replacements have their own filesystem constraints; even Python's documented rename primitive does not supply a multi-file transaction. Python os.replace documentation.
The handoff still has a human boundary
For an ordinary chat without access to the knowledge host, the workflow is an explicit attachment plus a bootstrap instruction. A filesystem or share location is not automatically readable by a conversation. A refreshed local copy also does not automatically replace a previously attached cloud-project file.
After meaningful changes, review the source, rebuild, verify the receipt, refresh the attachment and say what version was loaded. Versioned context does not eliminate uncertainty. It gives uncertainty a label, makes the handoff auditable, and keeps historical confidence from masquerading as current evidence.
Evidence basis: retained September 8 knowledge-build/deployment receipts, canonical trust and frontmatter runbooks, and the Windows refresh implementation. No new deployment or automatic synchronization was performed to write this article.