Assignment
Assume a customer has a ticket API, a document repository, single sign-on, and a small operations team. The pilot must retain human review.
Build sequence
- Draw a search-only option and a retrieval-plus-drafting option.
- Annotate identity, data scope, and failure behavior at each boundary.
- Write decisions for hosting, retrieval, model access, and operational ownership.
- Present a five-minute tradeoff review and record challenges from a peer.
Acceptance checks
- Every component has an owner and a demonstrated purpose.
- The design includes a manual fallback and a rollback route.
- At least one condition is identified under which the simpler option wins.
Evidence to keep
Submit the working artifact or decision document described above, the inputs used, and the observed results for every acceptance check. Include one failed attempt and the change you made after investigating it. Label fixture-based outcomes separately from live-system measurements. These artifacts become part of your final portfolio review.
Guided workshop: turn constraints into an architecture choice
Northstar needs a draft assistant within an existing ticket workflow. Compare two options before drawing the preferred system: A, authorized search with a human-written reply; B, authorized retrieval plus generated drafts with human approval. Keep the same identity and data-access boundaries in both.
Draw this flow for B:
Operator -> authenticated backend -> scoped ticket adapter
-> permitted document retrieval
-> model adapter -> validated draft
-> human review -> existing send workflow
Label where tenant identity is verified, where credentials live, where data persists, and which components can fail independently. Show the model provider as a data-processing boundary rather than a magical box inside the application.
Worked tradeoff: option A has less generative risk, lower dependency count, and a simpler fallback. Option B may reduce drafting time but requires answer evaluation, output validation, provider controls, and stronger user training. If discovery shows that locating the right policy dominates effort, A may capture most of the value.
Exercise: write an architecture decision record with context, alternatives, decision, consequences, and revisit triggers. Include expected traffic, latency target, data freshness, customer operating skills, and the budget. Avoid a scored matrix whose weights secretly predetermine the answer; explain any hard constraint that eliminates an option.
Build-versus-buy challenge: a vendor integration saves development time but cannot preserve document-level permissions. Treat that as an architectural gap, not something a stronger prompt can repair. Ask whether the vendor supports the required identity and audit contract, whether an adapter can supply it, and who owns failures.
Failure walkthrough: the ticket API times out, the model provider fails, and the retrieval index is stale. For each case identify the user-visible behavior, retry boundary, operator signal, and fallback. A component diagram without failure behavior is incomplete.
Assessment: defend the decision to a skeptical customer in five minutes. Then introduce a new constraint: the customer cannot operate a separate queue service. Revise the architecture or narrow the workload. Your design must fit the customer's ability to own it after you leave, not only your ability to build a demo.