Zephr

32 MCP tools · 11 platform surfaces · shared registry

Trust / Inspectable by design

Trust is inspectable. Or it does not exist.

Claims on this page originate from deterministic tests, policy enforcement, immutable scope binding, and explicit abstention — not from a badge. Where a gate has not been measured, this page says so in the same size type as everything else.

Copilot memories are written by the agent and cannot leave GitHub; Zephr memories are signed by a human and work everywhere.

Shipped · deterministic tests + policy
TrustBench · ADR-Z-08ADR-Z-09ADR-Z-07 (T3 deferred)
Trust-producing architecture

Four mechanisms produce every claim.

Trust is not a property you assert; it is a property you produce. These four mechanisms run before a claim can be made, and their output is inspectable.

  • Deterministic tests

    TrustBench produces reproducible scenario verdicts. Every verdict traces to a named fixture and a SHA-256 corpus digest, and the suite runs in CI on every merged commit.

    TrustBench · 9/9 measured scenarios

  • Policy enforcement

    The Trust Firewall refuses actions with a named reason. A refusal is not a mystery — it names the failed rule and the fix, and nothing is silently accepted at a lower standard.

    ADR-Z-08 · Trust Firewall

  • Scope binding

    Every connection is bound to an admitted installation / project / worktree scope before work begins. The scope is immutable for the connection's lifetime and cannot be widened by a tool call.

    ADR-Z-09 · immutable scope binding

  • Abstention

    When evidence is insufficient or contradictory, recall abstains. There is no fabricated confidence and no silent blank: every abstention carries the reason it abstained and the retrieval code that produced it.

    retrieval.contradiction · retrieval.empty

Illustrative diagram — not live data. The mechanism descriptions reflect the shipped architecture.

TrustBench evidence

9/9 measured scenarios. 5 features not evaluated.

TrustBench runs deterministic scenarios against the transferred environment. One feature (retrieval) has a fixture corpus and nine measured scenarios, all passing. Five features have no fixture corpus yet — they produce no evidence, so they produce no claim.

Measured feature:retrieval

hybrid recall + abstention

9 of 9 scenarios passed — 100%.

  • passed:Hybrid golden orderinghybrid-golden-ordering
  • passed:Foreign scope excludedforeign-scope-excluded
  • passed:Stale evidence supersededrejected-and-outdated-excluded
  • passed:Semantic paraphrase topsemantic-paraphrase-top
  • passed:Lexical fallback when semantic disabledlexical-fallback-equals-disabled
  • passed:Contradiction causes abstentioncontradiction-abstains
  • passed:Temporal as-of gatetemporal-asof-gate
  • passed:Empty result handled cleanlyempty-result-clean
  • passed:Capacity overflow abstainscapacity-overflow-abstains

Corpus: trustbench.retrieval v2.1
Digest: sha256:5ae0ccfa2b4b7c1e455df6cfd6dab43efd03bfa52ed801f75b91346c9fe2f351

Gate summary

Total features
6
PASS
1
FAIL
0
NOT EVALUATED
5
Measured features
1
Measured scenarios
9/9

The five not-evaluated entries are features, not scenarios. They are never folded into the nine.

NOT EVALUATED features

No fixture corpus = no artifact = no claim.

  • Atomic idempotencyidempotencyNo fixture corpus yet
  • Provenance / claim supportprovenance-claim-supportThe "0 unsupported claims" gate is unmeasured
  • Scope admission + foreign-scope integrityscope-admissionEnforced in code, not yet benched
  • Transport adversarial resiliencetransport-adversarialAdversarial corpus not written
  • UI honesty (no silent external requests)ui-honestyNo automated gate exists

provenance-claim-support is the gate that would measure Zephr's unsupported-claim rate. It is itself not evaluated — so the strength of the provenance section on this page is architectural, not measured, and we say which.

Source: docs/trust/TRUSTBENCH-EVIDENCE.md — a real checked-in evidence report, not sample data.

cat docs/trust/TRUSTBENCH-EVIDENCE.md
Limitations

What 9/9 establishes — and what it doesn't.

9/9 establishes deterministic behavior on this corpus, not statistical significance, production embedding quality, exhaustive adversarial coverage, or universal accuracy.

  • Hand-authored vectors

    Vectors are hand-authored; this measures retrieval logic, not a production embedding model.

  • One contradiction pair

    Only one contradiction pair exists, so contradiction-abstention precision has no statistical denominator.

  • No hard-negative mining

    No hard-negative mining; foreign-scope coverage is a single seeded decoy.

Confirmation law

