Task, Environment, Policy, Budget, and Trace

The same prompt and model can produce different product behavior when the working tree, policy, principal, network access, locale, time, budget, tool set, or executable changes. If those inputs remain ambient, a stored output cannot answer the most basic debugging question:

What exact system was allowed and expected to produce this result?

Harness Chapter 1 defined behavior and completion. This chapter compiles the execution context around that contract before the first model or tool call:

behavior specification
        │
        ├── task binding ───── objective + input manifest
        ├── environment ───── executable + workspace + runtime settings
        ├── policy ────────── principal + tenant + allowed effects + expiry
        ├── budget grant ──── organization ceiling + expiry
        └── trace contract ── required causal evidence + redaction release
                           │
                           ▼
                 immutable run envelope
                           │
                           ▼
             model/tool/verifier execution
                           │
                           ▼
               hash-linked terminal trace

The run envelope is not a dump of every process value. It is a deliberately bounded list of inputs whose changes can affect correctness, authority, cost, privacy, or replay. Secret values are represented by protected references or digests, never copied into the public trace.

The companion implements this boundary in mosaic-harness::run_contract. Thirteen module tests and one focused example prove budget intersection, behavior-policy authority, expiry, strict environment records, identity drift, trace ordering, envelope binding, hash-link tamper detection, required event coverage, and terminal finality.

Learning objectives

By the end you will be able to:

• distinguish a task definition from a behavior specification and one run envelope;
• replace ambient inputs with explicit, bounded, versioned observations;
• decide which environment facts affect semantic replay;
• bind principal, tenant, policy release, effect authority, and expiry;
• compute effective authority as an intersection rather than a union;
• intersect product budgets with organizational grants without silently widening either;
• distinguish reservation, ceiling, usage, reconciliation, and quota;
• define a trace contract before execution;
• separate a causal trace from logs, metrics, raw payload storage, and chain of thought;
• bind every trace record to one run envelope;
• detect record deletion, insertion, reordering, mutation, and cross-run splicing;
• explain what a hash link does and does not prove;
• propagate distributed trace context without trusting caller sampling or metadata blindly;
• redact data while retaining evidence that redaction occurred;
• design terminal traces that support debugging, replay, evaluation, and audit;
• recognize when environment capture itself creates a privacy or secret-leak risk.

Prerequisites and dependency order

Complete behavior specifications and completion conditions. This chapter imports its BehaviorSpecification, BehaviorBudget, and EffectClass. Complete the production chapters on configuration, authorization, observability, durable jobs, and structured cancellation. Those chapters explain individual mechanisms; this chapter binds their relevant identities into a harness run.

The dependency direction matters:

1. behavior says what must become true and what must never happen;
2. policy says what this principal may do now;
3. budget says what resources the organization grants now;
4. environment says where and with which releases execution will occur;
5. the compiled envelope records the effective intersection;
6. the trace records what actually happened under that envelope;
7. completion evaluates terminal evidence against behavior.

Policy does not rewrite behavior. A generous policy cannot make a forbidden effect acceptable. Behavior does not grant authority. A task requiring a read cannot authorize a principal who lacks read permission. The compiler rejects that mismatch before execution.

Completion artifact

Run:

cd rust/rust-ai-engineering
cargo test -p mosaic-harness run_contract
cargo run -q -p mosaic-harness --example compiled_run_envelope

Pinned output:

compiler release              mosaic-run-envelope-v1+task+environment+policy+budget+trace
envelope SHA-256              fcd3df597e0b104ece09e04fe3541fc78c2cac3ee92863643d07a5e0f05359be
behavior specification       900bd6c6bb8e3bcea96c8bc070a44341915403556b479e18e4a89b7e25f015a8
effective model calls        2
effective tool calls         4
effective elapsed ms         8,000
effective cost microunits    30,000
effective output bytes       4,096
effective allowed effects    read_only
valid until epoch ms         15,000
trace records                4
trace SHA-256                 9beb68227b482eda5b88638fb3b8cbf011f2719d59474a20684b9c30afea0c63
redacted fields              2

The behavior allows three model calls, four tool calls, ten seconds, 50,000 cost microunits, and 8,192 output bytes. The organization grant allows two model calls, six tool calls, eight seconds, 30,000 microunits, and 4,096 output bytes. The effective envelope takes the minimum independently for every dimension.

