Deterministic TinyRustLM Context Compiler: Authority, Provenance, Memory, and Exact Token Assembly

Full report

On this page

Executive recommendation and public scope

Executive summary

[Recommendation] TinyRustLM should replace all ad hoc prompt assembly with one normative, deterministic context compiler. The compiler should consume typed, provenance-bearing records; resolve conversational authority before retrieval; construct a machine-readable ContextPlan; render that plan through a model-specific template; tokenize the result; and identify the exact prompt by hashing its token sequence together with the active model, tokenizer, template, and policy identities.

The decisive architectural rules are:

1. Authority and relevance are separate dimensions. Semantic similarity can make a record eligible for inclusion, but it must never transform retrieved text, memory, a tool payload, or quoted material into an instruction.
2. The current explicit user request has protected retention and precedence. Stale profile fields, inferred preferences, generated summaries, and retrieved documents cannot override it or displace its material constraints from the context budget.
3. Every included assertion remains bound to its source. A summary, extraction, or memory record is a derived artifact, not a replacement for its sources.
4. Durability is explicit. Raw chat, temporary task state, inferred preferences, model KV state, embeddings, and durable memory are different objects with separate retention policies.
5. The plan is compiled before text is rendered. Selection, authority, ordering, token allowance, truncation, exclusions, and conflicts must be inspectable without exposing prompt payloads.
6. The final identity is token-level. A text hash alone is insufficient because different tokenizers, chat templates, special-token maps, or rendering code can produce different model inputs from superficially identical text.
7. Hosted continuity fails closed. A new browser may restore only server-derived state obtained through an advertised, authorized contract. It must not infer routes, tenant identifiers, workspace bindings, or credentials.
8. There is one clean cutover. After the deterministic compiler passes differential, adversarial, overflow, reconnect, and deletion tests, the legacy prompt-construction path and unpublished compatibility aliases should be removed rather than maintained.

The supplied specification establishes the fixed product constraints, required record types, authority behavior, security posture, synchronization requirements, test scope, and prohibition on legacy compatibility shims.

Scope, assumptions, and evidence labels

[Assumption] This report covers the browser-side compiler, local persistence boundary, optional hosted continuity adapter, retrieval pipeline, summaries, cache binding, diagnostics, and test strategy. It does not claim access to private TinyRustLM source code, prompts, model files, tokenizer assets, memory records, credentials, build systems, or test results.

[Assumption] No geographic restriction applies. Public observations were made on August 1, 2026, with source dates and immutable revisions recorded where exposed.

The following labels distinguish evidence classes:

Public observation log

Unavailable-contract ledger

[Recommendation] These are blockers to claiming implementation conformance, not blockers to defining the normative compiler contract.

Authority, typed records, and provenance

Authority lattice

An ordinary linear role hierarchy is too weak because a source can be authoritative for one purpose but untrusted for another. A weather tool, for example, may be trusted for returned weather fields but has no authority to change product policy. The compiler should therefore use a lattice with at least three independent axes:

\[ A(r) = \langle I_r, F_r, S_r \rangle \]

where:

• \(I_r\) is instruction authority;
• \(F_r\) is factual authority within a declared scope;
• \(S_r\) is state authority, meaning the ability to update session or durable state.

[External] Instruction-hierarchy research identifies failure to distinguish privileged from lower-priority instructions as a major cause of prompt-injection vulnerability. Training a model to recognize privilege improves robustness, but the application still needs an explicit source hierarchy and structural separation.

The normative instruction ordering should be:

The tier alone must not be interpreted as a universal truth score. A current user can authoritatively state “Use metric units” but cannot make an outdated third-party scientific claim become correct merely by repeating it. Conversely, an official data source can be authoritative for a statistic while remaining unable to issue instructions to the assistant.

Non-combinable authorities

[Recommendation] The compiler must reject attempts to combine the following into a stronger synthetic authority:

• Retrieved prose plus a system-looking prefix does not become a system instruction.
• A tool result plus a phrase such as “execute immediately” does not gain action authority.
• A generated summary plus a durable-memory location does not become a verified fact.
• A profile record plus age does not override a current explicit preference.
• Multiple low-authority duplicates do not collectively outrank one higher-authority correction.
• A signed or hashed document proves content identity, not truth or instruction privilege.
• A high vector score does not alter instruction, fact, or state authority.
• A hosted workspace identifier appearing in content does not establish tenant binding; only trusted, server-derived metadata may do so.

