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 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.