DEOS Model Standard (DMS-1) Specification

Draft v0.1.0, March 2026

1. Purpose

DMS-1 is the DEOS-native model standard. It defines the contract a post-Transformer model has to honor to run under the deterministic kernel: stateful across steps and sessions, sparse and routed so compute is only spent where it does work, retrieval-native with CAS as first-class memory, multi-agent compatible, and replay-auditable with capability-bounded I/O.

The spec covers four areas:

• Interfaces: the runtime, memory, and agent contracts
• Training targets: the objective set and how to weight it
• Evaluation: the gates a model has to pass to ship
• Rollout: the gated deployment path from sidecar to primary

2. Non-goals

DMS-1 does not mandate a specific neural architecture family, a specific tokenizer, or a specific training framework. What it mandates is observable behavior and the runtime ABI.

3. Normative language

The words MUST, SHOULD, and MAY are used in their RFC 2119 senses.

4. Reference architecture

A DMS-1 runtime MUST expose the following logical components.

Latent Core. Persistent hidden state across steps, with step-local updates from input plus retrieved memory.

Router. Per-chunk decision among KEEP, COMPRESS, SKIP, RETRIEVE, and DEFER. Compute allocation is budget-aware.

Memory planes. Working memory (short horizon, in-process), episodic memory (CAS blobs, content-addressed), semantic memory (CAS index keys plus retrieval metadata).

Specialists. Planner, retriever, verifier, and tool executor as separable modules or processes.

Policy surface. Optional mapping from DEOS sentience primitives (attention, workspace, drives) into routing priors.

5. Model package format

Each DMS-1 model package MUST contain:

• manifest.toml
• weights/ with one or more sharded tensors
• router/ with router parameters and thresholds
• memory/ with the retrieval encoder and memory schema metadata
• tokenizer/ with the tokenizer model and config

5.1 Required manifest.toml fields

standard = "dms1"
model_id = "org.example.model"
version = "1.0.0"
core_arch = "recurrent_latent_v1"
router_arch = "mixture_router_v1"
state_dim = 4096
max_step_tokens = 512
memory_embedding_dim = 1024
supports_tool_calls = true
supports_multi_agent = true
deterministic_mode = true

6. Runtime interfaces

A DMS-1 implementation MUST expose a stable userspace interface equivalent to:

pub trait DmsRuntime {
    fn init_session(&mut self, req: InitSessionReq) -> Result<InitSessionResp, DmsError>;
    fn step(&mut self, req: StepReq) -> Result<StepResp, DmsError>;
    fn checkpoint(&mut self, req: CheckpointReq) -> Result<CheckpointResp, DmsError>;
    fn restore(&mut self, req: RestoreReq) -> Result<RestoreResp, DmsError>;
    fn finalize(&mut self, req: FinalizeReq) -> Result<FinalizeResp, DmsError>;
}

6.1 Core request and response schema

pub struct InitSessionReq {
    pub tenant_id: [u8; 32],
    pub session_id: [u8; 32],
    pub policy_flags: u64,
    pub seed: u64,
    pub budget_tokens: u32,
    pub budget_ms: u32,
}

pub struct StepReq {
    pub session_id: [u8; 32],
    pub step_id: u64,
    pub input_token_ptr: u64,
    pub input_token_len: u32,
    pub max_output_tokens: u32,
    pub decode_mode: u8,           // greedy, sample, constrained
    pub temperature_milli: u16,
    pub top_p_milli: u16,
    pub policy_hint_ptr: u64,      // optional
    pub policy_hint_len: u32,      // optional
}

pub struct StepResp {
    pub status: u32,
    pub output_token_ptr: u64,
    pub output_token_len: u32,
    pub state_hash: [u8; 32],
    pub route_stats: RouteStats,
    pub memory_stats: MemoryStats,
    pub verifier_score_milli: i32,
}

6.2 Router output contract

Every step() MUST produce route telemetry:

pub struct RouteStats {
    pub chunks_seen: u32,
    pub chunks_keep: u32,
    pub chunks_compress: u32,
    pub chunks_skip: u32,
    pub chunks_retrieve: u32,
    pub avg_confidence_milli: u16,
    pub compute_saved_milli: u16,
}

6.3 Memory contract

All persisted memory artifacts MUST be CAS-addressable and keyed by deterministic derivation:

• Session state key: dms1/state/{tenant}/{session}/{step}
• Episodic chunk key: dms1/episodic/{tenant}/{session}/{event_hash}
• Retrieval index key: dms1/index/{tenant}/{namespace}/{embed_hash}