Conflict-resolution table

Canonical record model

#[derive(Clone, Debug, Serialize, Deserialize)]
pub enum RecordKind {
    RoleTaggedMessage,
    UserPreferenceAssertion,
    Retraction,
    SessionFact,
    SourceClaim,
    TrustedMetadata,
    UntrustedContentBlock,
    ToolResult,
    ShortTermSummary,
    LongTermMemoryRecord,
    MemoryPointer,
    Tombstone,
    SupersessionLink,
    RetrievalHit,
    CompilerDiagnostic,

    // Recommended additions needed to make lifecycle explicit.
    ConsentGrant,
    ConsentWithdrawal,
    ConflictRecord,
    OutboxOperation,
    SyncReceipt,
}

#[derive(Clone, Debug, Serialize, Deserialize)]
pub struct CanonicalRecord {
    pub schema_version: String,
    pub kind: RecordKind,
    pub payload_encoding: PayloadEncoding,
    pub payload_bytes: Vec<u8>,
    pub provenance: ProvenanceEnvelope,
    pub lifecycle: LifecycleEnvelope,
    pub authority: AuthorityEnvelope,
}

The minimum semantic requirements are:

Content identity and provenance envelope

[External] W3C PROV models provenance through entities, activities, agents, derivations, responsibility, and collections. That structure is appropriate for distinguishing a source record from the activity that summarized, retrieved, reviewed, or transformed it.

[External] RFC 8785 defines a deterministic JSON representation suitable for repeatable hashing, while explicitly requiring JSON strings to be preserved rather than silently Unicode-normalized. This supports canonical metadata hashing but argues against rewriting source payloads during canonicalization.

#[derive(Clone, Debug, Serialize, Deserialize)]
pub struct ProvenanceEnvelope {
    pub record_id: String,
    pub source_uri_hash: Option<String>,
    pub source_record_id: Option<String>,
    pub creator_class: CreatorClass,
    pub creator_id_hash: Option<String>,

    pub created_at: Timestamp,
    pub observed_at: Option<Timestamp>,
    pub valid_from: Option<Timestamp>,
    pub valid_until: Option<Timestamp>,

    pub revision: String,
    pub supersedes: Vec<String>,
    pub derived_from: Vec<String>,

    pub trust_class: TrustClass,
    pub tenant_binding_hash: Option<String>,
    pub agent_binding_hash: Option<String>,

    pub sensitivity: SensitivityClass,
    pub retention: RetentionClass,
    pub expires_at: Option<Timestamp>,

    pub original_hash: String,
    pub normalization_hash: String,
    pub metadata_hash: String,

    pub untrusted_data: bool,
    pub policy_version: String,
}

[Recommendation] Compute identities using explicit domain separation:

\[ H_{\text{payload}} = \operatorname{SHA256}( \texttt{"trlm-payload-v1\0"} \parallel \text{original bytes} ) \]

\[ H_{\text{metadata}} = \operatorname{SHA256}( \texttt{"trlm-meta-v1\0"} \parallel \operatorname{JCS}(\text{canonical metadata}) ) \]

\[ ID_{\text{record}} = \operatorname{SHA256}( \texttt{"trlm-record-v1\0"} \parallel \text{kind} \parallel H_{\text{payload}} \parallel H_{\text{metadata}} ) \]

original_hash identifies received bytes. normalization_hash identifies the exact result of an explicitly documented decoding or sanitation transform. metadata_hash covers canonical metadata. Search-oriented Unicode normalization, stemming, chunking, or whitespace folding must produce separate index artifacts; it must not mutate the archival payload or its original identity.

[Recommendation] All hash inputs must include length prefixes or canonical structured encoding, never ambiguous string concatenation. Timestamps should be fixed-format UTC strings, integer-like values that exceed safe JSON numeric precision should be strings, duplicate JSON keys should be rejected, and non-finite numbers should be forbidden, consistent with JCS constraints.

Deterministic planning, compilation, and budgeting

Context-plan contract

The compiler should never directly concatenate records into a prompt. It should first produce a deterministic plan:

#[derive(Clone, Debug, Serialize, Deserialize)]
pub struct ContextPlan {
    pub plan_schema: String,
    pub compiler_version: String,

    pub policy_id: String,
    pub policy_hash: String,

    pub model_id: String,
    pub model_artifact_hash: String,
    pub model_config_hash: String,

    pub tokenizer_id: String,
    pub tokenizer_hash: String,
    pub special_token_map_hash: String,

    pub rendering_template_id: String,
    pub rendering_template_hash: String,

    pub context_window_tokens: u32,
    pub output_reservation_tokens: u32,
    pub safety_margin_tokens: u32,

    pub selected: Vec<PlannedRecord>,
    pub excluded: Vec<ExcludedRecord>,
    pub conflicts: Vec<ConflictRecordRef>,

    pub retrieval_index_id: Option<String>,
    pub retrieval_index_revision: Option<String>,
    pub stale_index: bool,

    pub canonical_plan_hash: String,
}

#[derive(Clone, Debug, Serialize, Deserialize)]
pub struct PlannedRecord {
    pub record_id: String,
    pub record_hash: String,
    pub record_kind: RecordKind,

    pub instruction_authority: String,
    pub factual_authority: String,
    pub state_authority: String,

    pub order_key: String,
    pub token_allowance: u32,
    pub truncation_mode: TruncationMode,
    pub rendering_template: String,

    pub inclusion_reason_code: String,
    pub source_lineage_hash: String,
}

The plan hash should be calculated over a JCS-canonical plan object that excludes nondeterministic telemetry such as elapsed time, memory address, thread ID, and wall-clock completion time. Canonical JSON is designed to make hashing repeatable across implementations.

The plan is not yet the prompt identity. After rendering and tokenization:

\[ H_{\text{tokens}} = \operatorname{SHA256}\left( \texttt{"trlm-prompt-tokens-v1\0"} \parallel H_M \parallel H_T \parallel H_{\text{template}} \parallel H_{\text{policy}} \parallel \operatorname{encode\_u32le}(\text{token IDs}) \right) \]

where \(H_M\) is the exact model composition identity and \(H_T\) is the complete tokenizer identity.

Compilation algorithm

flowchart TD
    A[Ingest typed records] --> B[Validate schema and provenance]
    B --> C[Normalize metadata only]
    C --> D[Resolve current-turn authority]
    D --> E[Apply tombstones, retractions, supersession]
    E --> F[Detect claim and instruction conflicts]
    F --> G[Generate retrieval query from trusted task state]
    G --> H[Retrieve candidates]
    H --> I[Apply tenant, agent, ACL, sensitivity, status, expiry filters]
    I --> J[Exact and semantic deduplication]
    J --> K[Rank relevance without changing authority]
    K --> L[Allocate deterministic token budget]
    L --> M{Summary permitted and necessary?}
    M -- Yes --> N[Generate or select lineage-bound summary]
    M -- No --> O[Use source records directly]
    N --> P[Build canonical ContextPlan]
    O --> P
    P --> Q[Render typed, escaped boundaries]
    Q --> R[Apply exact model chat template]
    R --> S[Tokenize]
    S --> T{Within input budget?}
    T -- No --> L
    T -- Yes --> U[Hash exact token IDs]
    U --> V[Emit privacy-safe receipt]

A normative pseudocode sequence is:

compile(inputs, policy, model_bundle):
    records = validate_and_decode(inputs)
    canonical_meta = normalize_metadata(records)
    active = resolve_authority(canonical_meta, current_turn)
    active = apply_tombstones_retractions_supersession(active)
    conflicts = detect_conflicts(active)

    query = build_retrieval_query(current_turn, agreed_state)
    candidates = retrieve(query, pinned_index_revision)

    candidates = hard_filter(
        candidates,
        tenant_binding,
        agent_binding,
        ACL,
        sensitivity_policy,
        expiration,
        record_status
    )

    candidates = dedupe(candidates)
    ranked = rank_relevance(candidates)       // never rewrites authority
    budgeted = allocate(active, ranked, token_budget)

    derived = summarize_only_if_allowed(budgeted, summary_policy)
    plan = make_context_plan(active, derived, conflicts, exclusions)

    plan_hash = hash(canonicalize(plan))
    rendered = render_typed(plan)
    prompt_text = model_chat_template(rendered)
    token_ids = exact_tokenizer(prompt_text)

    if token_ids exceed input allowance:
        deterministically revise the plan or stop with overflow

    token_hash = hash(model_bundle_identity || token_ids)
    return plan, token_ids, redacted_receipt