The policy generally allows read-only and local-write effects. The behavior forbids local writes, so the effective run permits only read-only work. The budget grant expires at 15,000 ms and policy at 20,000 ms, so the envelope expires at the earlier boundary.

Task, specification, envelope, and run are different

These identities are often collapsed into one “request ID.”

Object	Stable meaning	Can be reused?
Behavior specification	Observable success, constraints, effects, budgets	Yes, across matching tasks
Task binding	Objective and exact input manifest for a task	Yes, for deliberate repeated runs
Run envelope	Task + environment + policy + grant + trace contract at one time	Normally no
Run	One execution attempt and its events	No
Completion report	Evaluation of one observation against one specification	Recomputed only under named evaluator

A task binding in the companion contains:

pub struct TaskBinding {
    pub task_id: String,
    pub objective_sha256: String,
    pub input_manifest_sha256: String,
}

The objective digest prevents a human-readable task ID from silently changing meaning. The input manifest digest binds all selected input artifacts and locators without embedding their raw bytes. The behavior specification digest binds the task to its definition of done.

In production, add an explicit relationship between objective text and the specification. The fixture uses separate digests to teach the boundary. A task can request “review snapshot S” while the behavior contract defines required evidence, effects, and output. Both affect meaning and should be preserved.

Do not hash an incomplete manifest

input_manifest_sha256 is useful only when the manifest is complete. Include:

• artifact digests and media types;
• source locators and lineage identities;
• declared ordering;
• tenant/access scope;
• acquisition or snapshot identity;
• transformations already applied;
• missing-input policy.

Hashing only filenames creates stable identity for unstable content. Hashing content without access scope can accidentally reuse private work across tenants.

Environment: capture semantic inputs, not the whole machine

Environment means facts outside the task that can affect execution. Common examples:

• operating system and architecture;
• exact executable or container image;
• workspace/source snapshot;
• model/runtime release;
• enabled feature flags;
• locale, timezone, and clock source;
• network mode and accessible endpoints;
• deterministic or nondeterministic runtime settings;
• relevant environment/config values;
• device type, driver, kernels, numeric precision, and fallback policy;
• tool binaries and sandboxes.

The reference snapshot starts small:

pub struct EnvironmentSnapshot {
    pub snapshot_id: String,
    pub operating_system: String,
    pub architecture: String,
    pub executable_sha256: String,
    pub workspace_sha256: String,
    pub network_mode: NetworkMode,
    pub timezone: String,
    pub locale: String,
    pub variables: Vec<EnvironmentVariableReceipt>,
}

This is not a claim that OS strings are sufficient for exact replay. It is a minimum contract for the provider-free fixture. A real local-inference run should also bind weights, tokenizer, processor, runtime, device, precision, kernel, seed, and sampling release. A remote call should bind provider route, declared model revision, API version, request contract, and returned provider IDs.

Ambient state is an undeclared dependency

Reading std::env, current directory, system clock, or network configuration deep inside a model or tool adapter makes tests and replay depend on the host. Read relevant values once at the boundary, validate them, create a snapshot, and pass the typed result inward.

Environment-driven configuration can be operationally appropriate; the Twelve-Factor configuration principle recommends keeping deploy configuration separate from code. That does not mean values should remain unrecorded. The harness should capture the effective, validated configuration identity used for a run.

Secret-safe variable receipts

The companion stores:

pub struct EnvironmentVariableReceipt {
    pub name: String,
    pub value_sha256: String,
    pub sensitive: bool,
}

This avoids raw values in the envelope. It still requires care:

• a digest of a low-entropy secret may be brute-forced;
• variable names can reveal infrastructure;
• equality across runs can reveal secret reuse;
• a hash does not prove the value came from an authorized secret manager;
• later deletion does not remove a published digest.

For secrets, prefer an opaque secret-version reference or keyed digest under protected access. Record that a value was supplied and which release it belonged to without making credential material or a guessable fingerprint public.

Snapshot identity versus enforcement

Recording network_mode = disabled does not disable the network. An environment snapshot is an observation or configuration claim. Enforcement belongs to the sandbox, container, host firewall, capability system, or runtime. Strong receipts should show the enforcement release and outcome.

