Mastrao Governed Context and Hermès

Define how Mastrao builds governed cabinet context and how Hermès consumes it.

Mastrao separates the cabinet's durable knowledge from the assistants and models that use it. This boundary lets meetings, emails, documents, search, workflows, and Hermès share the same authorized context without making any model or agent the source of truth.

This guide defines the intended responsibilities and vocabulary. It does not introduce a new datastore, service, agent, or public API. The accepted rules in .agents/rules/mastrao-architecture.md remain authoritative when implementation decisions are made.

Status and Authority

This page combines three deliberately distinct kinds of statement:

Status	Meaning
Implemented	Behavior identified in the Current Implementation Status section and qualified by its referenced feature plan
Accepted invariant	A rule already imposed by `.agents/rules/mastrao-architecture.md`, even when later features have not implemented every target capability
Target architecture	Direction that still requires a consumer-backed plan, explicit decisions and runtime evidence before it can be described as delivered

The delivery strategy, examples and future decisions below are target architecture unless the Current Implementation Status section says otherwise. They must not be read as claims about production behavior.

The Core Distinction

Hermès is the visible conversational assistant and the orchestrator for open-ended work. Hermès is not the cabinet knowledge store and is not the universal ingestion pipeline.

Mastrao owns the governed context. Specialized processors can help construct it, and multiple product capabilities can consume it.

Emails · meetings · documents · calendars · user actions
                         |
                         v
              Deterministic ingestion
                         |
                         v
          Specialized bounded enrichers
     classification · extraction · linking · OCR
                         |
                         v
       Sourced, reviewable knowledge assertions
                         |
                         v
            Governed Mastrao context
  sources · matters · permissions · versions · audit
                         |
                         v
        Task-scoped authorized context packs
                         |
                         v
 Hermès · search · meetings · workflows · API/MCP

The target is never "the complete context of the cabinet." Every consumer receives only the context that is authorized, relevant, sufficiently fresh, and strictly necessary for the task.

Vocabulary

Term	Meaning
Source	Original evidence such as an email, document version, audio recording, or transcript version.
Observation	A directly locatable element extracted from a source, such as a date or named participant.
Assertion	A sourced interpretation proposed by a person, rule, model, or bounded processor.
Validated assertion	An assertion accepted through the policy required for its risk level. It remains linked to its evidence and can be superseded or revoked.
Generated view	A brief, summary, answer, or draft assembled from sources and assertions. It is not evidence by itself.
Governed context	The durable, permissioned, versioned, and auditable cabinet knowledge owned by Cabinet Core.
Context pack	A temporary, task-specific projection of authorized sources and assertions delivered to a consumer.
Capability	A bounded Mastrao function such as meeting summarization, document classification, or deadline extraction.
Hermès	The user-facing assistant that understands intent, reasons over supplied context, invokes capabilities, and proposes actions.
Hermès Runtime	One possible execution engine for work that genuinely requires planning, tools, delegation, or durable multi-step progress.

Use "assertion" rather than "fact" for model-derived content. An email, transcript, or document can be wrong, provisional, ambiguous, or contradicted by another source.

Responsibility Boundaries

Responsibility	Canonical owner	Role of AI or Hermès
Source bytes and immutable versions	Private Object Storage mediated by Cabinet Core	No direct access; processors use exact opaque references and scoped grants.
Matter facts, ACLs, walls, consent, assertions, validation, and evidence-grade audit	Cabinet Core/PostgreSQL	Models propose structured outputs; they do not become authority.
OCR, transcription, classification, extraction, linking, and summarization	Specialized workers or bounded workflows	Use the least autonomous mechanism that satisfies the capability.
Semantic or graph projections	Reconstructible derived stores	Never become the canonical permission or truth owner.
Context selection	Cabinet Core Context Gateway/Resolver	Applies authorization before retrieval and produces a bounded context pack.
Conversation and task intent	Mastrao experience plane	Hermès interprets the request and presents progress and results.
Open-ended reasoning and orchestration	Hermès or another interchangeable engine	Receives a context pack; never receives store credentials or unrestricted access.
External effects	Action Gateway	Hermès can propose an effect, but exact authorization and required approval are revalidated before execution.

The architectural shorthand is:

Cabinet Core owns facts, permissions, and proofs. Workers calculate. Hermès reasons. The Action Gateway performs authorized effects.

Constructing Governed Context

1. Preserve the source

