Theo Arca 5.1: A Compliance-Gated Model Platform

Design principles

The request path

The life of a request

1

Authentication and metering (Tessera)

The bearer key is validated fail-closed, scopes are checked, rate limits and daily token quotas are enforced, and a request ID is assigned. Idempotency keys make retries safe.

2

Inbound guardrail (Praetorian Guard)

The request is classified by data sensitivity, PHI and PII entities are detected, and detected values are replaced with format-preserving tokens written to an encrypted, per-tenant, time-bounded vault. Only de-identified text proceeds.

3

Injection screening

Prompt-injection patterns are screened before the request reaches a backend. A positive screen is refused as a policy block.

4

Policy-routed backend selection

The effective data class, the more sensitive of what the caller declared and what the guardrail detected, determines which backends are eligible. Routing is fail-closed: no eligible backend means no inference.

5

Inference and the tool loop

The selected tier's serving profile executes the request. Tool calls are dispatched through the same guardrail in both directions, folded back into context, and continued up to a bounded number of steps.

6

Outbound guardrail

Tokens are re-identified only for callers holding the explicit re-identification scope. A final identity scrub enforces the served-identity policy on every response, streaming or not.

7

Evidence and telemetry

A hash-chained audit record (request ID, action trail, model, backend kind, data class, content digests) is appended to the Evidence Ledger, and PHI-safe usage metrics are recorded.

The provider contract

• Base URL https://api.theovex.com/v1 with bearer authentication. There is intentionally no proprietary SDK.
• Public model IDs (arca-velox-5.1, arca-magnus-5.1, arca-edge-5.1, arca-code-5.1, alias arca-5.1). Responses always echo the public ID, never an internal served-model name.
• The OpenAI chat-completions wire shape, SSE framing with a terminal [DONE], and one error envelope everywhere.
• A cold-start signal: 503 with Retry-After and code warming while a scaled-to-zero pool wakes.

Everything else (weights, serving engine, GPU topology, guardrail internals, personas, tool packs, registry versions, adapters) is invisible and free to change. A contract guard test enforces the machine-checkable parts of this promise in CI, so breaking the surface requires deliberately failing a test.

Agentic tools and MCP

Tools are typed, centrally registered functions with JSON-Schema parameters, each declaring required scopes and permitted data classes. Three domain packs ship with the platform, and the same governed tools are exposed over MCP (JSON-RPC 2.0) with identical scope enforcement.

Tiers are configurations

Because the public contract is the tier ID and not the weights, we can improve any layer (swap weights, change quantization, attach a fine-tuned adapter, replace the serving engine) and ship it as an atomic, reversible pointer update, provided the candidate passes the benchmark gates.

Registry and lifecycle

Every candidate build is an immutable registry entry: ID, family, tier, version, weight digest, engine, precision, configuration hash, optional adapter reference, and its eval scorecard. Entries move through a strict lifecycle.

The harness

The harness is intentionally minimal. A suite is a named set of cases with a pass-rate threshold. A case is a single pass/fail assertion with an explanatory detail on failure. A suite passes when its pass rate meets its threshold, and the scorecard passes only when every suite passes. The eval CLI exits non-zero on any failure, which is what makes it a CI gate.

{
  "passed": true,
  "suites": {
    "safety":      { "passed": true, "score": 1.0 },
    "capability":  { "passed": true, "score": 1.0 },
    "identity":    { "passed": true, "score": 1.0 },
    "coding":      { "passed": true, "score": 1.0 },
    "longcontext": { "passed": true, "score": 1.0 },
    "parity":      { "passed": true, "score": 1.0 },
    "ops":         { "passed": true, "score": 1.0 }
  },
  "ranAt": 1783000000000
}

The seven suites

From scorecard to promotion

01A candidate build (weights plus tier profile plus optional adapter) is registered, entering the lifecycle at building.
02The eval CLI runs the seven suites, offline suites always and live batteries against the deployed candidate, and emits the scorecard.
03The scorecard is posted to the registry entry, moving it to evaluated, then staged when thresholds are met.
04A promotion request without a passing scorecard is refused with a 409. With one, the build promotes through a blue-green and canary rollout to live, with the previous version retained as an atomic rollback pointer.
05In CI, the same harness runs on every change and exits non-zero on failure, so a change that breaks a pipeline guarantee never reaches a promotable build.

What we deliberately do not do

• We do not publish public-leaderboard numbers: aggregate scores say little about whether this build will keep PHI out of your logs.
• We do not report offline results as model quality.
• We do not average safety failures away under a soft threshold.
• We do not grade the model in isolation from the pipeline it ships inside.

The de-identification vault

• Per-tenant data-encryption keys, wrapped by a KMS, with TTL-bound entries.
• Tokens are namespaced per request and tenant to prevent cross-request or cross-tenant correlation.
• Detokenization requires scope, and every vault access is itself an Evidence Ledger event.
• Raw PHI never exists outside the vault's encryption boundary, not in logs, traces, metrics, or training data.

Fail-closed routing by data class

Every request carries an effective data class, the more sensitive of the caller's declaration and the guardrail's own classification, so declaring down does not work. Backends declare which classes they are certified to receive, and the router refuses rather than degrades. The code-execution pack accepts only non-PHI classes, so no prompt-engineering path can move PHI into a sandbox.

What gates a live promotion

Model-quality claims come from the live batteries: the same identity, coding, long-context, parity, and ops probes aimed at a deployed build, whose scorecard is recorded on the registry entry it grades. Those scorecards are operational gate artifacts, produced per candidate and per deployment. We do not publish live numbers in this report, and any future publication will state the exact build, date, probe set, and mode of each figure.

Error envelope

One error envelope everywhere, including mid-stream: { error: { message, type, code, request_id } }. Cold starts signal 503 plus Retry-After with code warming. Streams use an idle timeout between chunks, never a total-duration cap.

Optional request headers

• x-arca-data-classpublic | internal | pii | phi | secret | source_code
• x-arca-purposetreatment | payment | operations | underwriting | claims | engineering | research, recorded for HIPAA-style purpose-of-use auditing.