Awesome Testing

API lesson 08 · Ship the API boundary

Can you defend the complete request-to-decision path across providers and failures?

Shared system · deterministic provider fixtures

Harbor Support Drafting API. One bounded request moves through typed items, tools, state, budgets, and evidence without live provider calls.

01 · Smallest useful mechanism

Integrate the controls around one observable product claim.

The capstone assembles a support-drafting endpoint with streaming previews, a structured final draft, a read-only policy tool, explicit state, bounded retries, privacy-preserving traces, and an evaluation hook.

Provider portability follows from semantic contracts and evidence—not identical JSON.

02 · Experiment

Test the prediction

Deterministic protocol fixture

This workbench uses inspectable provider-event fixtures and injected failures. It does not make live calls or execute external effects.

Protocol workbench · harbor-capstone-v1

Choose the release candidate that can support a bounded public beta.

Injected failure

All candidates pass the golden path; only one preserves controls during provider and tool failures.

Choose the implementation

The trace has not run.

Commit to an implementation, then inject the failure and inspect the actual state transitions.

03 · Implementation brief

Build it, break it, prove the outcome.

Implement
Produce the architecture, capability matrix, state map, tool policy, trace schema, failure matrix, evaluation link, and rollout plan.
Break it on purpose
Combine stream loss, stale policy, malformed output, 429, cross-tenant state, tool injection, and provider failover.
Completion evidence
The service fails safely, reports truthful outcomes, preserves evidence, stays within budgets, and passes the same semantic suite on every supported adapter.

Your learning artifact

Write the argument you would defend

Stored only in this browser. No account required; course reset does not delete it.

Capstone decision rubric

Would this LLM API be safe to pilot?

Ready

The semantic contract, state ownership, security boundary, failure recovery, budgets, traces, and acceptance suite remain coherent under injected failures.

Incomplete

The happy path works, but a capability, terminal state, ownership rule, compatibility case, or recovery invariant remains implicit.

Unsafe

The design executes untrusted proposals, relies on stale or hidden authority, retries unknown effects blindly, leaks sensitive data, or hides failure behind a polished final answer.

04 · Check your understanding

What is the strongest evidence of provider portability?

Primary sources · verified 2026-08-02

What the fixture does not prove

Individual mechanisms can be correct while their composition creates deadline overruns, stale authority, tool-result confusion, data leakage, or misleading success states.

Common mistake: Passing one end-to-end happy-path test proves production readiness. Readiness requires versioned contracts, representative failures, security controls, repeated evaluations, operational limits, and a rollback decision.

Transfer exercise: Run the same acceptance suite through two provider adapters and force streaming loss, stale policy, 429, malformed output, and tool-result injection.

Optional referenceDeep dive / reference chapterOpen the complete essay, diagrams, mathematics, exercises, glossary, and sources when you want more depth.

Next: The next course replaces application-specific tool declarations with a standard client–server protocol: MCP.