Inspect the system.
Question the claim.
Useful research makes its architecture, evidence, and limits legible. Start with the question each project addresses, then read what was tested and what remains outside that evidence.
01two connected questions
Where does context come from? Where may it go?
Systems architecture / theo ArcaA protected path around inference.
The TheoVex report describes a deployable model platform with inbound de-identification, eligibility-based routing, governed tools, scoped re-identification, and an evidence ledger. The subject is the system around the model, not a universal property of model output.
Read the architecture alongside the verification section. The report separates deterministic offline checks from live model-quality gates and does not publish a live results series.
read the architecture guideRelevant context, with a history.
MCIR means Memory Context & Intent Response, theo’s built-in memory layer. It captures and recalls relevant facts, preferences, decisions, and open questions across sessions, models, and connected applications within the same owner scope.
The public protocol describes an eight-stage memory lifecycle and a separate four-stage request path. Chain and scoring capabilities have their own rollout status; a roadmap entry is not evidence of universal availability.
explore the protocol02a distinction worth preserving
A memory lifecycle is not a request trace.
Memory lifecycle / eight stages
- 1Capture
- 2Classify
- 3Index
- 4Retrieve
- 5Validate
- 6Apply
- 7Expire
- 8Audit
Intent resolution → memory context assembly → context fusion → response generation.
Classification, skills, routing, tool execution, and response formatting are another view. Do not combine these descriptions into an invented single sequence.
03keep a claim attached to its scope
A small evidence note is better than a large promise.
Claim → evidence → open question
Claim under review: requests with no eligible serving target are refused on the described Arca protected path.
Relevant evidence: the public report's routing architecture and its distinction between offline gateway fixtures and live candidate evaluations.
Still to establish: the deployed build, active policy, eligible target set, tool scopes, and evidence for your own workload.
Architecture explains intent. Verification narrows the claim.
An architecture diagram describes a design. A test establishes behavior for its inputs, configuration, and assertions. Neither automatically establishes behavior in a different deployment or clinical setting.
The public browser workbench is a third category: a deterministic teaching example. It helps explain a branching workflow but does not run the production gateway or evaluate a live model.
04read in this order
From the primary source to your own questions.
Architecture, the protected path, offline and live verification modes, promotion gates, and limitations.
What deterministic checks establish, how negative cases help, and why offline results are not model-quality results.
Read the eight memory stages separately from the four request stages and the status of chain/scoring work.
Map model and tool recipients, permissions, logging, and the policies that govern an actual deployment.
Begin with a claim you can inspect.
Read how the evidence was produced before deciding what it means for your application.