Designing for Partial Results: When Incomplete Data Is Honest Data
Systems that require all-or-nothing computation fail users at the worst possible time. Partial result architecture delivers honest value even when sub-tasks fail.
An audit that takes 5 minutes and involves 16 agents, Claude API calls, and external HTTP probes will sometimes have a sub-task fail. The architectural question is not "how do we prevent sub-task failure" — it is "how do we deliver maximum honest value even when a sub-task fails." Partial result architecture is the answer.
The All-or-Nothing Failure Mode
Systems designed without partial result support fail catastrophically when any sub-task fails. An audit that is 95% complete but fails on contradiction detection returns no audit at all. The user gets a spinning indicator and eventually an error. Five minutes of computation are discarded. The failure of one Claude API call voids the entire infrastructure analysis.
The GTL Approach: Compute What You Can, Report What You Cannot
GTL partial result architecture inverts the failure model. Each agent is designed to succeed partially: compute every sub-score that is possible given current dependencies, log every sub-score that cannot be computed and why, return a partial envelope with the computed sub-scores and a list of exclusions. The Infrastructure Agent aggregates partial results into a partial audit, and the partial audit is stored and shown to the user — with full transparency about what was excluded.
●In SiteNexis: if the Machine Trust Agent's contradiction detection fails (Claude API timeout), it returns contradictionAbsenceScore: null, reason: "claude_timeout". The remaining four Machine Trust sub-scores are still computed and returned. The Machine Trust Score formula excludes the null sub-score from the denominator. The result is honest and useful.
Implementation Pattern: Try-Skip-Log
The agent implementation pattern for partial results is: try the sub-task, catch any error, log the failure with context, skip the sub-task and mark it as excluded, continue to the next sub-task. Never let a single sub-task failure propagate as an unhandled exception that terminates the agent. The agent succeeds if it processes at least one sub-task successfully and returns a GTL envelope reflecting exactly what succeeded.
Partial Results Are Not Technical Debt
Teams sometimes treat partial result support as technical debt to be cleaned up later — once the system is more reliable. This is backwards. Partial result architecture is what makes a system reliable. A system that delivers partial honest results under adverse conditions is more trustworthy than one that delivers either complete results or complete failure. GTL makes partial results a first-class output, not a fallback.
GTL Systems — Part 5 of 10