Token-budget equations

Let:

• \(C\): model context-window limit;
• \(O\): reserved output tokens;
• \(M\): safety margin for template/version variance;
• \(I\): maximum input tokens;
• \(S\): system and product-policy tokens;
• \(T\): chat-template and typed-boundary overhead;
• \(U\): complete current-user message;
• \(K\): required markers and current tool-state tokens;
• \(D\): recent dialogue;
• \(G\): agreed session state;
• \(P\): confirmed profile and durable preference;
• \(R\): retrieval and memory;
• \(Q\): summary artifacts.

Then:

\[ I = C - O - M \]

\[ B_{\text{discretionary}} = I - (S + T + U + K) \]

and the compiler must satisfy:

\[ D + G + P + R + Q \le B_{\text{discretionary}} \]

A compilation must fail before inference if:

\[ S + T + U + K > I \]

unless a user-visible continuation or chunk-processing protocol has been explicitly selected.

[Recommendation] O must be reserved before selecting optional context. A local model should not consume its entire window with history and then silently reduce the requested answer length.

Non-negotiable retention order

[Recommendation] Tie-breaking must be stable. Within the same authority and retention class, use:

1. mandatory status;
2. direct relevance to current request;
3. explicit user pin;
4. validity and recency;
5. source reliability;
6. source diversity;
7. stable record_hash ascending.

Do not use unordered map iteration, database default ordering, locale-dependent sorting, floating-point scores without quantization, or arrival timing.

Current-turn overflow

If the current turn alone exceeds the available input budget, the compiler must not pretend the entire turn was read.

The required behavior is:

1. Emit CURRENT_TURN_OVERFLOW.
2. Preserve the unmodified full message in ephemeral local input state, subject to user-controlled retention.
3. Present the user with a visible continuation or deterministic chunk-processing mode.
4. Bind every chunk to the original message hash, total byte length, chunk index, and chunking-policy hash.
5. Do not produce a final answer requiring full-message comprehension until all required chunks have been processed.
6. Never discard the middle of the current message while retaining old memory or retrieval.

For a locally executed transformation such as rewriting a long document, chunk boundaries should be syntactic where possible, but the original byte spans and overlap policy must be recorded. For instructions whose meaning depends on the entire text, the compiler should stop rather than infer from a prefix and suffix.

Truncation-strategy comparison

[External] Long-context models often perform better when relevant information is near the beginning or end and worse when it appears in the middle; this supports explicit ordering and retrieval rather than assuming a large context window is uniformly usable.

Memory semantics, retrieval, and contradiction handling

Summary lineage

A summary must be represented as a derived record, not replacement prose:

pub struct SummaryLineage {
    pub summary_record_id: String,
    pub source_record_ids: Vec<String>,
    pub source_record_hashes: Vec<String>,

    pub summarizer_model_id: String,
    pub summarizer_model_hash: String,
    pub tokenizer_hash: String,
    pub template_hash: String,
    pub prompt_policy_hash: String,

    pub generated_at: Timestamp,
    pub scope: String,
    pub declared_omissions: Vec<String>,
    pub confidence_basis: String,

    pub output_hash: String,
    pub reviewer_status: ReviewerStatus,
    pub reviewer_id_hash: Option<String>,

    pub supersedes_summary_ids: Vec<String>,
}

[Recommendation] The default authority of a generated summary is A6: model-generated, untrusted memory. Human review does not make every summarized claim true; it only changes the review status. User confirmation may promote specific atomic assertions into confirmed preference or memory records, but should not promote an entire free-form summary wholesale.

A summary can be selected only when:

\[ \text{summary savings}

\text{summary overhead} + \text{required lineage markers} \]

and when the policy permits summary generation for the relevant sensitivity class.

A summary must be invalidated or marked stale when any bound source is tombstoned, materially superseded, corrected, or inaccessible under the current authorization boundary.

Supersession, retraction, and tombstones

These mechanisms should have distinct meanings:

An append-only event history improves traceability, but immutable event stores create privacy complications when personal data must be deleted. Microsoft’s event-sourcing guidance highlights both append-only auditability and the complexity and retention tradeoffs of the pattern.