New claims need a human. Routine repeats can auto-file.

The store enforces a confirmation law that separates what an agent may file from what may be promoted to a durable, trusted claim.

  1. New, contested, or security-critical claims

    Require an authenticated human decision, enforced by the store. No automated actor promotes a claim in these cases without one.

  2. Routine repeats

    May be auto-filed only under user-set rules and must carry the recorded reason. Auto-filing is not unrestricted trust promotion — the rule and the reason are part of the record, and the human who set the rule is accountable for it.

  • Provisional

    in play

    Captured or proposed, but not promoted to durable trust.

    stored asprovisional

  • Confirmed

    at rest

    A human decision, or an explicit user-authored routine rule, is recorded with the item.

    stored asconfirmed

  • Rejected

    at rest

    The item remains attributable and readable with the rejection reason.

    stored asrejected

Circles are still in play. Squares have come to rest. The shape carries the state, so the model survives greyscale, a printout, and a screen reader.

Store-enforced. The distinction is between auto-filing with a recorded reason and promoting a claim to durable trust — they are not the same thing.

The scope lattice

Step the lattice. See what each scope admits and refuses.

Containment is the whole design: a claim can only ever be seen by a scope it was written into. Step from personal to organization — the shipped rungs carry the shipped badge; the team and org rungs are marked planned.

widest = org · narrowest = personal

Personal scope

shipped
admits
Your draft notes and private memory — visible only to you, in every tool
refuses
Nothing escapes into project or team search. The wall is structural.

illustrative — the lattice mirrors the immutable scope binding in ADR-Z-09

Firewall and immutable scope

Policy produces a decision. Scope cannot be widened.

The Trust Firewall and immutable scope binding are enforceable architecture, not aspirations. They run before a claim or a mutation can land.

Trust Firewall — ADR-Z-08

Firewall policy produces a decision and a named reason. A refusal names the specific rule it failed — a useful error, not a mystery. Nothing is silently dropped, and nothing is silently accepted at a lower standard.

Immutable scope binding — ADR-Z-09

Scope is bound before work begins and cannot be widened by a tool call. A connection that never admitted is closed rather than defaulted, and a swapped directory is a new admission decision.

These mechanisms are architectural, not TrustBench-measured. The scope-admission feature remains NOT EVALUATED in TrustBench — enforced in code, not yet benched.

Illustrative diagram — not live data. ADR-Z-08 · ADR-Z-09.

Honesty statement

Absence of evidence is not evidence of absence — it is NOT EVALUATED.

Where a gate has not been measured, this page renders NOT EVALUATED, not silently converted to zero, pass, or supported. The same size type, the same place on the page, as every measured result.

T3 model-assisted judgement is deferred and unbuilt under ADR-Z-07. It has no current authority to override a deterministic policy refusal. When it ships, it will be advisory, provenance-bearing, and structurally unable to overturn a deterministic policy — and it will only be admitted if evaluation proves it improves on T1 and T2.

Zephr holds no accreditation or third-party seal, and makes no certification claim. The explicit security posture — what is and is not held — is documented at /security.

Continuity, not another memory API

How this differs from this week's memory hubs.

Zephr is the continuity and trust plane across coding agents. It is not another memory API, and it is not a coding agent. Its job is to preserve source, review state, scope, and transition evidence as work crosses clients.

Session-capture hooks · plannedAgent Plugins interop · evolvingVault ingest via anydoc · shipped
Dated repository snapshot for memory-hub category context.
RepositoryGitHub starsWhat it represents
MemPalace/mempalace58,401Benchmark-focused memory project; its AAAK/LongMemEval comparability claim was later corrected or contested.
mem0ai/mem063,354Universal memory API.
thedotmack/claude-mem90,856Session-hook capture.
TencentCloud/TencentDB-Agent-Memory22,050Team hub spanning Chat, Skill, LLM-Wiki, and Code-Graph.
supermemoryai/supermemory28,925Local and cloud memory.
letta-ai/letta24,265Stateful agent runtime.
getzep/graphiti29,965Bi-temporal knowledge graph.
vectorize-io/hindsight20,020Scale-focused memory with a published BEAM 10M-token critique of retrieve-everything approaches.
obra/superpowers272,584Skills and execution-discipline plugin, not a memory store.
Egonex-AI/Understand-Anything79,456Interactive code knowledge graph.
firecrawl/anydoc16,328Office/PDF-to-Markdown ingestion used by the Zephr vault path.

Star counts as of 2026-08-16 via GitHub API.

Repository snapshot is factual and dated; the category framing is illustrative, not a benchmark or product ranking.

