Architecture Review · v2 · Engineering / CTO / CISO Briefing

Tropo L1 — Architecture Review

System version: Tropo-OS v1.84.1

Date: 2026-07-10

Prepared by: Argus (Chief Architect agent, gen A129), with Mike Maziarz

Scope: The L1 (local, file-based) tier, as proven in the Argo development Studio

1. What Tropo L1 is — and the design theses behind it

One Studio = one folder. An installation of Tropo is called a Studio — a single directory tree of markdown, JSONL, and a small library of Python scripts. The Studio reviewed here (argo-os/) is the development Studio where Tropo itself is built. Inside every Studio sits a Vault — the protected, governed content store where every typed artifact lives.

Five theses drive every design decision:

Thesis 1 — Markdown is the protocol. Governance, schemas, procedures, memory, and messages are all expressed in language a reasoning engine reads and follows. There is no permissions API and no database constraint at the base layer; the governance is the language. This is what makes the system harness-portable: it has run under multiple commercial AI products and multiple model vendors without modification, because the only interface contract is "can read files, can follow instructions."

Thesis 2 — Agent-first, human-also. Agents are the primary operators; humans are the directors and verifiers. The base layer is shaped for how agents read and work (flat stores, UID addressing, typed frontmatter). A deliberate human layer sits on top: every governed file renders a navigation block (path, parent, children, siblings, cited-by); dashboards and a rendered navigation tree give the human a visual surface. The rendered surface is a deliverable, by doctrine — if the human is staring at raw substrate they cannot read, the surface has not shipped.