[Recommendation] Therefore, TinyRustLM should event-source control and lineage metadata, not indiscriminately copy sensitive conversation payloads into an immutable ledger. Sensitive payloads should live in separately deletable encrypted objects referenced by content identity. Deleting the object and its encryption key can preserve a non-sensitive tombstone while making the payload unrecoverable.

Retrieval eligibility and scoring

Retrieval should use two stages.

First, a hard eligibility function:

\[ E(r)= \operatorname{tenant\_ok}(r) \land \operatorname{agent\_ok}(r) \land \operatorname{acl\_ok}(r) \land \operatorname{sensitivity\_ok}(r) \land \neg\operatorname{tombstoned}(r) \land \neg\operatorname{expired}(r) \land \operatorname{status\_selectable}(r) \]

A record with \(E(r)=0\) is not ranked at all.

Second, a relevance score:

\[ \begin{aligned} R(r,q) ={}& 0.40\,S_{\text{semantic}} +0.15\,S_{\text{lexical}} +0.15\,S_{\text{recency}}\\ &+0.10\,S_{\text{source-quality}} +0.10\,S_{\text{explicit-pin}} +0.10\,S_{\text{record-status}} \end{aligned} \]

Weights should be policy-versioned and represented as exact integers or fixed-point values, for example basis points, to avoid platform-dependent floating-point ties.

[Recommendation] Instruction authority is not an input to this relevance formula. It remains a separate immutable property of the record.

For hybrid lexical/vector retrieval, Reciprocal Rank Fusion can combine independently generated rankings without pretending their raw scores share a common scale. The original RRF work evaluated fusion across TREC runs and LETOR data.

\[ RRF(r) = \sum_{j=1}^{m}\frac{1}{k+\operatorname{rank}_j(r)} \]

After fusion, apply deterministic diversity selection, such as maximal marginal relevance with fixed-point scores, and break remaining ties by record_hash.

Contradiction policy

Every atomic claim should have a claim key:

\[ K_c = \langle \text{subject}, \text{predicate}, \text{scope}, \text{valid-time interval} \rangle \]

Claims conflict only when their keys overlap and their normalized values cannot both be true within the same validity interval. Mere textual difference is not a contradiction.

The compiler should produce typed conflict codes such as:

PREFERENCE_STALE_PROFILE
CURRENT_USER_CORRECTION
AUTHORITATIVE_DATE_DIVERGENCE
SUMMARY_SOURCE_DIVERGENCE
DUPLICATE_EQUIVALENT
SUPERSEDED_PLAN
UNCERTAIN_RETRIEVAL
UNTRUSTED_EMBEDDED_INSTRUCTION
TENANT_BINDING_MISMATCH
TOMBSTONED_RECORD_SELECTED

Proceed without asking when a clear authority or temporal rule resolves the conflict and the consequence is reversible. Disclose the conflict when two credible sources support materially different conclusions. Ask or stop when no authority rule resolves a decision-critical ambiguity, when an irreversible action is contemplated, or when resolving the issue requires unavailable authorization.

Memory-write policy

The public MemoryEndpoints material distinguishes local startup memory from protected hosted continuity and states that hosted memory should not silently replace local continuity.

[Recommendation] Memory consent should be field-specific, purpose-specific, and duration-specific. “Remember this” is not blanket consent to retain the full surrounding conversation.

A cleanup proof should contain:

• deletion request hash;
• affected record hashes;
• stores and index revisions processed;
• cache namespaces invalidated;
• completion or partial-failure status;
• timestamp and policy version;
• bounded error codes.

It must not reproduce deleted content.

Startup, reconnect, and synchronization

Deterministic startup package

The startup package should be assembled in this exact order:

The startup package must itself have a canonical hash and include a deterministic source list. It should not contain every durable record; it should contain selected profile fields, pointers, status, and conflict notices sufficient to compile the first turn.

Advertised hosted-contract requirements

[Observed] The MemoryEndpoints contract advertises a discovery route, explicit activation requirements, canonical agent-name normalization, authenticated runtime leases, fail-closed lease conflicts, exact workspace/agent scoping, idempotency headers for mutations, and server-side redaction of raw credential material.