Illustrative comparison of memory-hub patterns and Zephr responsibilities.
AxisCommon memory-hub/session-capture patternZephr continuity/trust plane
ProvenanceSome memory APIs retain text, chunks, or vectors without a complete claim-to-source chain.Evidence anchors and provenance remain inspectable.
Review stateStored or retrieved context does not necessarily distinguish provisional material from human-confirmed material.reviewState records provisional, confirmed, and rejected; automated actors cannot self-confirm new claims.
Worktree and scopeMemory is commonly attached to a user, agent, or workspace.Installation, project, and worktree scope is bound before disclosure or mutation.
L0 observationsSession-capture tools can inject raw captured history back into context.L0 observations remain evidence and are not automatically injected as durable truth.
ReceiptsStorage and retrieval may not produce an inspectable transition record.Governed actions and handoffs retain receipts and reasons.
Cross-client continuityA memory surface is often tied to one API, runtime, or coding client.The continuity plane carries reviewed state and scope across supported clients.

Illustrative category comparison — not live benchmark data. Individual projects differ; inspect their current documentation before making a procurement decision.

Memory APIs can be useful storage or retrieval components, and session-capture tools can preserve useful raw history. Zephr's distinct responsibility is carrying governed context across coding agents without converting capture into confirmed truth.

Public proof library

Continuity you can show. Real numbers, signed handoffs, scope lattice.

The proof library is the centre of gravity of the marketing surface. Every entry is an artifact — a CI run, a benchmark digest, a signed handoff packet, or a capability status. Nothing on this page is a claim that is not backed by something the reader can verify.

TrustBench real numbers

mirror of docs/STATUS.md

P@5 = 0.207 · MRR = 0.89 · 9 of 9 measured scenarios passed — 100% (9/9) on the single measured feature, retrieval.

Earlier fabricated figures (P@5 = 0.88) were corrected in place per the 2026-08-03 entry below. The numbers above are what the TrustBench run actually produced — not a rounded-up marketing read.

Gate summary

Total features
6
PASS
1
FAIL
0
NOT EVALUATED
5
Measured features
1
Measured scenarios
9/9

The five not-evaluated entries are features, not scenarios. They are never folded into the nine.

Signed-handoff verifier · live `zephr_why` example

zephr_why · Continuity Packet v1

A continuity packet encapsulates the provenance chain of a claim: the scope it was admitted into, the human witness that signed it, and the set of tools the destination is allowed to use. The example below is a real-shape packet; the verifier section further down this page reads the same JSON shape.

{
  "packet_id": "cp_2026-08-19_7c4f",
  "scope_proof": {
    "scope": "Worktree:apps/marketing",
    "admitted_at": "2026-08-19T14:22:07Z",
    "worktree_hash": "sha256:9a07…f13c"
  },
  "signature": {
    "alg": "Ed25519",
    "signer": "zephr_human_witness:u_alice",
    "sig": "5f3a…1b87"
  },
  "allowed_tools": [
    "zephr_recall",
    "zephr_remember",
    "zephr_why"
  ],
  "destination": {
    "host": "claude-code",
    "hmac": "sha256:7d29…b401"
  }
}

References

  • ADR-014 · Continuity Format v1
  • ADR-Z-09 · immutable scope binding
  • docs/trust/TRUSTBENCH-EVIDENCE.md · artifact source
  • docs/STATUS.md · correction ledger

Verified by

zephr_why cp_2026-08-19_7c4f

Scope-lattice explorer

Step the lattice below — the same explorer the rest of the page links to from the “signed-handoff” band. The shipped rungs admit the claim; the planned rungs do not.

widest = org · narrowest = personal

Personal scope

shipped
admits
Your draft notes and private memory — visible only to you, in every tool
refuses
Nothing escapes into project or team search. The wall is structural.

illustrative — the lattice mirrors the immutable scope binding in ADR-Z-09

Capability status table

live from shared-facts.ts · 11 clusters · 32 MCP tools

The registry is the single source of truth. The page never hardcodes a status; drift is rejected by check-capability-home in CI.

Product cluster status table mirrored live from apps/marketing/src/lib/platform/shared-facts.ts.
ClusterStatusLabelHref
MemoryShippedShipped/product/memory
SlipstreamShippedv1.1 shipped · E2E-proven/product/slipstream
LibraryEvolvingEvolving · legal gate not built/product/library
SyncShippedShipped · local reconcile/product/sync
LensEvolvingGate layer tested · hosted runtime in design/product/lens
ReviewEvolvingEngine + lenses built · in development/product/review
PulseEvolvingCore shipped · expanding/product/pulse
GuardShippedShipped · T3 judge deferred by decision/product/guard
FleetPlannedInstallation ledger exists · complete profile integrity + revocation planned/product/fleet
ConnectEvolvingCLI shipped · web wizard partial/product/connect
AgentsEvolvingBuilt, hardening · never self-confirm/product/agents