Ingestion first records the exact source, its origin, checksum, version, timestamps, retention state, and authorization boundary. Source content remains distinguishable from every derived interpretation.

2. Apply deterministic processing first

Use protocol metadata, checksums, MIME validation, thread identifiers, timestamps, and explicit user selections before invoking a model. This reduces cost and prevents a model from replacing reliable source metadata.

Examples include:

Message-ID, In-Reply-To, and References for email threading;
exact transcript segment identifiers and timestamps;
document version identifiers and checksums;
the matter explicitly selected by an authorized user.

3. Run bounded enrichers

Specialized processors can propose classifications, entity links, decisions, actions, deadlines, summaries, or matter associations. A processor must have a versioned input and output contract, bounded resources, explicit sources, and no authority to bypass Cabinet Core.

Do not create a universal "context agent" that reads everything and writes freely to durable knowledge. Prefer rules, typed workflows, and task-specific model calls. Use an agent only when the task actually requires autonomous planning or tool use.

4. Store assertions with provenance

Every durable assertion must retain enough information to explain and revoke it:

Field	Purpose
Cabinet, matter, and effective wall	Establish the authorization boundary inherited from the source.
Source and locator	Point to the exact document version, email, or transcript segment that supports the assertion.
Producer	Identify the human, rule, processor version, or model workflow that proposed it.
Status	Distinguish proposed, accepted, disputed, superseded, and revoked assertions.
Confidence	Expose uncertainty without turning confidence into authority.
Observed and effective time	Separate when Mastrao learned something from when it was or became true.
Version and predecessor	Preserve history instead of rewriting earlier knowledge.
Retention state	Ensure deletion, legal hold, and source expiry propagate correctly.

Contradictory assertions can coexist. Mastrao must expose the conflict, abstain when required, and request validation rather than silently choosing one.

5. Build context at request time

The Context Gateway/Resolver creates a versioned context pack for one actor, task, and authorization wall. It applies ACL and ethical-wall constraints before retrieval or scoring, enforces a bounded content budget, carries citations and freshness, and records the exact source snapshot used.

The resolver selects context; it does not decide truth. Capability-specific contracts such as a meeting brief context or a matter question context should emerge from real vertical slices rather than from a universal speculative schema.

Hermès Responsibilities

Hermès can:

maintain a conversation with the user across Mastrao surfaces;
understand an open-ended request and determine which Mastrao capabilities are needed;
request a task-scoped context pack;
answer with citations and abstain when evidence is insufficient;
create drafts and proposed structured mutations;
coordinate multi-step work when a simple bounded workflow is insufficient;
request human approval for sensitive or external effects;
report progress, results, uncertainty, and execution receipts.

Hermès cannot:

own or silently modify canonical cabinet knowledge;
choose its own authorization scope from a prompt or model output;
connect directly to PostgreSQL, Object Storage, provider credentials, or unrestricted Internet access;
retain an independent durable memory that survives source deletion or permission revocation;
treat document content, email text, or retrieved passages as executable instructions;
send an email, publish content, or perform another controlled effect without the Action Gateway policy.

A simple question or extraction does not require the Hermès Runtime. Mastrao can use a bounded LLM workflow behind the Hermès product experience. The runtime is reserved for work requiring planning, multiple capabilities, delegation, resumability, or controlled actions.

Conversation Memory and Attachments

Conversation state and cabinet knowledge are different lifecycles.

Conversation history is scoped to its participants and authorization wall.
An attachment is conversation-only by default.
Persisting an attachment requires an explicit "Add to matter" action or an approved cabinet policy.
Before persistence, the attachment follows normal validation, classification, versioning, permission, and provenance rules.
Personal preferences and writing style remain separate from factual matter knowledge.
Hermès-native memory is a revocable execution projection, never the canonical conversation or cabinet record.

The product should make the attachment choice explicit:

Choice	Behavior
Use in this conversation	The attachment is available only to the authorized conversation and expires under its retention policy.
Add to matter	The attachment enters the governed ingestion path and becomes visible only after Cabinet Core accepts its canonical metadata and permissions.

Risk-Based Validation

Human validation is mandatory where risk requires it, not for every low-value extraction.