[Recommendation] A TinyRustLM hosted-memory adapter should require these contract fields before enabling continuity:

contractRevision
deploymentRevision
issuer
discoveryRoute
supportedSchemaVersions
authenticationScheme
activationFlow
approvedScopes
serverDerivedAgentBinding
serverDerivedTenantOrWorkspaceBinding
runtimeLeaseContract
idempotencyRules
retryRules
cursorAndRevisionSemantics
searchRequestSchema
memoryWriteSchema
tombstoneOrDeletionCapability
credentialRotationAndRevocation
typedErrorCatalog
redactionContract
CORSContract
maximumPayloadAndRateLimits

The adapter should pin the accepted contract revision and fail closed on an incompatible revision. It should not hardcode undocumented aliases merely because a similarly named route appears in a fixture or interface.

The public contract observed on August 1, 2026 exposes routes such as discovery, runtime lease, search, self, workspace, and public-safe memory submission. Those observations justify building a contract adapter, but they do not establish that any particular user account, credential, workspace, or memory is available.

Local outbox record

pub struct OutboxOperation {
    pub operation_id: String,            // UUIDv7 or content-derived ID
    pub idempotency_key: String,
    pub canonical_request_hash: String,

    pub operation_kind: String,
    pub target_contract_revision: String,
    pub expected_server_revision: Option<String>,
    pub base_cursor: Option<String>,

    pub tenant_binding_hash: String,
    pub agent_binding_hash: String,

    pub created_at: Timestamp,
    pub retry_count: u32,
    pub retry_state: RetryState,
    pub encrypted_payload_ref: Option<String>,
}

A time-ordered UUID may be useful for outbox locality, but operation semantics must not rely on UUID time as an authoritative server revision. The canonical body hash and idempotency key establish replay identity.

Idempotency and optimistic concurrency

For an operation \(o\):

\[ K_{\text{idempotency}} = \operatorname{SHA256}( \texttt{"trlm-outbox-v1\0"} \parallel \text{operation ID} \parallel \text{canonical request hash} \parallel \text{binding hash} ) \]

A retry must reuse the same idempotency key and canonical request bytes. If the local application cannot determine whether a request committed, it should query an advertised status or receipt mechanism rather than issue a semantically new write.

[External] HTTP defines entity tags, If-Match, preconditions, idempotent methods, 409 Conflict, and 412 Precondition Failed, which provide standard primitives for optimistic concurrency when a service contract supports them.

[Recommendation] Use service-specific advertised revision fields when present. Use ETag/If-Match only if the MemoryEndpoints contract advertises them for the relevant route; do not assume generic HTTP support implies application-level revision support.

Offline and cross-browser conflict behavior

Where CRDTs do and do not fit

[External] CRDTs converge when their data type and operations satisfy formal monotonicity or commutativity conditions; they are not a universal conflict-resolution mechanism.

[Recommendation] CRDTs are appropriate for:

• sets of acknowledged message IDs;
• add-only receipt sets;
• counters;
• explicitly commutative tags;
• independent bookmark collections.

They should not silently merge:

• contradictory user preferences;
• corrected biographical facts;
• task plans with mutually exclusive choices;
• consent grants and withdrawals;
• authorization bindings;
• deletions versus writes.

Those require explicit supersession, conflict, or server-authoritative resolution. A last-writer-wins register based only on client time is particularly unsafe for corrections because browser clocks can differ and “latest timestamp” is not equivalent to user intent.

Injection-resistant rendering, cache identity, and receipts

Typed rendering contract

[External] Chat models ultimately consume token sequences, and different models can require materially different role-control tokens and chat templates, even when derived from the same base model. Using the wrong template can substantially degrade behavior.

A model-family-compatible renderer should first create typed blocks, then pass the resulting role messages through the exact verified chat template.

Conceptual block:

<|context_block_start|>
meta_length=241
payload_length=983
metadata={
  "record_id":"sha256:...",
  "record_kind":"retrieval_hit",
  "role":"retrieved_data",
  "instruction_authority":"none",
  "factual_authority":"external_source",
  "untrusted_data":true,
  "source_lineage_hash":"sha256:..."
}
<|payload_start|>
...escaped source bytes...
<|payload_end|>
<|context_block_end|>