Public correction ledger

mirrored from docs/STATUS.md · last update 2026-08-19
  • 2026-08-03TrustBench benchmark fabrication, corrected

    The TrustBench block of TRUTH-TABLE.md claimed P@5 = 0.88. An audit confirmed no artifact produced those figures. The real TrustBench run measures P@5 = 0.207 (MRR = 0.89, unchanged and artifact-backed) — a 4.3x overstatement, corrected in place with a CORRECTED marker pointing at the audit row.

    Show artifact + verifier

    artifact: docs/v4-synthesis/audit/00-MASTER-REALITY-TABLE.md#L24

    verifier:

    grep -n "TrustBench" docs/architecture/TRUTH-TABLE.md

  • 2026-08-04Library docs capability corrected to honest post-change state

    The "Library docs" row of TRUTH-TABLE.md was corrected to match the shipped post-change state. The third-party catalog remains gate-CLOSED and is NOT served to any tenant; the legal gate (ADR-018) is intact. The earlier "retired and replaced" claim was itself false.

    Show artifact + verifier

    artifact: docs/architecture/TRUTH-TABLE.md (Library row, ADR-018)

    verifier:

    grep -n "library\|ADR-018" docs/architecture/TRUTH-TABLE.md

Source: docs/STATUS.md — the public correction ledger. The two entries above are mirrored word-for-word from that ledger. The trust-mirror gate refuses a divergence of more than a day between this mirror and STATUS.md.

The constitution

Six constraints. Each is a gate, not a guideline.

The constitution is the spine of the marketing surface. Every claim on this page is shaped by one of the six constraints; every constraint has a corresponding ADR. Violating one requires a change proposal that explicitly supersedes openspec/project.md, not a quiet edit here.

  1. 01

    Agents can never self-confirm a memory.

    Human review state is the product. A memory can only be promoted to durable trust by an authenticated human decision.

    ADR-012 · memory model

  2. 02

    No provenance, no disclosure.

    Every disclosed memory traces to a source event. The provenance chain is the contract; a missing link is a refusal.

    ADR-014 · Slipstream Continuity

  3. 03

    Abstain rather than fabricate.

    Insufficient evidence returns a structured abstention — never a plausible guess. The abstention is the answer.

    ADR-013 · verification ladder

  4. 04

    Publish coverage, not just findings.

    What was not checked is part of the answer. TrustBench reports the not-evaluated features alongside the measured ones, in the same size type.

    ADR-016 · product-surfaces honesty

  5. 05

    Memory is normalised to reported speech.

    No second-person, no imperatives, no URLs in the body. The unsafe form is unrepresentable. This is the token win, the prompt-injection defence (OWASP ASI06), and the fix for agents flagging memories as attacks.

    ADR-012 · memory model

  6. 06

    BM25/lexical ranking on the curated belief layer only.

    Never on the raw observation ledger. The ranking layer is the contract; the observation ledger is for evidence, not recall.

    ADR-014 · Slipstream Continuity

The circuit

Ingest → Connect → Memory → Trust → Continuity → Fleet → loop.

The value is the loop, not any single cluster. A claim that survives the loop is inspectable on the other side — same scope, same signature, same allowed tools. Hover a cluster to see what it does; click to land on the product page.

  1. 01Ingest
  2. 02Connect
  3. 03Memory
  4. 04Trust
  5. 05Continuity
  6. 06Fleet

The circuit is architectural, not TrustBench-measured — the same way the scope-binding and policy-enforcement bands above are. Inspect each cluster's product page for the artefact that ships it.

Receipt verifier

Paste a continuity packet. Read its provenance chain.

The verifier reads the same JSON shape the daemon enforces. It is a stub — the real signature check happens in the daemon — but it catches the field shapes that would make a packet un-deliverable.

Provenance chain

shape rejected

    The example above uses the same shape as the proof-library's signed-handoff demo. Replace the textarea contents to verify your own packet.

    Close

    Read the security model.

    The trust semantics on this page rest on layered controls and measured performance. Both are documented, and both state their limits. The Continuity Format is an open specification. Art.50 period receipts are voluntary transparency evidence that may support an audit — they are not a certification and do not claim the regulation requires human-attested review.