The same applies to workspace immutability. A pre-run digest plus post-run digest detects many changes but does not prevent temporary modification, access outside the hashed tree, or races. Use read-only mounts or OS isolation when the invariant matters.

Policy: current authority for a specific actor and scope

A behavior contract may require an effect, but only policy can authorize the concrete actor. The snapshot includes:

pub struct PolicySnapshot {
    pub policy_id: String,
    pub release_sha256: String,
    pub principal_id: String,
    pub tenant_id: String,
    pub expires_at_epoch_ms: u64,
    pub allowed_effects: Vec<EffectClass>,
}

The compiler first validates unique effect classes. It then requires every effect named by the behavior specification to appear in policy authority. Missing authority is a compile-time run error, not a prompt-repair opportunity.

The NIST definition of least privilege limits users or processes to the minimum authorizations and resources needed for their function. The run compiler implements one piece of that principle through intersection:

effective effects = policy-allowed effects − behavior-forbidden effects

It never uses union:

unsafe: policy allows write OR task wants write ⇒ allow write

The policy may be broader because it describes a role across many tasks. The compiled run should be narrower because it describes one task.

Authority needs more dimensions than an effect class

ReadOnly is too broad for production. A complete authorization decision also binds:

• principal and delegated actor;
• tenant and resource owner;
• exact resource or path scope;
• operation and parameters;
• purpose or task;
• policy release;
• approval or capability token;
• issue/expiry/revocation state;
• conditions such as network, amount, and rate;
• separation-of-duty or human-review requirements.

The reference effect class proves the intersection mechanism. Later typed-tool chapters refine it to per-call capabilities and receipts.

Expiry and revocation

The envelope compiles only when both policy and budget grant expire after compilation. Its valid_until_epoch_ms is their minimum. Long-running workflows must re-authorize effects whose authority may expire or be revoked. A valid start-time policy snapshot is historical evidence, not permanent permission.

For high-impact actions, authorize as close to execution as possible and include the current run envelope, tool call, resource, and parameters in the decision subject.

Budget: request, grant, reserve, use, and reconcile

“Budget” can name five different things:

Stage	Meaning
Requested	Product would like this much
Granted ceiling	Organization will allow at most this much
Reserved	Capacity held for admitted concurrent work
Used	Measured consumption
Reconciled	Reservation released and actual usage charged

The behavior specification supplies the product ceiling. BudgetGrant supplies the organizational ceiling and expiry:

pub struct BudgetGrant {
    pub grant_id: String,
    pub expires_at_epoch_ms: u64,
    pub ceiling: BehaviorBudget,
}

The compiler intersects each dimension:

effective.max_model_calls = spec.max_model_calls.min(grant.max_model_calls);
effective.max_tool_calls = spec.max_tool_calls.min(grant.max_tool_calls);
effective.max_elapsed_ms = spec.max_elapsed_ms.min(grant.max_elapsed_ms);
effective.max_cost_microunits =
    spec.max_cost_microunits.min(grant.max_cost_microunits);
effective.max_output_bytes =
    spec.max_output_bytes.min(grant.max_output_bytes);

Do not compare a combined “budget score.” Two model calls and 10 MB output are not interchangeable with ten model calls and 2 KB output. Each resource has its own operational and risk boundary.

The run envelope does not reserve concurrency or money. The existing mosaic-policy ledger teaches reservation and reconciliation. Integrating that ledger later should preserve the grant identity:

grant ─► reservation ─► per-stage usage ─► terminal reconciliation
  │           │                │                    │
  └──────── stable IDs and checked arithmetic ─────┘

If a process crashes, durable state must distinguish an active reservation from charged usage. Timeout and cancellation paths release unused capacity exactly once. Retries must have one owner, or provider, HTTP client, harness, and job worker can each multiply resource use.

Trace: causal evidence, not a debug transcript

OpenTelemetry describes traces as the path of a request through an application and distinguishes traces, metrics, logs, and baggage as separate signals (OpenTelemetry signals). A harness trace has a related but stricter purpose: explain decisions and bind evidence needed for replay and completion.

A useful trace answers:

• which envelope governed the run?
• which stage happened in which order?
• what input/output identity crossed the stage?
• which policy or budget decision allowed it?
• what verifier result changed control flow?
• why did the run stop?
• which sensitive fields were omitted or protected?

It should not store:

• hidden chain-of-thought;
• entire prompts or user files by default;
• raw credentials;
• uncontrolled tool output;
• every log line;
• mutable pointers without retention contracts.

The reference trace contract names a schema, ID, redaction policy, and required event kinds:

pub struct TraceContract {
    pub schema_version: u32,
    pub trace_id: String,
    pub redaction_policy_sha256: String,
    pub required_events: Vec<RunTraceEventKind>,
}

Every contract must require:

• EnvelopeCompiled;
• RunStarted;
• RunTerminal.

The fixture also requires VerificationCompleted. Tool-using contracts can require tool request and completion receipts. The required-event list is checked for duplicates so no map or set silently hides malformed input.

Event identity and payload identity

Each trace record contains:

pub struct TraceRecord {
    pub sequence: u64,
    pub envelope_sha256: String,
    pub previous_record_sha256: String,
    pub kind: RunTraceEventKind,
    pub subject_sha256: String,
    pub redacted_fields: u32,
}

subject_sha256 identifies the event-specific receipt or protected payload. It does not contain the payload. The storage layer must retain that subject under correct access, integrity, and retention policy if replay needs it.

redacted_fields makes omission visible but is not enough to reproduce the redacted structure. A strong redaction receipt should name input subject, output subject, redaction policy and release, field/path classes removed, and whether the transformation is reversible under protected access.

Hash links detect trace mutation

The first record points to an all-zero root sentinel. Each later record stores the digest of the previous complete record. Validation recomputes each identity and checks:

• contiguous sequence starting at one;
• every record binds the same envelope;
• every previous digest matches;
• required event kinds occurred;
• first event is envelope compilation;
• last event is terminal;
• nothing can append after terminal through the API.

This detects modification, removal, insertion, reordering, and cross-run splicing inside the validated chain. It does not prove:

• who created the chain;
• that omitted real-world events never occurred;
• that a dishonest producer reported truth;
• that two different valid chains were not forked;
• secure timestamping;
• durable append-only storage.

Add signatures, trusted timestamps, monotonic storage generations, witness logs, or transparency systems when those properties are required. Describe the actual claim as “hash-linked” rather than “tamper-proof.”

Distributed context is correlation, not authorization

The W3C Trace Context Recommendation standardizes traceparent and tracestate for correlating requests across systems. It defines a 16-byte trace ID and 8-byte parent ID for version 00, rejects all-zero identifiers, and includes explicit privacy, security, and denial-of-service considerations.

Use W3C context to correlate the run with HTTP/services, but keep these rules:

• an incoming trace ID is not a run ID, tenant ID, or authorization token;
• tracestate is untrusted metadata;
• caller sampling flags are recommendations, not a guarantee of recording;
• baggage must never carry credentials or unrestricted user content;
• invalid context is rejected or replaced according to the standard;
• internal envelope identity remains explicit even when distributed tracing is sampled;
• trace correlation should survive without exposing sensitive task identity.

OpenTelemetry context propagation can correlate traces, metrics, and logs across service boundaries. The run envelope adds product semantics that generic telemetry does not know: behavior, policy, budget, evidence, and completion identities.

Compile before expensive or irreversible work

compile_run_envelope follows a fail-closed order:

1. validate the behavior specification;
2. validate run and task identifiers/digests;
3. validate environment bounds and unique variables;
4. validate policy identity, expiry, and unique effects;
5. validate budget grant and hard resource bounds;
6. validate trace schema, redaction identity, and mandatory events;
7. reject expired policy or grant;
8. prove authority for every behavior-required effect;
9. subtract behavior-forbidden effects;
10. intersect every budget dimension;
11. choose earliest expiry;
12. build and validate the immutable envelope;
13. compute its stable identity;
14. emit EnvelopeCompiled;
15. only then admit model or tool work.

The function accepts explicit RunEnvelopeInput; it reads no global environment, clock, current directory, network state, or provider. The caller owns acquisition of those facts and their trustworthiness.

Failure investigations

1. Same task, irreproducible result

Symptom: a stored trace has task ID and prompt, but a rerun differs.

Investigate: compare executable, workspace, model, environment, policy, and budget identities.

Root cause: task identity was used as a substitute for execution identity.

Repair: bind every semantic dependency into a run envelope and compare envelopes before outputs.

2. A required read cannot compile

