System architecture / 03
Eleven modules. One governed request lifecycle.
The modules separate planning, evidence, privacy, memory, execution and evaluation so each responsibility has an owner, a contract and a promotion gate. The runtime composes only the set required for the request.
Request lifecycle
A request moves through responsibilities, not a compulsory chain of eleven steps.
Routing rule: a simple request may bypass several capabilities. Modularity is useful only if unused parts can stay out of the path.
↳
Connected responsibilities
A source is not a memory. A search result is not a durable fact.
Each handoff keeps the authorized owner and evidence reference. CLI, MCP and authenticated HTTP compose these contracts; a public demo never grants access to private sources.
Ingestion → Search
Ingestion validates and normalizes the source. Persistence commits its records; Search owns the source catalogue, index and bounded evidence lookup. Replacing a source must not leave old trailing chunks searchable.
Source admissionSource evidence → Memory review
After persistence, the runtime can return a content-free review handoff, including after deferred recovery. Memory derives candidates; a separate, explicit promotion validates the current evidence. Ingestion never promotes automatically.
Reviewed memoryMemory + Search → Cognitive Engine
Memory supplies approved context; Search supplies relevant sources. The Cognitive Engine owns the explicit four-layer context plan and its total budget. Calling that plan is separate from running an ordinary answer request.
Context compositionSource lifecycle → Persistence
Replacement, deletion and vector refresh share source identity rules. Retained references block destructive changes; a changed snapshot invalidates a pending vector refresh. Coordination keeps task and event state separate from Memory.
Evidence lifecyclePublication boundary: Firebase hosts this public site and its illustrative demonstrator, not the authenticated Rust API or a customer database. Read the integration contract.
01
DECIDE WHAT A GOOD ANSWER REQUIRES
Plan and check
These modules turn a request into visible obligations, choose a bounded route and check the result before publication.
Plan the smallest sufficient pathControlled pilot
Cognitive Engine
- Its job
- Chooses the smallest route that can do the job.
- Why it matters
- Avoids a fixed, expensive pipeline and makes escalation or refusal a deliberate decision.
Know what a complete answer must containImplemented
Question Contract Compiler
- Its job
- Writes down what a complete answer must contain.
- Why it matters
- Makes missing parts, wrong shapes and false completeness easier to detect.
Connect every published claim to admissible evidenceImplemented
Answer Assurance
- Its job
- Checks coverage and support before an answer is released.
- Why it matters
- Connects important statements to evidence and targets repair at the actual gap.
02
BRING THE RIGHT KNOWLEDGE SAFELY
Evidence, privacy and context
These modules bring private, stored, external and multimodal information into the route without treating every source as equally trusted.
Reason over aliases, not exposed identitiesImplemented
Confidentiality Boundary
- Its job
- Keeps sensitive values inside an approved boundary.
- Why it matters
- Lets a system reason with scoped aliases and restore exact values only for the authorized caller.
Retrieve structure, not just similar textControlled pilot
Document Retrieval
- Its job
- Finds a bounded packet of relevant private evidence.
- Why it matters
- Keeps source identity and scope attached as information moves from documents into an answer.
Production-qualified fresh evidence under an explicit egress budgetCanary
External Research
- Its job
- Looks for fresh public evidence when stored knowledge is not enough.
- Why it matters
- Makes web access a named, budgeted and traceable decision rather than a hidden side effect.
Continuity without hidden accumulationControlled pilot
Governed Memory
- Its job
- Keeps useful context under retention and deletion rules.
- Why it matters
- Separates durable product memory from the accidental history inside one model conversation.
Preserve meaning across documents and mediaControlled pilot
Multimodal Ingestion
- Its job
- Turns supported files and media into governed records.
- Why it matters
- Creates one controlled entry path for text, documents, images and audio while keeping format limits visible.
03
CONNECT MODELS AND DEPLOYMENTS
Execution without lock-in
These modules keep model access and deployment choices behind explicit contracts.
Models are capabilities — never hidden dependenciesControlled pilot
Inference Gateway
- Its job
- Connects the plan to an approved model endpoint.
- Why it matters
- Keeps provider credentials, transport behavior and model choice out of the rest of the product.
Useful cognition when the network disappearsCanary
Edge & OEM Runtime
- Its job
- Runs governed capabilities closer to a device or private environment.
- Why it matters
- Supports local and disconnected directions without pretending that every hardware profile is already qualified.
04
PROVE THAT A CHANGE DESERVES RELEASE
Evaluation and promotion
This module turns tests, failures and release gates into a visible product discipline.
Promotion is earned, not announcedImplemented
Evaluation & Release Kit
- Its job
- Checks a candidate change against frozen cases and release rules.
- Why it matters
- Helps a team reject regressions and keep a narrow result from becoming a broad public claim.
05
Where to start
Begin with the responsibility that creates the most risk or friction.
Mentaview does not require a company-wide migration to begin an evaluation. The right entry point depends on the workload and the boundary you need to prove.
Start with Question Contract and Answer Assurance.
Start with Confidentiality Boundary and Inference Gateway.
Start with Document Retrieval and the evidence contract.
Start with the Cognitive Engine and explicit budgets.
Technical records
Architecture, evidence and limits stay attached to each module.
Every module record includes its problem statement, workflow, use cases, system boundary, evidence status and next promotion gate.