Legibility And Continuity
A system the user cannot inspect is a system the user has to trust on faith. Stallari refuses that posture. Every surface the platform produces — content, state, decisions, history — is inspectable through first-party tooling. The user can read what the platform knows, what it did, and what it decided, without depending on a vendor for the answer.
This is not a slogan that everything is plaintext. Some substrates are SQLite-backed for performance and encryption reasons that plaintext cannot satisfy. The honest claim is sharper: every surface is inspectable through first-party tooling, with no vendor opacity. Markdown is the default authoring surface where it makes sense. SQL substrates surface through dedicated UI panes. Encrypted credential blobs are intentionally opaque even to first-party inspection. The user can tell which is which and why.
Markdown First
Section titled “Markdown First”The user’s content lives in the vault as Markdown with YAML frontmatter. Notes, ledgers, decision records, briefings, correspondence summaries, pack manifests, skill prompts — all of it is plaintext on disk that the user can read with any text editor.
This is load-bearing. When the platform writes to the vault, the user can verify the write by reading the file. When the platform deletes a note (it never does — it archives), the user can verify the move. When a skill modifies frontmatter, the diff is visible in any version-control tool. The vault is not a black box that the platform claims to write into; it is the user’s filesystem.
Obsidian is the editor most users reach for, but the substrate does not require Obsidian. Any Markdown-aware tool reads the vault. The user could write a Python script tomorrow that parses the entire vault and the substrate would not care. Stallari does not own the format; it cooperates with it.
SQL Substrates: Inspectable Where It Counts
Section titled “SQL Substrates: Inspectable Where It Counts”Several load-bearing substrates run on encrypted SQLite for reasons that Markdown cannot satisfy: high-volume append (dispatch records), fast structured query (memory recall, scope classification), integrity-protected state (runtime materialised bundles, credentials). The user does not read these with a text editor — but the user does read them.
The platform ships first-party inspection panes for each substrate it expects the user to consult:
| Substrate | Inspectable surface today | Notes |
|---|---|---|
| Vault content | Filesystem and Obsidian. | Plaintext-first, no platform mediation needed. |
memories.db (Open Memory Substrate) | Insights pane in the app. | Lists every memory with content, domain tag, source agent, timestamp, importance, vault note link. |
tracks.db (Track records) | Activity pane in the app. | Idempotency-keyed, watermarked, append-only — every workflow handoff surfaces. |
traces.db (Dispatch runs) | Activity pane in the app. | Per-dispatch records (Activity in the UI) — what ran, what providers were called, what cost. |
| Credentials (CredentialStore) | Settings → Vault & Encryption. | Surfaces credential names and metadata; values are intentionally not exposed even to first-party UI. |
| Runtime materialised bundles | RuntimeIntegrityCheck health pane. | Reports integrity verdicts; per-key listing is partial today. |
The encryption is honest: every SQLCipher store opens through the same migration pattern with a key sourced from the keychain-backed credential store. A user who exfiltrates a database file does not get a readable database. The key never leaves the user’s machine.
Substrates Currently Gapped
Section titled “Substrates Currently Gapped”The platform does not claim complete inspectability for v1. The legibility axis is defensible because the gaps are named:
- Commitments substrate — Agent promises are durable on the daemon and observable via MCP, but there is no first-party UI pane listing outstanding commitments yet.
- Per-key runtime listing — RuntimeIntegrityCheck reports a verdict for the materialised bundle tree but does not yet enumerate individual key states.
- Audit and pulse panes — Several lower-level audit surfaces (pack-load history, scope-derivation history, classifier feedback log) are observable in logs and via MCP but lack dedicated panes.
These gaps are tracked by the follow-on DEVFU-2026-05-20-sql-substrate-inspectability-surface register entry. The posture is to ship the gap-closing UI work rather than overclaim.
Intentionally Opaque
Section titled “Intentionally Opaque”Some substrates are not inspectable by design. The CredentialStore holds API keys, tokens, signing material. The platform exposes credential names and metadata in Settings — enough for the user to know which credentials exist and which integrations they support — but it does not expose the credential values, not even to first-party UI. This is the same posture every responsible keychain takes. Inspectability of a secret defeats the purpose of holding it as a secret.
The boundary is documented. The user knows what is opaque (credential blobs) and what is not (credential names, metadata, last-used timestamps). The opacity is named, not snuck in.
The Audit Trail As Memory
Section titled “The Audit Trail As Memory”Every dispatch produces a Track record (issue-shaped, idempotency-keyed) and a corresponding dispatch run with full step-by-step detail. Both are append-only. Both survive restarts. Both survive instance migration. Both survive the model that produced them being deprecated.
The Activity pane reads both. A user asking “what happened with the briefing job yesterday?” gets an answer from disk: the workflow that ran, the steps it took, the tools it called, the providers it used, the cost in tokens, the cost in time, the outputs it produced. The model that ran the job does not have to remember. The audit trail does.
This is what makes the platform legible at the human timescale. A model session forgets. A model vendor changes its API. A workflow gets rewritten. None of this erases the historical record. The user owns the audit trail in the same way they own the vault.
Continuity Through Precedent
Section titled “Continuity Through Precedent”The audit trail is also the substrate for precedent. When the platform makes a judgment call on the user’s behalf — picking a recipient, selecting a provider, choosing a classification, deciding to draft rather than auto-send — the call is recorded with its reasoning.
stallari-precedent lifts these into a queryable continuity layer. A skill making a similar judgment tomorrow can read the prior precedent, follow it, or override it. The override itself becomes new precedent. The user’s accumulated taxonomy compounds rather than resetting every session.
This is how Stallari mirrors how legal continuity actually works: not as a rule-book the user has to maintain, but as a record of decisions the future can consult. A skill from a third-party pack reads the same precedent store as a first-party skill. Continuity crosses pack boundaries.
Warrant Canary
Section titled “Warrant Canary”Substrate-level legibility extends past the platform’s own actions to compelled disclosure. Stallari operates a warrant canary on its public surface: a quarterly signed attestation that no compelled-disclosure orders have been received. The canary is signed by the platform’s release key. A break in the canary cadence — or an attestation that fails to update — is a public signal the user can read without coordination with the platform.
This is not protection against compelled disclosure. It is transparency about it. A platform that does not publish a canary cannot say truthfully whether it has been compelled to act against users. A platform that does — and updates it on a public cadence — has bound itself to a posture that any user can verify.
The substrate posture makes the canary load-bearing in a specific way. User data and encryption keys reside entirely on the user’s machines — vault content as Markdown on disk, SQL substrates as SQLCipher blobs whose decryption keys live in the macOS Keychain (Secure Enclave on capable hardware) and the iOS equivalent on the companion. The platform itself holds no per-user data, no per-user keys, and no central decryption ability. There is nothing centralised that a compelled-disclosure order could target to expose an individual user’s data — the data and the keys are not in a place the platform can be ordered to surrender.
What such an order could compel is platform-wide: a court could in principle direct the platform to ship an update that weakens encryption, embeds a backdoor, or alters the signing posture for every user at once. That is a different threat from “hand over user X’s data” — it is a posture change visible to every user as a release artefact. The canary surfaces precisely this class of compulsion: a break in cadence is the signal that the platform’s posture is no longer what it was. Such an order would naturally be contested in the courts before any update shipped; the canary’s job is to make the contest visible to users without privileged disclosure from the platform.
In-App Documentation Browser
Section titled “In-App Documentation Browser”A separate first-party inspection surface: the in-app Docs and Governance browser renders the same documentation corpus you are reading now, alongside governance materials, directly in the app. The user does not have to open a browser to consult what the platform documents about itself.
What Legibility Buys
Section titled “What Legibility Buys”The combined posture has practical consequences. A user can verify a write by opening the file. A user can verify a decision by reading the audit trail. A user can verify continuity by querying the precedent store. A user can detect compelled disclosure by watching the canary. A user can hand the platform to a successor — the vault is portable; the encrypted stores migrate with the user’s key.
Legibility is not a feature. It is the substrate that makes everything else trustworthy.
Related concepts
Section titled “Related concepts”- Agency model — how the audit trail is produced as a side effect of every dispatch.
- Context and memory — how memory is inspectable as a substrate.
- Packs and trust — how pack integrity is verifiable through hashes.