Symptom: RequiredEffectNotAuthorized(ReadOnly) before the model call.

Investigate: compare behavior-required effects with policy-allowed effects for the exact principal and tenant.

Root cause: the task requested behavior the current actor cannot perform.

Repair: change the task, obtain narrowly scoped authority, or route to review. Prompt repair cannot create permission.

3. Local write disappears from effective authority

Symptom: role policy allows local writes, but envelope lists only read-only.

Investigate: inspect behavior-forbidden effects.

Root cause: compilation correctly subtracts task-specific prohibitions from broader role policy.

Repair: none when read-only behavior is intended. If writing is genuinely required, create a new behavior contract and authorization review instead of mutating the envelope.

4. Budget unexpectedly shrinks

Symptom: behavior allows six tools but envelope allows four.

Investigate: compare every behavior limit with every grant limit independently.

Root cause: organizational grant is stricter for that resource.

Repair: adapt the plan, request a new grant, or reject admission. Never borrow unused cost from another dimension unless policy explicitly defines conversion.

5. Grant is valid now but expires during execution

Symptom: envelope compiles, then authority expires before a tool effect.

Investigate: compare estimated stage duration, envelope validity, and per-effect reauthorization.

Root cause: start-time validation was treated as lifetime authority.

Repair: reject work that cannot finish safely, renew before expiry, or reauthorize each effect. Preserve both old and new grant identities.

6. Duplicate environment key changes identity unpredictably

Symptom: two MODEL_ROUTE receipts appear with different digests.

Investigate: detect duplicates before collection into a map.

Root cause: precedence was implicit and serializer/map behavior selected one value.

Repair: resolve configuration precedence before snapshot construction, then require unique effective keys.

7. Trace validates until one subject changes

Symptom: after editing record two, record three reports a broken link.

Investigate: recompute the edited record identity and compare the next record’s previous digest.

Root cause: the chain correctly binds content and ordering.

Repair: restore original evidence or create a new chain/fork with explicit ancestry. Never patch historical records in place.

8. Required verification event is absent

Symptom: chain ordering and links validate, but terminal validation fails.

Investigate: compare observed event kinds with TraceContract.required_events.

Root cause: integrity does not imply completeness. A perfectly linked trace can omit a required stage.

Repair: fail completion or recover the missing protected receipt. Do not infer verification from a terminal label.

9. Public trace leaks secrets

Symptom: an environment snapshot contains an API key or raw tool response.

Investigate: identify which acquisition boundary serialized raw values before redaction.

Root cause: observability was treated as unrestricted debugging storage.

Repair: rotate exposed credentials, restrict and purge where possible, replace raw values with protected references, and regression-test Debug, Display, JSON, logs, and errors.

10. Hash-linked was described as tamper-proof

Symptom: two internally valid traces exist for the same run ID.

Investigate: inspect producer identity, storage generation, signatures, witnesses, and fork policy.

Root cause: hash linking detects internal mutation but does not prevent a producer from creating two histories.

Repair: add authenticated append authority and durable fork detection. Correct documentation to the narrower verified claim.

Security implications

The envelope becomes a high-value authority object. Protect it accordingly:

• accept only strict schemas and bounded collections;
• authenticate the compiler boundary;
• obtain current principal and tenant from verified identity, not model text;
• never use task content as policy;
• bind capabilities to exact resources and operations in production;
• subtract behavior prohibitions from role policy;
• use earliest expiry and revalidate before effects;
• preserve policy and grant release identities;
• avoid raw secrets and low-entropy secret digests;
• separate public trace subjects from protected payload storage;
• enforce network/filesystem/device claims outside the snapshot;
• sign envelopes and receipts when crossing trust boundaries;
• prevent run-ID reuse or make generations explicit;
• cap trace events and diagnostic output;
• treat caller-supplied distributed context as untrusted correlation metadata.

Least privilege is not only fewer tools. It includes data scope, network destinations, effect parameters, duration, concurrency, cost, and output channels.

Performance and storage implications

Compilation serializes and hashes the behavior specification and envelope. Trace append hashes the previous record and new record. For ordinary interactive runs this overhead is small, but measure:

• environment acquisition time;
• manifest construction and hashing;
• policy and grant decision latency;
• envelope bytes;
• per-record serialization/hash time;
• trace bytes by event kind;
• protected payload storage;
• validation time for 1, 10, 100, 1,000, and 4,096 records;
• redaction and encryption overhead;
• export backpressure and drop behavior.

Do not block the product forever on an unavailable telemetry exporter. The product trace required for completion may need a durable local write-ahead path, while optional observability export can buffer, sample, or degrade. Explicitly define whether inability to record a required receipt stops the run. Silent loss is the worst option.

Hashing a huge workspace on every model step is wasteful. Capture one immutable snapshot identity or incremental content-addressed tree, then reference it. Rehash when an authorized transformation creates a new generation.

Alternatives and trade-offs

Pass configuration fields independently

Simple initially, but functions gradually omit or reorder dependencies. A typed envelope centralizes validation and identity. Avoid turning it into a global mutable “context” object; pass narrow views to components.

Capture the entire process environment

Easy and comprehensive-looking, but leaks secrets, adds irrelevant drift, and makes identity noisy. Use an allowlisted, typed effective configuration contract.

Container image digest as the whole environment

Strong for packaged files, weak for runtime mounts, secrets, policy, devices, kernel, network, and remote dependencies. Keep it as one field in a broader snapshot.

Ordinary logs only

Useful for operations, but free-form logs rarely guarantee required event coverage, stable subjects, or replay identities. Emit logs from trace events if helpful; do not make prose logs the sole causal record.

OpenTelemetry spans only

Excellent for cross-service correlation and latency. Generic spans do not automatically encode behavior contracts, authority, budgets, evidence receipts, or completion. Bridge envelope/run IDs into safe span attributes and preserve the product trace separately when required.

Database event log

Better for durable workflows, concurrent writers, and recovery. Use transactional sequence allocation, generation fencing, and immutable payload identities. The in-memory TraceChain is a teaching artifact for the contract, not a distributed log.

Merkle tree or transparency log

Supports efficient inclusion proofs and large append-only histories. It adds operational and proof complexity. A linear chain is adequate for a bounded single-run trace; global audit logs may need a tree and external witnesses.

Practical milestone

Extend compiled_run_envelope:

1. add an explicit model/runtime release to EnvironmentSnapshot;
2. add a protected secret-version reference type instead of a raw digest;
3. add a resource scope to policy authority;
4. add one mutation for expired authority between model and tool stages;
5. add a budget reservation ID and terminal reconciliation receipt;
6. add a tool request and completion event to the trace contract;
7. tamper with, delete, reorder, and splice records; classify each failure;
8. bridge the run to a valid W3C traceparent without using it as authorization;
9. measure trace validation from 1 to 4,096 records;
10. write a note defining which environment changes require strict replay, forked replay, or a new evaluation comparison.

Keep the baseline provider-free. Optional extensions may connect a remote provider only after exact request, release, and response identities are recorded.

Exercises

Recall and classify

1. Distinguish task ID, specification digest, envelope digest, trace ID, and run ID.
2. Classify model weights, timezone, user input, policy, and usage as task, environment, authority, or observation.
3. Explain why environment variables can be good configuration inputs and bad ambient dependencies.
4. Name four things a hash-linked trace does not prove.
5. Explain why incoming traceparent is not authorization.

Predict and trace

6. Compute effective budgets for (3 calls, 10 s, 8 KB) behavior and (5 calls, 8 s, 4 KB) grant.
7. Predict effective effects when policy allows read/write/network and behavior forbids write/network.
8. Trace a task from input manifest through envelope compilation to a completion report.
9. Predict the first failing record after mutating record two in a five-record chain.
10. Decide whether missing optional metrics invalidates a run whose required product trace is complete.

Implement and repair

11. Add model_release_sha256 and prove identity drift.
12. Replace environment variable names with an allowlisted enum for one application.
13. Add a resource-scoped authorization and reject a same-class effect on another resource.
14. Add a signed-envelope placeholder interface without implementing cryptography; keep signature verification outside deserialization.
15. Add maximum total serialized trace bytes in addition to event count.
16. Add explicit trace fork ancestry and tests for authorized versus silent forks.

Design and measure

