# Optional Technical Labs

These labs add implementation practice to Missions 3–9 without creating a second
curriculum. Use the fictional claims-denial case or substitute a customer-safe case.
Choose any language and framework. Keep the business contract, evidence, and
authority independent of the implementation.

Each lab ends with an observable artifact and a failure that the learner must make
the system detect. Passing a lab is practice evidence only.

## Lab 1 — Decision-bound data and context

**Build**

Create a versioned context manifest for a denial-correction recommendation. Include:

- source identity, revision, authority, purpose, and permitted population;
- preparation steps and lineage;
- label or expected-output authority and adjudication path;
- freshness, quality, access, retention, and restricted-field rules;
- behavior for missing, stale, contested, or unauthorized context.

Write a small validator that rejects a context bundle with a missing source revision,
wrong tenant, stale policy, or absent required encounter note.

**Prove**

Run one valid bundle and four invalid mutations. Capture deterministic results and
the remediation route. Do not let retrieval success turn the bundle into authority.

**Keep**

Context manifest, validator, fixtures, and positive/negative test output.

## Lab 2 — Smallest-mechanism bake-off

**Build**

Implement the same bounded decision three ways:

1. deterministic policy/rule;
2. scoped retrieval plus one model call;
3. human-only review baseline.

Use the same fixtures and measure quality, latency, full cost, review time, failure
detectability, and recovery. Add an agent route only if multi-step uncertainty cannot
be met by the smaller candidates.

**Prove**

Document where the rule is sufficient, where contextual judgment is required, and
what remains a human authority decision. Define an invalidation and retirement
trigger for the selected route.

**Keep**

Runnable comparison, measurements, and intelligence-selection record.

## Lab 3 — Evaluation harness that catches false green

**Build**

Create routine, boundary, adversarial, and recovery cases. Keep deterministic
contracts, behavioral quality, authorization, latency, cost, and review burden in
separate result lanes. Bind the run to code, context, configuration, model route,
tools, and grader revision.

**Prove**

Make the suite fail by introducing at least these mutations:

- mismatched citation;
- stale policy or approval;
- duplicate recommendation;
- cross-tenant context;
- failed readback with a false completion claim.

If the suite stays green, repair the harness rather than lowering a threshold.

**Keep**

Cases, reference-authority record, runner, mutation tests, raw results, and report.

## Lab 4 — Trusted effect boundary

**Build**

Implement a narrow recommendation-write capability with:

- authenticated caller and tenant/object scope;
- typed bounded input;
- capability version and policy revision;
- stable idempotency key and concurrency precondition;
- timeout classes, source-of-truth readback, retry rule, and disable path;
- audit fields that exclude secrets and restricted content.

The model receives no reusable credential and cannot expand scope through a prompt,
retrieved page, tool output, or plan.

**Prove**

Test allowed use, wrong tenant, expanded object scope, replay, concurrent revision,
timeout after possible effect, failed readback, and disabled capability. Reconcile an
uncertain result before retry.

**Keep**

Tool contract, implementation, threat tests, and effect/readback traces.

## Lab 5 — Exact release, rollback, and service change

**Build**

Create a release manifest that binds code digest, dependency lock, schema/migration,
configuration, context revision, behavior route, tools, capabilities, and evaluation
evidence. Add a canary limit, telemetry, cost ceiling, stop condition, rollback, and
disable path.

**Prove**

1. Exercise forward migration and rollback with an old record.
2. Disable queued work and reconcile in-flight state.
3. Change one bound dependency and show which evidence becomes stale.
4. Run a short service review using outcome, adoption, reliability, safety, cost,
   human-review, and incident evidence.

**Keep**

Release manifest, exercised rollback evidence, selective-rerun trace, and service
decision.

## Review rubric

- Every lab protects the same accepted business and authority boundary.
- Tests contain visible negative and recovery evidence, not only happy-path output.
- Model behavior, deterministic software, tools, and human review remain separately
  observable.
- Full cost and operating burden are measured where relevant.
- A model, evaluation score, graph, or tool description never grants authority.
- Artifacts bind to exact versions and state their limitations.

## Attributed optional depth

For adjacent implementation practice, consult the independent MIT-licensed
[AI Engineering from Scratch](https://github.com/rohitg00/ai-engineering-from-scratch)
curriculum by Rohit Ghumare and contributors, especially its LLM engineering, tools
and protocols, agent engineering, and infrastructure and production phases. Lumyn's
labs are original FDE exercises and do not reproduce those lessons.