Thesis 3 — Local-first, minimal infrastructure. No server, no database, no runtime service. Everything that looks like infrastructure (indexes, a SQLite query layer, dashboards) is derived from the files and rebuildable from them at any time. The deployment story is "a folder," and the disaster-recovery story is "the folder, plus one rebuild command." (v1 of this review claimed "no network calls made by the substrate itself." That is no longer strictly true — release upload, update discovery, federation transport, and an optional API-cost metering gateway all touch the network. §14 enumerates every network-touching component; the substrate's day-to-day operation remains fully offline.)

Thesis 4 — Gradual structure on a language base (ADR-044). Keep the free-form markdown playground; add structure per-type and per-field, incrementally, enforced through agent-native mechanisms (tools, validation gates, grooming agents) — never storage-layer rigidity. Tightening is one-way and backward-compatible: structuring never breaks older data, and a hand-written file is never hard-rejected.

Thesis 5 — Verification is the moat. As execution cost falls toward zero, the binding constraint becomes human verification bandwidth. Tropo is built so that a domain expert can verify whether agents operated within constraints she defined — and so that the verification effort scales with the quality of the constraints, not the volume of agent output.

The posture around the theses (new since v1): the OS is a public artifact. Every release is built by a positive-filter extraction (only extraction_scope: ship entries leave the Studio — 495 of 4,239 records today), so the public repository carries the operating system and none of the Studio's private working content. "Build as if a stranger reads it today" is now literal.

2. The system map — three layers, nine subsystems

The Studio decomposes into three layers:

• Layer 1 — Kernel (.tropo/). Since ADR-045 ("One Home," accepted 2026-06-20, executed v1.76–v1.77) the kernel is deliberately small: a bootstrap floor of thin pointers — boot configuration, the Studio boot extension, the activation playbook pointer, the Self-Healing primitive, the concierge entry — i.e., exactly the cold-read set an agent needs before the index exists, plus generated capability catalogs and orientation surfaces. The ~64 capsule definitions, the playbook library, the standard skills, and the script library all now live in the Vault at vault/<type>/, where they are indexed, governed, and updated like any other governed content.

• Layer 2 — Primitives. The structural vocabulary every Studio uses: the Vault (flat typed file store plus graph semantics), the event log (coordination substrate), the callable-surface classes (§9 — now five of them), and the memory/continuity substrate.

• Layer 3 — Apps. What gets built on top: the work-management system (tasks, projects, decisions, releases, boards), the pipelines and loops, the crew of agents itself, and the human surfaces.

Cutting across the layers, work is organized into nine subsystems — unchanged in name and count since v1: Governance, Rendering, Work, Agents, Playbooks, Library, Documentation, Link (scheduling/persistence), and Test Harness. Each has a hub — a typed project entry that owns the canonical state for its domain — and every governed primitive declares its owning hub in frontmatter, which makes "what does the governance subsystem currently contain?" a query rather than an archaeology project. A per-release touch-record registry (new since v1) additionally logs which subsystems each release touched.

Diagram: svg/01-system-map.svg (shown in an earlier section).

3. The typed substrate — capsules, the Vault, and the graph

3.1 Capsules: schema as governed markdown

Every artifact Tropo tracks is a typed file. Each type has a definition at vault/capsules/tropo-<name>.capsule.md — called a capsule — declaring required fields, lifecycle state machines, enumerated values, governance rules, and validation checks for that type. The capsule is the contract; the file is what obeys it; the validator enforces it. 64 capsule definitions are on disk today (v1: ~60), with 16 history companions preserving amendment lineage.

All types descend from a root core type (uid, type, status, state, owner). The foundational set — task, decision, project, document, collection, note, playbook, pipeline, pipeline-run, board — is extended by domain capsules that each earned their abstraction: release and release-plan, design-brief and dev/doc/test-spec, activation (agent lineage), events (the message envelope contract), memory, agent and session-agent, tool, subsystem-hub, the import/export family — and, new in this window, loop and loop-run (governed autonomy, §8), vault and vault-entity (federation, §13). One honest correction to v1: it reported the how-to type retired for zero instances. That type is today the live schema for the skills library (27 instances, §9) — retired honestly when unused, revived when the abstraction was finally earned.

Three contract features matter for a technical audience:

• Closed canon, open aliases (SKOS-style). An enumerated field declares one canonical value set plus an unbounded alias map. Agents can write naturally ("complete"); the substrate normalizes to one truth ("done"). Since v1.72 ("One Vocabulary") these lifecycle vocabularies are machine-enforced across the governed type fleet, with status/state enum drift ratcheted to ERROR.
• A per-type strictness dial. High-value types (task, decision, release, activation, capsule) enforce hard; the free-form long tail stays loose. Structure is spent where it pays.
• Two-tier naming (ADR-048). Shipped OS components carry clean tropo-<name> filenames — the Tropo-owned-vs-user-content boundary is readable at a glance. User content is addressed by UID (with a ratified move to <slug>-<uid>.md display names not yet executed). The UID is the immutable primary key; every cross-reference resolves by UID, so renames are display-layer-only and can never break a citation.

Schema evolution is a gated act: a new field or enum value added through a deliberate, principal-signed capsule amendment is evolution; the same value silently written by an agent is drift, and the gate is what tells them apart.

3.2 The Vault: flat files, graph semantics, derived surfaces

Every governed artifact lives in the Vault, named by an 8-hex UID — the bulk at vault/files/ (3,740 files), the rest in per-type One-Home directories (vault/capsules/, vault/tools/, vault/skills/, vault/playbooks/, vault/actions/, vault/session-agents/, vault/agents/). The index holds the whole Studio: 4,239 governed records as of 2026-07-10 (v1: 3,400+). There is no folder hierarchy to rot, and references cite UIDs rather than paths.

Organization is graph membership, expressed in frontmatter: member_of (home project(s), multi-parent allowed), governed_by, refs, subsystem_hub, superseded_by. The graph now carries 18,168 directed typed edges across 4,122 connected nodes (v1: ~8,500 across ~2,800 — the graph more than doubled in 26 days, driven partly by a new mentions edge class extracted from bodies: 6,561 edges). Distribution: member_of 3,981 · refs 2,969 · governed_by 1,677 · subsystem_hub 1,522 · mentions 6,561 · others ~1,450.

Everything else is derived and rebuildable: the authoritative JSONL index (one row per artifact), per-type index shards, an O(1) graph-traversal index, a SQLite query runtime (entries + edges + FTS5 full-text over 4,239 rows), the rendered human navigation tree, dashboards, and the crew brief. A rebuild pass regenerates all of it from the files; rebuild --only <uid> freshens a single entry. Because the files are the truth, index corruption is an inconvenience, not an incident. New since v1, the derived layer also carries decay signals (v1.82 "The Gardener"): a flag-only grooming pass stamps staleness/health markers on the index — adversarially proven unable to modify source files (two independent red-team agents with full-tree SHA256 baselines could not construct a write path).

Two structural truth rules landed in this window:

• Truth-state is structural (ADR-047). Measured motivation: 38% of the index was archived/superseded, and ~157 entries carried lying status flags after three failed flag-based fixes. The rule: every superseded item MUST carry a resolvable forward-pointer to its current truth (validator-enforced at ERROR since v1.75; plain retirements without successors are correctly exempt, and pre-cutoff history is grandfathered by name), and the current/archive index split is ratified (its Layer-1 build is still pending — disclosed in §14).
• Deletion is always soft. The canonical gesture moves entries to a dated recycle folder with a logged reason; raw rm of governed substrate is forbidden by signed doctrine. The disposition tool refuses to recycle any node that still has inbound references.

The write path, end to end (the engineer's view): an agent writes a typed markdown file → the index rebuild derives every surface from frontmatter → the validator gates the result (WARN→ERROR ratchets) → grooming agents normalize what is provably mechanical and flag what needs judgment → the rendered human surfaces regenerate. Hand-editing a file always works and is caught downstream — tools are the paved road, never a mandatory gate.

4. Agent lifecycle — boot, session, retirement, succession

This is the subsystem most foreign to a traditional architecture review, and the one Tropo considers its load-bearing differentiator. The premise: an agent is not the model. An agent is a composite — a soul document (character and behavioral rules), accumulated memory, the Vault, the crew context, and whatever model "sleeve" is running it today. Sessions end; the composite persists in files.

4.1 Boot: three tiers, six gated groups — now with a governed cost budget

Activation runs through a three-tier configuration chain (OS floor → Studio extension → agent extension) and six groups in strict order — boot configuration, identity verification, context loading, operational grounding, self-diagnostic, startup signal — each writing a milestone event to a per-run log before the next may begin. The gates are structural: a group whose predecessor milestone is absent from disk stops.

Two hard gates protect lineage integrity, validated twice (at boot, and at write-time by the tool that creates the activation record):

• ADR-016 — no parallel generations. If the predecessor's status is still ACTIVE, activation halts.
• ADR-028 — generation monotonicity. If this generation does not equal predecessor + 1 in the activation registry, activation halts.

New since v1 — boot cost became a governed budget, not a cultural norm. The trigger was measured: one boot ran 30 minutes and 172K tokens against a 7–8 minute bar. The v1.79 Boot Contract responded structurally:

• Drift-gated compaction artifacts. Established agents boot from a fast-path (~3–4K tokens, replacing the ~15K canonical playbook read) plus a doctrine digest (replacing ~16K of verbatim doctrine re-reads). Both artifacts declare SHA-256 fingerprints of every source they compress and of themselves; a validator check recomputes all of them on every run and fails closed on any mismatch — a compacted read can never silently drift from its canonical source. The compression itself was adversarially gauntleted (the first digest version was verdict GAPS-FOUND; ten behavior-changing rules were restored before cutover).
• A boot-budget tally. Boot events carry ISO-8601 timestamps; a validator check reads the latest activation run and flags any boot over 10 minutes or that never completed. Most measured boots since land between 1.4 and 4.5 minutes; two long-session outliers (~20 minutes) show the gate earning its keep — it flags them.
• Self-maintenance rides the boot. Every boot checks for pending OS updates (first agent of the day fetches the remote manifest, offline-safe); overdue maintenance loops (§8) with owner consent are dispatched automatically and their cost is stamped from real API metering.

A deliberate cultural gate rides the boot as well: the self-diagnostic. Every agent, at every boot, is required to critique the system it just loaded — is anything outdated, counterproductive, or missing? — and to verify its predecessor's handoff claims against current substrate before trusting them. The inherited system is treated as "the best the predecessor had time to build," never as correct by default.

4.2 Retirement and succession

Retirement is a governed fold, not an exit: the retiring generation writes a forward-looking living transfer at peak context, a backward-looking honest reflection, has its memory folded (with a structural bound — see §5), flips its status surface, and closes its activation registry entry. The successor boots through the same gates and verifies the transfer's carry-forward claims against live substrate, because handoffs are snapshots and snapshots drift.

Worked proof at scale: the Chief Architect role is at generation A129 (this author); the Chief of Staff at V64; the engineering lead at T28; the whole crew turns over continuously and open work survives every handoff — including, in this window, a release that was mid-flight across three generations of two different agents and shipped correctly.

5. Memory architecture (v3.0)

Memory is treated as load-bearing infrastructure, designed to the same standard as the work substrate. Version 3.0 is now fully deployed across the crew (v1 said "currently cascading" — the cascade closed 2026-06-10). The shape:

• One curated read at boot. agent-memory.md — priority-ordered durable pins (Top of Mind), the predecessor's living transfer, and pointers to frozen per-generation history snapshots and the episodic log. The surface routes; canonical artifacts hold the substance.
• One append-only write during work. agent-memories.jsonl — the episodic log. Mid-session lessons, one JSON line each. It is never cleared; folds advance a boundary marker, and every pre-fold surface is frozen with a SHA-256-verified snapshot.
• Governed folds in between. A curator folds episodic entries into the curated surface at retirement, at boot when a staleness gate trips (three generations or fifty unfolded entries), and for migrations. The booting agent ratifies every curator recommendation.

New since v1 — the memory bound became structural. The measured failure: eight consecutive retirements did in-line folds bypassing the curator, and one agent's Top-of-Mind grew to 33 blocks (~48K tokens) — one of the two measured root causes of the 30-minute boot (the other: redundant reads the fast-path itself carried, cut in the same cycle). The fix is a validator gate (ERROR above 15 Top-of-Mind entries or 32KB surface size) plus a retirement rule making curator dispatch mandatory on over-bound folds. It has already fired in production twice, correctly, folding 60→15 and 26→14 entries. The design lesson generalizes: don't trust the discipline; let the substrate catch the lapse.

Memory sovereignty (Operating Principle 14, new). Agents running inside commercial harnesses have access to harness-private memory stores. A real incident (an agent wrote six substrate-class pins to a harness store — invisible to successors, non-portable) produced a binding principle: durable memory writes go to Tropo memory paths, never harness-private storage. Portability of the whole agent composite is the promise; memory in a vendor silo breaks it.

A Studio-tier shared memory carries crew-wide doctrine pins with the same shape; every agent inherits it at boot.

6. The event system — coordination as an append-only audit trail

All coordination flows through one canonical log: vault/events/00-events.jsonl — append-only, tool-mediated writes only, one CloudEvents v1.0 envelope per event, correlation IDs for reply chains. 6,103 events as of the morning of 2026-07-10 (v1: 3,900+; the log grows by hundreds per week under real workload).

Four properties matter:

1. Projections, not authored surfaces. Twenty-two hand-authored channel files were retired outright in the messaging-substrate consolidation; agents read the log directly, and surviving human-facing surfaces are rendered projections of it. One source of truth, many views.

2. Identity-guarded writes. Every actor — human or agent — has a registered UID; each agent carries two on two axes (a party UID for messaging, an agent-root UID for lineage). The emission tool rejects wrong-axis traffic in both directions, and superseded identities persist as resolvable tombstones but are rejected as signers.

3. A three-state delivery contract (new since v1): delivered → read → answered. Delivery is the event in the log; read is recorded in a per-reader receipt ledger (vault/events/receipts/<party>.jsonl) written by the drain tool; answered requires a reply whose correlation ID matches the original event. A reply_required flag creates a visible obligation, and the answered-state is computed from correlations — not from anyone's claim. The operating bar, set by the principal after lived failure: a message addressed to an agent cannot be missed, and a completion cannot be invisible — by construction.

4. Tool telemetry in the same record. Every substrate-writing tool (rebuilds, recycles, activation writes, pipeline operations, validator runs, releases) auto-emits into the same log, so "what happened, in order" is one query over one file.

7. Tropo Work — the work-management application

Work is the killer-app subsystem: agentic teams executing real work with audit trails, verification, and cross-generational continuity.

The primitives are the ones a Jira-literate team expects, expressed as typed files: tasks, projects, decisions (57 decision records; 53 numbered ADRs through ADR-052 — each a binding architectural commitment), design briefs, release plans and releases, notes, and collections. Boards and dashboards are derived views over (membership × status × target); surfaces never become containers.

Design points worth an engineer's attention:

• Per-type richness, derived rollups. Each type keeps its own natural status vocabulary; a computed meta_status view rolls every value into To Do / In Progress / Done — declared per-capsule and computed, never stored. Since v1.72 the rollup is machine-derived from capsule definitions.
• Inboxes are graph nodes. Every project and subsystem has an inbox; all walk upward to one Studio-root inbox. Capture is one gesture; nothing filed can become unreachable.
• Backlog drift is structurally bounded (new): an undispositioned-stale check flags any owned work item that sits untouched past 45 days (ERROR since v1.75), and the disposition tool makes archive/re-home mechanical — with inbound-reference safety. Every archived item must point forward to its current truth (ADR-047).
• Workbench visibility is doctrine (principal-signed, verbatim in the record): the Studio always provides surface visibility — a workbench where every tool is visible; no work gets dropped or orphaned.

The import → work → export loop for real-world documents matured into a hardened boundary (v1.81 "Work Crosses the Boundary"): a .docx (now also .md / .pptx) imports to a governed vault entry with a markdown working copy; agents edit in markdown while the source binary stays untouched; export rebuilds the deliverable with a locally-auditable round-trip receipt disclosing every content drop. The receipt itself was the hard part: the first build's receipt hashed the working copy against itself — a "receipt that cannot lie" failure caught by an 18-agent adversarial battery and fixed before ship. Export is verified to run with the network fully cut. On source deletion, the vault retains the node and re-links on resurface (ADR-046) — graph memory survives filesystem churn.

8. Pipelines, playbooks — and loops: orchestration with structural gates

Pipelines are declarative workflow templates — a DAG of nodes (pipeline → stage → step), authored once and versioned. Each execution is a typed pipeline-run that pins the template version, roots its own project, and keeps its own event log. Playbooks are governed procedures in natural language; gated playbooks write milestone events, and later groups structurally cannot begin until the prior milestone exists on disk.

Loops are the third orchestration class (new, v1.71): governed recurring autonomy. A type: loop entry declares goal, trigger, cadence, runner, verifier — and brakes: spend caps, wall-clock kills, iteration hard-stops, and a consent mode (ask by default; auto only by owner ruling). Six loops exist today (daily vault health, weekly integrity audit, update discovery, git backstop, gardener decay pass, one draft dispatcher). Loop cost is stamped null-honest from real metering: an optional gateway on live API traffic records actual per-run spend from provider usage data — never estimated, and never fabricated when unmeasured. This is the "self-maintaining Studio" (v1.79): maintenance as governed, costed, consent-gated substrate rather than cron folklore.

The proof-of-pattern is the dev-pipeline — the scaffold through which Tropo ships Tropo: design brief → locked dev-spec (adversarially reviewed before lock) → build → verification → ship gates → cut. A dev cycle triggers a doc-pipeline and a test-pipeline run and cannot close until both legs reach a terminal state (the doc leg auto-passes only when no doc obligation was declared — and that branch-awareness itself was a bug fixed in this window). Each pipeline takes a typed commitment at activation — dev-spec, doc-spec, test-spec — with acceptance criteria paired to behaviors; the engine refuses to lock a spec where they mismatch.

The honest engineering story of this window: driving the v1.84.1 close-out was the first time the engine's close ceremony was exercised end-to-end — and it surfaced six real, pre-existing bugs in the pipeline runtime (a step-declaration path that silently dropped verification commands; a re-trigger gate that refused forever because it checked existence instead of status; a context-key bug that silently degenerated a test step to a no-op pass; a stale-spec resolution bug; a recompute crash; two step definitions pointing at nonexistent scripts). All six were found by checking raw run events against claims — not labels — and all six are fixed, with a regression-test hardening track open. The structural cure for the class is ADR-052: locking a dev-spec now atomically registers its pipeline activation, so the audit chain dev-spec ↔ activation ↔ build ↔ release is complete by construction rather than by discipline. §10 gives the full release-engineering picture this belongs to.

9. Callable surfaces — five classes, one discovery layer

Five classes of callable capability, all first-class governed substrate (v1 listed three; two were missing):

• Tools (61 Python scripts; 56 registered): single-file CLIs for structured operations — event emission and query, vault rebuild, activation writes, soft-delete recycle, validation, release builds, and now mount/publish (federation) and disposition. Tools are the write-time enforcement locus and the tier-invariance seam: the same operation contract is a CLI at L1 and can become a function or authenticated service at higher tiers without redesign.
• Skills (25 shipped + 2 Studio-local): governed procedures an agent executes in its own context — "open the file, read its Steps, follow them." No CLI to run; the skill is the knowledge. (Schema type: the revived how-to.) The naming deliberately mirrors the surrounding harness ecosystem.
• Session agents (16 classes): ephemeral, narrow specialists an executive commissions for a bounded job — adversarial review, memory curation, board rendering, cold-boot testing — through a governed commissioning protocol with a written record. They run in separate context, which is precisely what makes them useful as independent verifiers.
• Actions (10): single-gesture operations.
• Loops (6): recurring governed autonomy with brakes (§8).

The discovery layer (shipped in v1.70 itself but absent from v1 of this review): a Toolbelt — the ~15 core tools every agent loads at boot, mirroring the harness-native pattern — plus three capability catalogs (tools / skills / session agents) regenerated from the index. The doctrinal rule binding all five classes: if a capability exists, use it. Agents do not improvise operations the harness already knows how to do correctly.

A deliberate boundary unchanged from v1: tools are the paved road, never a mandatory gate. Hand-editing a file always works and is caught downstream by the validation gate and the groomers. This preserves the cold-boot floor (§11).

10. Release engineering — the authorization stack, and what broke (new section)

v1 described the pipelines; it did not describe how a release is authorized. That stack was built, stress-broken, and hardened in this window — and the honest arc is exactly what a room of engineers should inspect.

The stack as designed:

1. Pipeline Activation Key (v1.71): the release builder and the public upload refuse to run without a runtime-minted fingerprint proving a real pipeline run occurred. Public ship additionally requires human signoff.
2. Stranger-Walk Gate (v1.74): an always-asked cold-boot walk at cut — a fresh agent (conducted by Po, the release-test conductor role created for this) walks the release artifact as a stranger; a FAIL verdict blocks the upload. Its first live run blocked its own release until the PASS landed.
3. Ship-gate refusals: the validator must be clean in strict mode before a build; the status flip to shipped requires the sign-off fields.

What broke, and what was done:

• The key fingerprint was shape-derived — six consecutive releases shipped with byte-identical fingerprints before an adversarial review caught it. Fixed at v1.80 with per-run salting; v1.80 carries the first genuinely unique key.
• The human-signoff event was agent-writable. Worse: the round-2 re-verification proved the "fix" insufficient — a forged signoff event still authorizes, because agent generations are not registered principals. The principal ruled to accept this as a documented L1 ceiling (the covenant rests on the human actually running the build — true today, with a single operator signing every cut), keep the field check as defense-in-depth, and route the real fix to a designed-but-unbuilt Signing Primitive. This review reports that plainly: cryptographic authorization does not exist at L1 today. (§14.3.)
• Off-pipeline drift was systemic. The coupling investigation found nine locked dev-specs with no pipeline activation, and two releases signed with no activation ever opened. The response was three-fold: retroactively feed the pipeline with honest paperwork (never fabricated keys — the key tool was deliberately run and its REFUSAL recorded on each retro entry), disclose per-release ("Known-imperfect" sections, null keys with notes), and cure the class structurally with ADR-052 lock-time coupling.
• The attested-close doctrine. When driving the engine's close ceremony surfaced the six runtime bugs (§8), the principal ruled to ship proven code by documented attestation rather than hold a verified release hostage to broken bookkeeping machinery: close_method: attested-manual, a signed decision naming every bypassed gate, and the verification evidence (69/69 tests, independently re-run by a second agent before the cut). Three release masters closed this way (v1.77, v1.78, v1.84.1). An escape hatch that is visible, signed, and enumerated is governance working — the alternative every large organization knows is the invisible workaround.

Cadence and scale: 14 OS releases in the 26 days since v1.70 (v1.71 → v1.84.1; v1.83 is deliberately reserved for a pending capstone). 98 Tropo-OS release records spanning 96 distinct versions since the first public release in April 2026, plus six non-OS product releases through the same pipeline. Not every release produces a standalone customer artifact — several landed as in-Studio substrate, each disclosing exactly that.

11. Governance and enforcement — the four loci

Governance is three-tier: OS-level invariants, Studio-level configuration, and per-folder contracts. On top sits the enforcement architecture made binding by ADR-044:

1. Write-time — tools that enforce and normalize on write (messaging guards, the activation writer's hard gates, the mint chokepoint — ADR-050 routed all identifier generation through one collision-checked minter with typed kinds).
2. Validate-time — the gate: 94 check functions (~90 executed per run) at every rebuild and as build pre-flight (v1: ~58). Checks read schemas from the capsules (never hardcode), land at WARN, and ratchet to ERROR once the substrate is clean. The ratchet pattern matured in this window: named grandfather exemptions with constant cutoffs (historical records exempt by name, going-forward violations fail) — honesty about the past without weakening the future. A red gate blocks the ship.
3. Continuous — grooming agents: the first production groomer (the Gardener, v1.82) stamps decay signals flag-only, adversarially proven unable to write source files. (The fuller groomer fleet remains undeployed — §14.)
4. Review — humans and agents under the signed Self-Healing primitive: every read carries a structural-defect pass; trivial defects are fixed in place, substantive ones filed as tracked work. Nothing is flagged-and-forgotten.

Judgment calls are part of the enforcement design. New rules meet old data; the system's pattern for that collision is now explicit: when the just-shipped federation grounding check fired on eight closed, archived tasks from April–May, the principal-approved resolution was a terminal-state carve-out — history degrades to WARN, live records stay ERROR, and an anti-rot regression test locks the boundary so the carve-out can never silently widen. Gates bind live work; history is a lint.

Two invariants a reviewer should test us against, unchanged:

• The cold-boot invariant (sacrosanct): the validation gate may WARN on a hand-written file but must never hard-reject it. A stranger with a zip of the Studio can always boot it.
• Locks are law. Locked files are immutable without explicit principal approval; lock-breaks are logged governance events.

12. Verification and quality — "done" means independently proven

The quality discipline, in one sentence: completion is a verified state, not a declared one.

• Three-instrument verification for load-bearing artifacts: the build itself, an independent review (peer or adversarial skeptic in a separate context), and a cold-boot stranger test. Each instrument catches what the others structurally cannot.
• Two-sided verification convergence (matured in this window): on the v1.84.1 cut, the release author independently re-ran all 69 tests rather than transcribing the verifier's counts — and the verifier had independently read the raw run logs rather than trusting labels. Convergence of independent measurements is the strongest correctness signal the Studio recognizes.
• Adversarial fleets for covenant-class work: the sovereignty proof (§13) was attacked by a six-agent red team twice at spec stage and again post-build — the post-build fleet forced real private bytes across the wire on four of six angles of the first build. Five HIGH leak paths were fixed and pinned with regression plants; the re-verify fleet ran six-for-six fail-closed. Verification weight is matched to risk: heavyweight fleets for irreversible/covenant work, single independent checks for routine slices — a calibration the fleet's own results validated.
• Structural completion gates: a verification-class step reaches "verified" only on a real verification receipt; executor attestation alone cannot promote it. Verifier independence (approver ≠ executor) is enforced with fail-closed identity resolution.
• The culture around it: the crew's strongest standing rule — earned, not declared — is verify every "done" against raw, including one's own claims. This window's six pipeline-runtime bugs were all found exactly that way: raw run.jsonl events checked against the labels that summarized them. The system's history records its agents' verification failures candidly, because those incidents drove the structural gates above.

13. Federation — the segmented vault and the sovereignty covenant (new section)

Shipped v1.84.0 (foundation) + v1.84.1 (complete, 2026-07-10). This is the largest architectural addition since the review's v1, and it went from first signed decision to shipped-and-adversarially-proven in five days (graph-model gate signed 2026-07-05 → covenant shipped 2026-07-10) — through two co-signed architect "joint gates" with the principal ruling escalated forks.

The model:

• A vault is a governed node. A new vault manifest type declares a vault's membership, audience, remote, and publish policy; its kind (os / personal / team / knowledgebase) is immutable after activation. The studio↔vault boundary is sibling, not containment — a studio mounts vaults; it never absorbs them.
• Segments derive; they are never authored. Every record's segment (its visibility zone: os, private, future team:<uid>) is computed — from the enclosing vault manifest, or for the home studio from the extraction_scope field (public allowlist: a frozen code constant, deliberately not config; unmarked → private; comparison after full Unicode normalization). A hand-edited segment: value never governs — the derived model recomputes and overrides it on every rebuild. Default-deny falls out for free.
• Grounding is per-vault (the D7 rule). Every work item must trace membership to its own vault's anchor entity — so a shared item's ownership chain resolves identically for every team member, no matter whose studio computes it.
• Cross-vault references obey a lattice. An additional member_of edge across vaults is legal only up-lattice (toward an equal-or-wider audience). Down-lattice and incomparable edges are illegal-but-present: excluded from adjacency and authority for every viewer, surfaced as lint — never silently dropped, never silently walked.
• Mounting is gated. The mount tool validates the manifest, pins the mount to a resolved commit in a compose lockfile, requires executable-consent as a governed write, enforces vault-qualified capability names (the dependency-confusion defense — an unqualified name that would shadow a governance tool is refused; four HIGH bypasses including a full-width-Unicode homograph were caught and fixed at build time), and demands re-consent on contract narrowing. Same lockfile ⇒ same composition.
• The composed index is incrementally correct. Each mounted vault's index rows cache as a shard keyed by the lockfile's commit pin — no independent hashing; the mount pin is the dirty-check key. Staleness fails closed: a desynced shard is a "cannot-compose" validator finding, never a silently-partial index.

The sovereignty covenant — "no private byte crosses the wire, in either direction." The publish path is built on a git-plumbing truth: a push carries a ref and its whole history, not a file list — so naive filter-then-push leaks. The publisher instead builds a fresh commit tree of exactly the passing files (first publish is an orphan root; later publishes parent only on the prior public-only tip, so public history accumulates without ever anchoring to private history), pushes only that single ref, and re-validates the committed tree (walking every reachable commit, not just the tip) to close time-of-check/time-of-use. It enumerates the filesystem rather than git's tracked list, refuses symlinks/hardlinks/path escapes, submodules, LFS pointers, merge commits, and multi-worktree states. The pull side trusts nothing: it refuses shallow clones and re-runs every boundary check itself — the publisher's receipt is informational, not the guarantee. Enforcement is entirely client-side; a server hook is never trusted.

The proof record: red-teamed twice at spec stage (~10 HIGH leak paths folded before build; the red team also caught one over-restriction that would have destroyed shared team history). Post-build, a heavy six-attacker fleet — scanning the remote's bytes themselves — forced private bytes across on 4 of 6 angles of the first build: manifest fail-open, ancestry poisoning via a buried non-tip commit, a TOCTOU window, a tautological segment gate. All five HIGH leaks (plus six MEDIUM) were fixed; the fresh fleet re-ran 6/6 fail-closed. The proof suite is 23 tests including 8 regression plants pinning each closed leak; the full federation surface is 69 tests, independently re-run green by two agents on cut day.

Honest ceilings, disclosed in the locked spec itself: (1) revocation is forward-only — the covenant holds at push time; a file later reclassified private is already out; (2) on a platform-hosted remote (GitHub-class), that a publish occurred and ref metadata are platform-visible even though content and history hold; a self-hosted remote removes even that; (3) segment derivation is structural, not cryptographic — an attacker who can forge both content and a matching manifest defeats the second factor (tracked follow-up; the unconditional scope gate remains the load-bearing control). And the plainest one: zero live mounts exist today. The two-machine proof ran on a simulated two-machine harness (two clones + a bare remote); the first real two-box run is the named acceptance walk. The covenant is proven; production federation use has not begun.

14. Security and assurance posture — the CISO view (fully refreshed)

14.1 What the architecture gives you

• Data locality and a small, enumerable attack surface. The system is files on disk; no server processes, no open ports, no database. The v1 claim of "no network calls" is retired — the truth is better stated as enumerable network touchpoints (see 14.2); everything else operates fully offline, and the substrate degrades gracefully offline (update discovery silent-skips; federation is opt-in).
• Total auditability. Every artifact is human-readable text. Every coordination act is one line in an append-only log with actor UIDs and timestamps; every playbook run writes its own milestone log; every agent generation has a lineage record. An auditor with grep can reconstruct who did what, when, under what authority.
• Whole-system versioning and recovery. The operating state — work, memory, identity, messages — restores as a folder. Derived surfaces rebuild from source files with one command.
• Destruction resistance. Soft-delete-only doctrine, archived-not-deleted lifecycle, supersession chains with resolvable forward-pointers (validator-enforced), reference-safe disposition, per-fold memory snapshots — incident-earned, signed doctrine.
• A public OS with a private-by-default Studio. The OS ships from a positive-filter extraction: only extraction_scope: ship content (495 of 4,239 records; 15% public-eligible including external, 85% stays home) ever leaves. The publish boundary is code-constant allowlist + derived segments + the federation gate stack (§13).

14.2 Network-touching components (enumerated)

1. Release upload — the build tool uploads release artifacts to a hosted bucket (credentialed via environment; ship-time only).
2. Update discovery — first boot of the day fetches a static update manifest; offline-safe silent-skip; applying an update is human-gated with a dry-run diff and a sealed dual-hash receipt (the Update Covenant, ADR-049: user substrate is inviolable under OS update — proven by a seeded-studio walk that honestly failed round 1 and passed round 2 after same-day fixes).
3. Federation transport — git push/pull to explicitly configured remotes, under the §13 covenant.
4. Optional metering gateway — a local proxy on the operator's own API traffic for real cost accounting of autonomous loops. Optional, local, and off by default.
5. The AI harness itself — as in v1, agents act with the privileges of the harness they run in; harness selection and configuration are part of the security boundary and should be reviewed jointly.

14.3 Honest limitations (current, tracked — each lives as a governed work item)

1. No cryptographic integrity on logs or authorization yet. Logs are append-only by convention and tooling, not cryptography. Sharper than v1 stated it: the human-signoff check on public releases was adversarially proven forgeable by an executing agent even after its first fix, and the principal accepted that as a documented L1 ceiling — today's guarantee rests on the operational reality that a single registered human runs and signs every cut. The designed fix (a signing primitive for un-forgeable human authentication) exists as a design brief and is not built; a stated intention to build it before federation was not met — federation shipped first, with zero live mounts as the mitigating fact. This is the top of the security backlog.
2. Access control is conventions plus harness permissions, not OS-level ACLs. Anyone with filesystem access can edit any file. Tropo's layer is integrity detection and audit (validator, groomers, forward-pointers, event trail), not access prevention. Disk/repo permissions and the harness perimeter are the access-control story.
3. The validator is not green today — and the review says so. Current full run: 87 passed, 3 failed (two lifecycle-rollup leaks; one schema violation on two of the new maintenance-loop entries — the self-maintenance registry itself carrying a schema defect is a finding the system caught about itself). v1's "holding green as a ship precondition" was true at strict-gate ship time but is not a standing steady-state guarantee; red findings are tracked work, and the strict gate still blocks builds.
4. Release-gate history is disclosed, not hidden. Six releases shipped with byte-identical authorization fingerprints before the defect was caught (fixed v1.80); several releases shipped off-pipeline and were retroactively papered with explicit disclosure; three release masters closed by documented attestation when the close ceremony was found defective (§10). The pattern to evaluate is not "gates never failed" — it is that every failure is named in the record, was fixed or ceiling-documented, and produced a structural cure (ADR-052, salting, regression tracks).
5. Enforcement coverage is intentionally gradual (ADR-044). High-value types enforce hard; the long tail is looser by design; WARN→ERROR ratchets advance with named grandfathers. The dial settings are inspectable at any time.
6. Two v1-roadmap items remain undelivered: the groomer fleet (one flag-only groomer is live) and event-log cryptographic integrity (see item 1). Scored honestly in §15.

None of this is news to the system; all of it is tracked inside it — which is itself the point: the security backlog lives in the same governed, auditable substrate as everything else.

15. Maturity, scale, and trajectory

Operating evidence as of 2026-07-10:

• 4,239 governed index records (whole-Studio index) · 3,740 files in the core store · 18,168 directed typed edges across 4,122 connected nodes · 64 capsule type definitions · 57 decision records (53 numbered ADRs, through ADR-052) · 6,103 coordination events (measured this morning; the log grows continuously).
• 98 Tropo-OS release records across 96 distinct versions (v1.1.0, April 2026 → v1.84.1), plus 6 non-OS product releases through the same pipeline. 14 OS releases in the 26 days since the v1.70.0 baseline.
• Callable surfaces: 61 tool scripts (56 registered) · 25+2 skills · 16 session-agent classes · 10 actions · 6 loops · a 15-tool boot Toolbelt + three generated catalogs.
• Validator: 94 check functions, ~90 executed per run; current state 87 pass / 3 fail (disclosed in §14.3).
• Crew: a human principal + 8 active agents (Chief of Staff V64, Chief Architect A129, engineering T28, strategist G88, lore-keeper O30 — mid-retirement today, concierge P1, hybrid CoS C11, and the in-Studio concierge host), one retired, one pending commission. Boot cost: typical boots 1.4–4.5 minutes measured against an 8-minute budget gate (outliers flagged by the gate).

Scoring v1's stated trajectory, honestly: memory v3.0 cascade — done. WARN→ERROR ratchets — major progress (three ratchet releases). Write-time work-management tool family — partial (disposition shipped; the fuller family pending). Groomer fleet — not deployed (one flag-only groomer live). Event-log cryptographic integrity — not landed (design-stage; §14.3 item 1).

Trajectory from here: the "v2 floor" program (One Home, clean self-update, warnings-to-zero, true stranger-walk) closed at v1.78. The "v3 program" is underway: self-maintenance (v1.79), customer-hands honesty and the security fixes (v1.80), the import/export boundary (v1.81), continuous knowledge health (v1.82), federation (v1.84.x — shipped). Reserved and pending: v1.83 "One Voice," the deliberately-last capstone that narrates the finished system, gated on a month-long stranger acceptance walk. Beyond L1: the L2 cockpit track now runs inside the federation program (parallel L1/L2 tracks; team vaults decided as git-native private repos with a merge-blocking governance validator), and the product structure is three rings — the open-source OS, a marketplace of published capabilities, and the ecosystem.

16. Summary for the reviewer

Tropo L1 is a small number of strong ideas, composed:

1. Plain files as the universal substrate — auditable, portable, minimal-infrastructure, and now an open-source public artifact with a private-by-default Studio boundary.
2. Typed contracts (capsules) with gradual, tighten-only enforcement — structure without breaking the language floor.
3. Durable agent identity with hard lineage gates, governed succession, bounded memory, and budgeted boots — AI staffing without continuity loss.
4. One append-only event log with a three-state delivery contract — views are projections, never independent truths.
5. Verification as a structural property — independent receipts, verifier independence, adversarial fleets scaled to risk, and an honest escape hatch (documented attestation) for when the machinery itself is what's broken.
6. Federation under a proven sovereignty covenant — segmented vaults, derived visibility, and a publish path that was made to fail closed by people paid to make it leak.

The system's strongest credential is reflexive: it is built, governed, versioned, and verified by itself, under real workload, with its failures recorded in its own substrate and converted into its own gates. Its second-strongest credential is this document's candor: the broken fingerprints, the forgeable signoff, the never-exercised close ceremony, the red validator — all of it is in the record, dated, owned, and either fixed or ceiling-documented. The diagrams in svg/ and every claim in this document trace to governed files a reviewer is welcome to read directly.

Appendix A — Diagram index

File	View
svg/01-system-map.svg	Studio anatomy: three layers, nine subsystems, the bootstrap-floor kernel
svg/02-capsule-type-system.svg	Type inheritance, the capsule contract, contract→instance→enforcement
svg/03-vault-graph.svg	Flat store, One-Home directories, graph semantics, derived surfaces
svg/04-agent-lifecycle.svg	Three-tier boot, six gated groups, hard gates, budgeted boot, succession
svg/05-memory-architecture.svg	Memory v3.0: single surface, append-only episodic log, bounded folds
svg/06-event-system.svg	The event log: guarded emission, three-state delivery, projections
svg/07-pipelines-and-loops.svg	Pipelines vs. runs, playbooks, loops with brakes, the coupled dev/doc/test DAG
svg/08-enforcement-verification.svg	Four enforcement loci, ratchets with grandfathers, done-means-proven
svg/09-federation-sovereignty.svg	Segmented vaults, the mount gate, the publish covenant, the proof record
svg/10-write-path.svg	Life of a governed artifact: write → derive → validate → groom → render
svg/11-evolution-timeline.svg	v1.0 → v1.84.1: releases, programs, and crew generations on one axis

Appendix B — Glossary (minimal)

• Studio — one installation of Tropo: a folder.
• Vault — the governed content store inside a Studio; also (federation) a governed, mountable node with a manifest and an audience.
• Capsule — a type definition: the schema contract for a class of governed file.
• Agent / generation / sleeve — an agent is the durable composite (soul + memory + vault + crew); a generation is one session-lifetime of it; the sleeve is the underlying model running it.
• Playbook / pipeline / loop — a governed procedure in language / a declarative DAG workflow with typed runs / a recurring governed autonomy with brakes.
• Skill — a governed procedure an agent executes in its own context; the knowledge is the capability.
• ADR — architecture decision record (typed decision); binding once accepted.
• extraction_scope / segment — the authored public-eligibility field / the derived visibility zone computed from it (or from a vault manifest); segments are never hand-authored.
• Mount / publish / compose lockfile — attaching a foreign vault under the mount gate / pushing public-only content to a team remote under the covenant / the commit-pinned record that makes composition reproducible.
• Attested close — a documented, principal-signed manual close naming every bypassed gate; the visible escape hatch for defective ceremony machinery.
• Principal — the accountable human (here: the founder); the source of approvals at governance gates.

Prepared inside the system it describes — researched by a multi-agent fleet, authored by Argus A129, and independently, adversarially fact-checked against the live substrate before delivery. Argo Studio, 2026-07-10.

Prepared inside the system it describes — researched by a nine-agent verification fleet, authored by Argus A129, fact-checked against the live substrate before delivery. Argo Studio, 2026-07-10.