17. Design an envelope for local GPU inference including device and numeric behavior.
18. Design an envelope for a remote multimodal provider whose backend revision may be opaque.
19. Design a durable trace store for concurrent workers and crash recovery.
20. Benchmark JSON versus a canonical binary encoding for envelope identity; include portability, inspectability, and migration.
21. Threat-model a service that accepts caller-supplied environment and policy snapshots.
22. Define a retention plan where task data expires before aggregate operational metrics.

Solution and review guidance

1. The task names requested work; specification names success; envelope names effective execution inputs; trace correlates events; run names one attempt.
2. Weights/timezone are environment; user input is task evidence; policy is authority; usage is an observation.
3. Read once, validate, and snapshot the effective allowlisted values. Avoid hidden reads deep in execution.
4. It does not prove producer identity, truth, completeness, absence of forks, or trusted time.
5. Trace context correlates operations and is caller-controlled metadata; policy uses authenticated identity and scoped decisions.
6. Effective values are 3 calls, 8 seconds, 4 KB.
7. Only read remains.
8. Join task inputs to behavior, environment, policy, grant, and trace contract; then join terminal receipts back to that envelope and behavior.
9. Record three fails because its stored previous digest names the original record two.
10. No, unless metrics are declared required evidence. Record degradation honestly.
11. Add the digest before envelope identity; a one-byte release change must change the envelope.
12. An enum reduces typo and surprise surface but needs versioning when configuration evolves.
13. ReadOnly on repository A must not authorize database B. Bind operation, resource, tenant, and purpose.
14. Separate unsigned content, signature envelope, key ID, algorithm, and verifier result. Never accept presence of bytes as verified.
15. Count before append and reject before growing storage. Decide whether protected subjects count separately.
16. A fork records parent chain identity and policy authorization; a silent competing terminal history is an incident.
17. Bind weights, tokenizer/processor, runtime, device UUID/class, driver, precision, kernels, fallback, seeds, and deterministic settings.
18. Bind every observable provider identity, exact request, response request ID, dates, and capability contract; state that opaque backend replay is not guaranteed.
19. Use transactional per-run sequence numbers, generation fencing, immutable payload digests, and idempotent append keys.
20. Canonical binary formats may reduce size and ambiguity; JSON improves inspection. Golden cross-language vectors and explicit versions matter more than format fashion.
21. The server must derive trusted principal/policy/environment facts itself or verify signed attestations. Caller claims cannot grant authority.
22. Store protected payloads separately with short retention, preserve redacted structural receipts, and ensure metrics cannot be joined back to people unexpectedly.

Check your understanding

• Which fields make two executions different runs of the same task?
• Why does effective authority use subtraction/intersection?
• What happens when behavior requires an effect absent from policy?
• Why does an environment digest need a complete manifest?
• Which expiry controls the run envelope?
• Does a snapshot enforce network isolation?
• What is the difference between budget grant and reservation?
• How does a chain detect event reordering?
• Why can a perfectly hash-linked trace still be incomplete?
• What belongs in protected payload storage rather than the trace?
• How should a trace behave after a terminal record?
• When should authority be revalidated during a long run?

Primary references

• W3C Trace Context Recommendation
• OpenTelemetry concepts
• OpenTelemetry signals
• OpenTelemetry context propagation
• NIST glossary: least privilege
• NIST SP 800-171r3: least privilege and audit controls
• The Twelve-Factor App: config
• Serde attributes
• RustCrypto SHA-2

Definition of done

You are finished when you can demonstrate all of the following:

• task, specification, envelope, run, trace, and completion report have distinct identities;
• objective and input manifests are content-bound;
• environment inputs are explicit, allowlisted, bounded, and secret-safe;
• policy binds release, principal, tenant, effects, and expiry;
• every behavior-required effect has policy authority before execution;
• behavior-forbidden effects are removed from broader role authority;
• effective budgets take the stricter limit independently for every resource;
• envelope validity uses the earliest policy/grant expiry;
• trace schema and redaction policy are versioned;
• mandatory envelope/start/terminal events are required;
• records have contiguous sequence, envelope binding, subject identity, and hash links;
• deletion, mutation, reordering, splicing, and post-terminal append fail;
• required-event coverage is checked separately from hash integrity;
• distributed trace context is used for correlation, never authorization;
• limitations of snapshots, hashes, and producer trust are documented;
• the 13 module tests and focused example test pass;
• full workspace formatting, Clippy, tests, docs, fuzz compilation, and dependency policy pass.