How do you decide which assertions belong at the service interface rather than through the screen?

This is an allocation question, not an automation question. Assume the rule is going to be checked automatically; the decision is which interface produces the evidence. Framing it as "where does the oracle live" turns an argument about taste into a question with an answer. ## What each interface can and cannot witness Only the screen can witness what a person perceives: that text is actually rendered rather than merely returned, that a control is present, enabled and reachable, that the layers between the service and the eye are wired together. Only the service interface can witness the machine contract with any precision: the exact status code, the stable error code in an envelope, what was persisted, what a replay does, what happens under concurrent submissions, what the tenth page of a collection contains. Between those two poles sits a large middle where either could technically assert the rule — a validation message, a rounding rule, a permission-shaped refusal — and that middle is where placement policy earns its keep. ## The cost model Compare four costs, not one. Run time is the obvious one: a service call is typically two to three orders of magnitude cheaper than driving the same rule through a rendered page, and the difference compounds across a permutation set. Authoring cost follows the same shape. Upkeep is where the gap widens further, because a screen-level assertion is coupled to layout and interaction as well as to the rule. And diagnosis cost is the one teams underweight: when a service assertion fails it names a field and a value, while the same rule failing through a screen produces a step that could not proceed, and someone spends an hour deciding whether the defect is in the rule, the rendering or the harness. ## The rule an eleven-person team can actually apply A policy that lives in one person's head produces eleven habits. On an airline seat-map service the written rule was three lines: an assertion whose oracle is a value in a response lives at the service interface; the screen asserts only what a person could observe; each rule is asserted at exactly one level unless a named risk is recorded next to the duplicate. That last clause matters more than the first two, because "assert it at both levels to be safe" is the default drift, and it doubles upkeep while adding almost no information. Reviewing new cases against three lines is something a team will actually do; reviewing them against a principle nobody wrote down is not. ## The counter-risk Push every assertion down and you can reach the state where the service suite is entirely green while the product does not work — the classic "integrated tests pass, nothing is wired" failure. The screen suite's remaining job is exactly that gap: a small number of end-to-end journeys through the paths that carry the most value, asserting that the pieces connect and that a person sees the outcome. Small and deliberately chosen, because those cases are the expensive ones. The seat-map team's stale-cache defect is the cautionary tale on the other side: the service cases were green, the screen cases were green, and nobody had asserted the consistency rule between the write and the view it fed — placement policy cannot save you from a rule nobody wrote at any level. ## Migrating rather than declaring An existing suite is not restructured by decree. The workable sequence is to attach the policy to change: when a screen case fails or its area is touched, decide whether its assertions belong lower, move the ones that do, and leave the journey with the checks only it can make. Track the rules, not the case counts — a coverage map keyed by business rule shows duplication that a count of cases hides entirely, and it is the artefact that makes deleting the redundant copy an easy decision rather than an argument. ## What to measure, and what is contested The honest measure is where defects would have been caught. Reviewing escaped defects and asking at which level the cheapest possible catch existed tells you whether the policy is calibrated; a rising count of service cases tells you nothing. It is worth being explicit in an interview that the familiar layered-shape heuristic is a heuristic and is genuinely contested — teams with strong contract boundaries and teams with a monolith and a fast environment reach different, defensible distributions, and the useful version of the argument is about oracle location and cost, not about hitting a prescribed ratio. ## Organisational edges When different groups own different levels, placement becomes a hand-off protocol rather than a preference: moving an assertion down means someone else now owns it, and if that transfer is not explicit the rule quietly stops being asserted anywhere. The same applies when a rule sits behind a contract between two services — placement then involves deciding which side's suite is the rule's home, and recording it, so that a future change to the rule updates one suite rather than surprising two.