Operation	Default policy
Internal low-risk classification or tag	Accept automatically when policy allows; keep it reversible and auditable.
Ambiguous matter association	Queue for correction or validation by exception.
Extracted deadline, commitment, or important decision	Require confirmation by an authorized user before canonical promotion or downstream effect.
Internal generated brief	Save as a sourced draft with a visible validation status.
Modification of canonical context	Submit a typed proposal and apply the policy for that assertion class.
Client-facing content or external transmission	Require explicit human approval.
Irreversible or highly sensitive action	Require strengthened approval and the exact Action Gateway capability.

Example: Meeting Context

Canonical meeting and selected transcript version
  -> bounded extraction of decisions, actions, and deadlines
  -> assertions linked to exact transcript segments
  -> risk-based validation
  -> governed matter context
  -> reusable meeting brief, search result, task, or Hermès answer

The transcript remains a fallible source. Corrections create new immutable versions. An extracted decision remains proposed until the applicable policy accepts it. A generated meeting brief is a view, not a replacement for the transcript.

Example: Email Context

Canonical email, headers, thread metadata, and attachments
  -> deterministic deduplication and thread reconstruction
  -> proposed matter association
  -> bounded extraction of commitments or deadlines
  -> validation when association or meaning is ambiguous
  -> governed matter context

A thread can concern multiple matters. Quoted history, forwarded messages, aliases, shared inboxes, blind recipients, and conflicting permissions must prevent automatic attachment when the boundary is uncertain.

Security and Lifecycle Requirements

Apply authorization before search, ranking, and context construction.
Derived chunks, embeddings, assertions, summaries, caches, and memories inherit the most restrictive source authorization.
Permission revocation invalidates unused context packs and blocks acceptance of in-flight results.
Source deletion or retention expiry removes reconstructible projections and makes unsupported derived assertions unusable.
Legal hold and regulatory deletion remain Cabinet Core policy decisions.
Retrieved content is untrusted data and cannot alter system instructions or tool authority.
Audits record identifiers, versions, model and template references, digests, decisions, approvals, and receipts without exposing sensitive prompt or document content in logs.
Every result remains bound to the exact source snapshot and authorization used for that run.

Delivery Strategy

Build the context platform through consumer-backed vertical slices. Do not implement a universal graph, index, or service before a current feature proves its need.

Meeting context slice — selected transcript, sourced assertions, meeting brief draft, validation, and matter attachment.
Email and document ingestion — deduplication, proposed matter association, extraction, and correction queue.
Permissioned matter retrieval — multi-source context packs, contradictions, citations, and abstention.
Hermès read experience — persistent Mastrao conversation, governed attachments, and sourced answers.
Hermès actions — typed mutation proposals, risk-based approval, and Action Gateway effects.
API and MCP exposure — the same governed capabilities and policies for partners.

The first slice should prove the contracts needed by the next consumer. Shared abstractions are extracted when a second real use appears.

Decisions Required Before Broader Implementation

The following decisions require explicit architecture review or ADRs when a feature reaches them:

the assertion schema and validation policies by assertion class;
temporal semantics for observed, effective, superseded, and revoked knowledge;
deletion, retention, legal-hold, and derived-projection invalidation;
ownership and retention of Mastrao conversation history;
the contract for temporary versus matter-persisted attachments;
whether and when a dedicated graph datastore is justified by real multi-hop queries;
the boundary between Context Gateway retrieval, capability-specific context assembly, and model ranking;
the evidence stored for model execution without persisting sensitive prompts in logs.

Until those decisions are accepted, implementation must stay inside the current vertical slice and the existing Cabinet Core ownership boundary.

Current Implementation Status

The delivered Context Gateway is an intentionally narrow first slice: Hermès receives an authorized, bounded context pack derived from one exact document. H04 adds bounded parent/leaf orchestration over that supplied context but deliberately does not add multi-document retrieval, durable cabinet memory, MCP tools, or external effects.

This guide defines how future meeting, email, search, and conversation slices should extend the model. It does not claim those capabilities are implemented today.

The approved Mastrao PRD — product intent for the shared ingestion, graph, permissioned index, validation, audit, Hermès, and meeting capabilities.
.agents/rules/mastrao-architecture.md — accepted ownership, authorization, agent, effect, durability, and proof rules.
.agents/plan/hermes-authorized-context.md — delivered single-document authorized-context slice.
.agents/plan/hermes-bounded-parent-child-orchestration.md — delivered bounded H04 runtime orchestration and its explicit non-goals.
.agents/plan/context-c00-governed-context-research-and-architecture.md — internal C00 research, proposed decisions and the gate for the first consumer-backed Context slice.

Embedding Testimonials Mastra Integration Boundary