Scoring Trade-Offs: Unit Economics and NFRs

Framing build, buy, partner, and stop establishes a reviewable set of delivery options, but a review board still needs a recommendation supported by explicit trade-offs and evidence. Trade-off scoring provides a structured way to compare architecture options using explicit assumptions, evidence, and uncertainties that can be challenged without reopening the entire design discussion. The scorecard should evaluate more than token costs and vendor pricing. It should connect each score to the strength of its supporting evidence, reduce confidence in claims that lack measurable evidence and risks without assigned responsibility, and evaluate economics using cost per task that meets the defined success criteria rather than raw token or API consumption.

A scoring frame stays stable when it separates what success looks like from what it takes to operate. KPIs and quality attributes define the what. Non-functional requirements (NFRs) and governance or security effort define whether the option can run inside constraints, and what that costs in operational burden. Scoring also depends on provenance: each row in the rubric should cite an upstream evidence source, a measurement plan, feasibility checks, or a capability assessment. A score without evidence counts as unknown, and unknowns carry an explicit penalty unless a planned experiment resolves them.

The following table shows a rubric layout that keeps option scores and evidence strength visible in the same view:

Unit economics as cost per successful task

Unit economics at qualification time comes down to one primary measure: cost per successful task. That ties spend to outcomes instead of activity.

A successful task needs an operational definition. Typically that includes a correctness threshold, acceptable latency, required citations or policy references where applicable, and an oversight outcome, like a human approval rate that stays within a budgeted band.

Cost per successful task is better ...