This notation is illustrative. The actual markers may be used only if they are reserved special tokens in the verified tokenizer. For models without suitable reserved tokens, use a length-prefixed canonical envelope rendered inside an ordinary role message.

A safer generic text representation is:

TRLM_BLOCK_V1 241 983
{"authority":"data_only", ...canonical metadata...}
<exactly 983 bytes encoded under the declared encoding>
TRLM_BLOCK_END_V1

The parser, not the model, enforces the byte lengths. The model receives the same block as data, but application control must not depend on the model perfectly respecting the boundary.

Required injection defenses

[External] Indirect prompt-injection research demonstrates that malicious instructions can arrive through externally retrieved data rather than directly from the user. Structured-query research consequently separates trusted instructions from untrusted data instead of relying on natural-language admonitions alone.

[External] OWASP identifies prompt injection, insecure output handling, excessive agency, insufficient access control, and sensitive-information disclosure as core LLM-application risks.

The renderer and host must address:

[Recommendation] For consequential tools, use a two-stage architecture: one component reads untrusted content and proposes typed data; a separate privileged policy component authorizes any action using only the minimum necessary fields. The untrusted reader should not possess credentials or broad tool permissions.

Cache identity

KV caching reuses prior attention computations and can improve iterative-generation efficiency, but the cached state depends on the exact preceding token sequence and model behavior. Official Transformers documentation distinguishes cache types and shows prefix-cache reuse, while warning that model and template behavior matters in iterative chats.

A cache key must include:

model_artifact_hash
model_config_hash
adapter_and_merge_hash
quantization_and_runtime_kernel_identity
tokenizer_vocab_hash
tokenizer_merges_hash
special_token_map_hash
chat_template_hash
compiler_policy_hash
context_plan_hash
exact_prefix_token_hash
prefix_token_count
position_encoding_identity
rope_scaling_parameters
sliding_or_chunked_attention_parameters
cache_dtype
cache_layout
cache_format_version
runtime_abi_version

[Recommendation] Cache reuse rule:

\[ \operatorname{reusable\_prefix}(P_{\text{old}},P_{\text{new}}) = \operatorname{LCP} (\text{old token IDs},\text{new token IDs}) \]

only when every non-token identity above is equal.

Any changed selected record, order, rendering template, policy, tokenizer, model composition, positional rule, adapter, or special-token map invalidates the affected suffix. Never reuse KV state across unrelated models under a friendly alias such as “TinyLlama-compatible.”

Privacy-safe receipt

{
  "receiptSchema": "tinyrustlm.context-receipt.v1",
  "compilerVersion": "context-compiler/1.0.0",
  "policyId": "policy/context-v1",
  "policyHash": "sha256:...",
  "planHash": "sha256:...",
  "promptTokenHash": "sha256:...",

  "modelIdentity": {
    "modelHash": "sha256:...",
    "configHash": "sha256:..."
  },
  "tokenizerIdentity": {
    "tokenizerHash": "sha256:...",
    "templateHash": "sha256:..."
  },

  "recordCounts": {
    "currentUser": 1,
    "recentDialogue": 4,
    "profile": 1,
    "memory": 2,
    "retrieval": 3,
    "summary": 0
  },

  "tokenAllocation": {
    "contextWindow": 4096,
    "outputReservation": 768,
    "safetyMargin": 64,
    "systemAndTemplate": 411,
    "currentUser": 506,
    "selectedOther": 2018
  },

  "selectedRecordHashes": ["sha256:...", "sha256:..."],
  "conflictCodes": ["PREFERENCE_STALE_PROFILE"],
  "retrievalIndexIdentity": "hash-or-redacted-id",
  "retrievalIndexRevision": "immutable-revision",
  "cache": {
    "status": "partial-hit",
    "reusedPrefixTokens": 883
  },
  "stopReason": "generation_started",
  "boundedErrors": []
}

The public receipt must exclude:

• prompt text;
• message, memory, or retrieval payloads;
• raw token IDs;
• model output;
• credentials, auth headers, invitation URLs, pairing proofs, and runtime proofs;
• unhashed private source URLs;
• workspace, tenant, company, project, or agent identifiers when those would expose a hidden boundary;
• stack traces containing payload fragments;
• embeddings or reversible lexical fingerprints.

