The protected path
is the subject.
The TheoVex theo Arca report describes a deployable model platform that places policy, de-identification, routing eligibility, governed tools, and evidence around inference. The model is one component inside that boundary.
Read with this scopeA described Arca path.
Not every theo request.
01the system around the model
A node serves the request. A control plane manages its lifecycle.
The report calls the deployable serving unit an Arca Node. It contains the gateway, authentication and scoping, the protected inference path, tool execution controls, and an evidence ledger. It describes deployment on customer-controlled infrastructure, including restricted environments.
Arca Fleet is the control plane described for enrollment, licensing, usage aggregation, and the model registry. A versioned serving configuration moves through evaluation and promotion rather than becoming live merely because it can answer a request.
These are architecture descriptions from the cited report. Availability, infrastructure choices, licensed behavior, agreements, and the actual security boundary need confirmation for a particular deployment.
02an annotated architecture
No eligible path means no inference.
Within the described Arca serving boundary
Validate the caller, purpose, and permitted operations. Unknown credentials and insufficient scopes do not acquire authority from a prompt.
Apply the inbound policy and replace detected sensitive values before inference. The report describes a tenant-scoped encrypted vault for token mappings.
Use the more sensitive of the declared and detected data classes to determine eligible serving targets. Do not route to an ineligible target simply to obtain an answer.
Check typed arguments, required scopes, and permitted data classes. Tool input and output re-enter the protected path; the described code-execution pack excludes PHI-classed traffic.
Re-identification requires an explicit caller scope. The outbound path applies the report's served-identity policy rather than treating generation as the final boundary.
The described ledger records action metadata and content digests. Logging is part of the boundary, not an excuse to copy sensitive content into another system.
Stop condition: no eligible serving target, missing tool authority, or a disallowed data class must not turn into a silent fallback that bypasses the boundary.
03a synthetic eligibility specimen
A tool can be valid and still be ineligible.
Well-formed request. Wrong boundary.
Input: a synthetic request is classed as PHI. No personal data is present in this example.
Proposed action: invoke a code-execution tool whose permitted classes exclude PHI.
Required outcome: refuse that action. Valid JSON arguments and a useful task description do not make the tool eligible.
Human next step: review the purpose and configuration. Do not weaken the class or route around the check just to get output.
“Fail closed” is about the action, not the wording.
A refusal is meaningful only if the prohibited inference or tool call did not already happen. Evaluate the boundary that dispatches the action, including the handling of errors and alternative paths.
The same distinction applies to the response: a scoped re-identification rule is different from a request to a model to hide sensitive details. Examine where the permission is checked and which data is available at each stage.
read the negative-fixture example04do not merge the contracts
Arca protection and gateway Guardrails are not synonyms.
- Arca report
- Describes a particular deployable protected path, data-class eligibility, scoped tool use, a vault, and evidence. Review that deployment and its verification artifacts before relying on those properties.
- Gateway Guardrails
- Are explicitly opt-in and bound per API key. An unbound key has no gateway policy enforcement. A detector's configured verdict and phase determine its behavior; a policy name is not a general privacy guarantee.
- Streaming output
- The gateway documentation says raw tokens can stream before output evaluation, with the guarded result in the final event. Do not infer Arca's described outbound architecture from that separate gateway contract.
- Your application
- Owns end-user permissions, context selection, tool recipients, display behavior, and human review. An architecture paper does not implement those controls in your product.
05what remains to establish
Take the architecture to a deployment review.
- 01
Read the verification mode
The report describes deterministic offline gateway checks and separate live candidate gates. Published offline results are not live model-quality results, and the report does not publish a live results series. - 02
Inspect the actual build
Confirm the serving configuration, eligible target set, detector and policy behavior, tool scope, and evidence attached to the version you intend to deploy. - 03
Review data handling and agreements
Identify recipients, vault and logging boundaries, operational access, and the agreements required for your use. Confirm the deployment-specific responsibilities with the appropriate reviewers. - 04
Retain domain and human review
Curated probes and structural checks are finite. They do not establish clinical accuracy, coverage correctness, complete security, or suitability for every workload.
Read the evidence before choosing the boundary.
Use the primary report and deployment review to establish what applies to your actual workload. Keep sensitive records out of public demos.