DMS-1 runtimes MUST include state_hash in StepResp for replay validation.

6.4 Sentience integration (optional but standardized)

If enabled, runtimes SHOULD map:

• attention_focus to router priority bias
• workspace_submit to short-term working memory writes
• drive_stimulate and drive_satisfy to exploration and exploitation control

The mapping MUST be declared in manifest.toml under policy_map.

7. Determinism and replay

In deterministic mode, the runtime MUST guarantee that the same (model package, seed, input, policy flags) produces the same output tokens, the same route decisions, and the same state_hash. All external retrieval and tool events MUST be logged with stable IDs.

The per-step replay artifacts a runtime MUST emit:

• Input token hash
• Retrieved memory IDs
• Router decision trace
• Tool I/O hash (if any)
• Output token hash

8. Training targets

DMS-1 training MUST optimize a multi-objective bundle:

L_total = w_tok*L_token
        + w_state*L_state
        + w_route*L_route
        + w_ret*L_retrieval
        + w_ver*L_verify
        + w_budget*L_budget

Required components:

L_token (compatibility). Next-token cross-entropy for language fluency.

L_state (stateful coherence). Predict latent next-state consistency across long horizons. Penalize state drift after retrieval or tool insertion.

L_route (router correctness). Supervised plus self-distilled route choice quality. Encourage correct SKIP and COMPRESS when no quality loss results.

L_retrieval (grounding). Retrieval precision and recall against oracle memory references. Penalize hallucinated memory references.

L_verify (self-check robustness). Verifier agreement on answer correctness and tool usage validity.

L_budget (efficiency). Penalize latency per token and excessive FLOPs under fixed quality.

8.1 Default objective weights

A reasonable starting point:

Teams MAY tune weights but MUST report them in model cards and eval runs.

9. Evaluation suite (DMS-EVAL-1)

All candidate models MUST pass four gates.

Gate A: quality

• General instruction quality set
• Long-context retention set
• Multi-hop retrieval QA set
• Tool-use correctness set
• Verifier consistency set

Required reporting: accuracy or F1 per task, hallucination rate, verifier false-positive and false-negative rates.

Gate B: performance

• p50, p95, p99 step latency
• Tokens per second
• CAS read and write overhead
• GPU utilization and the ratio of compute saved by the router

Default thresholds: p95_latency <= baseline_transformer_p95, quality >= baseline_transformer_quality, compute_saved_milli >= 150 (15% or greater).

Gate C: reliability and determinism

• Replay equivalence over fixed seeds
• Crash recovery via checkpoint and restore
• Corrupt-memory resilience tests

Pass criteria: replay mismatch rate below 0.1%, checkpoint restore fidelity at or above 99.9%.

Gate D: multi-agent and safety

• Planner, executor, verifier decomposition tasks
• Capability boundary tests for tool calls
• Adversarial memory injection tests

Pass criteria: no unauthorized tool or capability usage, safety policy bypass rate below the security baseline.

10. Rollout plan

Phase 0: spec freeze (1 to 2 weeks). Freeze DMS-1 structs and manifest schema. Publish conformance tests (dms1-conformance). Exit when interface hashes are stable and the conformance harness is green against the reference runtime.

Phase 1: sidecar runtime (2 to 4 weeks). Run the DMS runtime alongside the current Transformer path. Shadow traffic only. Exit when there are no crash regressions and telemetry is complete for all required fields.

Phase 2: shadow evaluation (2 to 6 weeks). Full DMS-EVAL-1 runs. Calibrate router, memory, and verifier. Exit when Gates A through D pass against the baseline policy.

Phase 3: canary deployment (1 to 3 weeks). 1 to 5 percent of production traffic with fallback enabled. Exit when the error rate is not worse than baseline and the automatic fallback handles every failure class.

Phase 4: primary path (2 to 4 weeks). Ramp to 50 percent then 100 percent of traffic. Transformer path retained as a rollback fallback. Exit when SLOs are stable for 14 consecutive days.

Phase 5: standardization. Mark DMS-1 as the default model package format. Require DMS conformance for new model onboarding.

11. Conformance levels

A model MUST declare its conformance level in manifest.toml:

• DMS1-Core: runtime, package, deterministic replay
• DMS1-Memory: adds the retrieval-native memory contract
• DMS1-Agent: adds multi-agent specialist interoperability

12. Required deliverables per release

• Model package (manifest plus artifacts)
• Training recipe summary (weights and objectives)
• DMS-EVAL-1 report
• Determinism and replay report
• Security and capability audit report