[Recommendation] Selected-record hashes may themselves enable dictionary attacks against predictable private values. For public export, use a receipt-specific keyed commitment or redact the selected-hash list to counts unless cross-party verification is explicitly required.

Evidence review, tests, and quality evaluation

Primary literature and standards review

Quantitative evidence

The following reported effects use different tasks, models, denominators, and metrics and therefore must not be treated as directly comparable effect sizes. They illustrate the magnitude of known long-context and hierarchy problems rather than providing a forecast for TinyRustLM.

xychart-beta
    title "Selected reported long-context and hierarchy effects"
    x-axis ["LongMemEval accuracy drop","Instruction-hierarchy max gain","Found-in-middle max gain"]
    y-axis "Reported percentage or percentage-point effect" 0 --> 70
    bar [30,63,10]

LongMemEval reports a 30% accuracy drop in sustained-interaction memory settings; instruction-hierarchy reporting includes large task-specific robustness gains; and position-bias calibration work reports improvements of up to ten percentage points on evaluated RAG tasks. These measurements are heterogeneous and should be re-measured on the exact local model and compiler.

Evidence-strength assessment

Metamorphic and adversarial test matrix

Browser determinism suite

The same fixture corpus should run in Chromium, Firefox, and WebKit-compatible environments with:

• fixed WASM module hash;
• fixed compiler build;
• fixed model/tokenizer artifacts;
• fixed locale-independent encoding;
• deterministic sorting;
• deterministic fixed-point retrieval scores;
• fixed random seed where stochastic summarization is unavoidable;
• no wall-clock fields inside the plan hash;
• no object-key iteration dependence;
• explicit handling of UTF-8 decoding errors.

Acceptance criterion:

\[ H_{\text{plan}}^{Chrome} = H_{\text{plan}}^{Firefox} = H_{\text{plan}}^{WebKit} \]

and:

\[ H_{\text{tokens}}^{Chrome} = H_{\text{tokens}}^{Firefox} = H_{\text{tokens}}^{WebKit} \]

for every conformance fixture.

End-to-end quality evaluation

Use a factorial test set covering:

Preserve the raw model output in a private test artifact, but not in the public compiler receipt. Score:

\[ Q = w_c C_{\text{continuity}} +w_p C_{\text{current-precedence}} +w_s C_{\text{source-honesty}} +w_f C_{\text{feasibility}} +w_i C_{\text{injection-resistance}} +w_h C_{\text{helpfulness}} -w_l L_{\text{latency}} \]

Security-critical criteria should be gates, not compensable averages. A system that is highly helpful but follows an instruction embedded in retrieval fails regardless of aggregate score.

TDD cutover, blockers, and annotated sources

Test-driven implementation sequence

Stop rules

Deployment must stop if any of the following occurs:

• identical fixtures produce different plan or token hashes across supported browsers;
• a lower-authority record changes a higher-authority instruction decision;
• a retrieved or memory payload can invoke a privileged tool without independent validation;
• the current request is silently truncated while lower-priority context remains;
• the receipt contains prompt, payload, token, output, secret, invitation, or private workspace material;
• a tombstoned record reappears through retrieval, summary, cache, or reconnect;
• a hosted write occurs without pinned contract revision, authorized scope, idempotency identity, and binding;
• a cache hit occurs when model, tokenizer, template, plan, position, or prefix-token identity differs;
• reconnect state can be forged through prompt text or local untrusted metadata;
• deletion cannot be demonstrated across the local store, index, summaries, outbox, and cache.

Clean-cutover criteria

The legacy prompt path may be deleted when:

1. all golden context-plan fixtures are deterministic;
2. all current-turn-precedence tests pass;
3. all injection and fake-role tests pass;
4. all overflow cases stop or continue visibly;
5. all public receipts pass secret-scanning and payload-leak tests;
6. revoked credentials fail closed;
7. tombstone and deletion tests show no reappearance;
8. authorized reconnect dogfood succeeds in at least two clean browser profiles;
9. cache invalidation tests cover every identity component;
10. a one-way production feature gate has shown no fallback dependence.

[Recommendation] After those criteria pass, remove the old assembler, old prompt constants, undocumented memory aliases, migration readers, compatibility shims, and fallback cache keys. Keep test fixtures that demonstrate the old failures, but not executable legacy behavior.

Principal blockers and local-verification requirements

Annotated primary-source bibliography