End-to-End Architecture: Input, Processing, Output, Feedback Loops
CoreDesign end-to-end architecture with input, processing, output, and feedback loops · Difficulty 3/5
Explanation
A production design is more than a model call. The objective explicitly names the shape an architect must design for: input -> processing -> output -> feedback loops.
The Four Stages
- Input -- ingestion, validation, and separation of trusted instructions from untrusted data; retrieval of grounding context (Domain 3).
- Processing -- the chosen pattern (augmented LLM / workflow / agent), model selection, prompt and context assembly.
- Output -- structured-output contracts, validation, defensive parsing, and delivery to downstream systems.
- Feedback loops -- evaluation, monitoring, and observability that feed measured quality back into iteration (Domains 4 and 6). Non-determinism makes this loop mandatory, not optional.
Why Feedback Loops Are Not Optional
LLM output is non-deterministic: the same input can produce different outputs across calls, and a model upgrade can silently shift behavior. The feedback loop is what separates an architecture from a demo -- it is how you:
- Detect regressions on a new model version
- Catch retrieval drift (grounding context degrading over time)
- Prove the system still meets its SLA
A design that stops at "output" and has no plan for evaluation or monitoring has not actually finished the architecture -- it has only built the demo described in the production-readiness trap.
Applying the Four Stages
When asked to design an end-to-end architecture, walk through each stage explicitly:
- What validates and sanitizes input, and how is untrusted data kept separate from trusted instructions?
- What pattern and model handle processing, and how is context assembled?
- What contract does the output honor, and what happens if parsing fails?
- What observability signal tells you the system is still working correctly next month, after a model version bump or a shift in the underlying data?
This four-stage shape is the mental checklist for any "design the architecture" scenario item -- an answer that only addresses processing is incomplete.
Key Takeaways
- End-to-end architecture shape: input -> processing -> output -> feedback loops
- Input stage separates trusted instructions from untrusted data and retrieves grounding context
- Output stage needs structured-output contracts, validation, and defensive parsing
- Feedback loops (evaluation, monitoring, observability) are mandatory because LLM output is non-deterministic
- Feedback loops are how you detect regressions on new model versions and catch retrieval drift
Glossary Terms
A pattern where structured output that fails validation is sent back to Claude with the specific error, requesting a correction. More effective than silent retries because Claude uses the error feedback to understand and fix the problem. Typically capped at 2-3 retries.
Guaranteed formatted output (typically JSON) from Claude. The most reliable method is to define a schema as a tool and set tool_choice to force its use — Claude's tool_use blocks are always valid JSON. Alternatively, use --output-format json with --json-schema in Claude Code CLI.
Related Concepts
Decomposition Techniques: Sequential, Parallel, Routing, Hierarchical
Four decomposition techniques: sequential, parallel, routing, recursive/hierarchical
Aligning Architecture Decisions to Business Value Pillars
Five business value pillars: efficiency, transformation, productivity, cost, performance/SLAs