Don't ask for what you already know.

The lazy field is the expensive one.

Here is a design rule worth obsessing over, never ask a user for data your system can retrieve itself. Every field you ask for is a small tax, paid by every user, on every interaction, for the life of the product. The lookup costs you an hour, once. The question costs them forever. Run the multiplication and the lazy field is always the expensive one.

A form field looks free. It costs the user five seconds, maybe, plus a small context switch, plus the chance of a wrong answer that somebody downstream has to live with. Retrieving the same value costs the builder real work, a join, an integration, an inference. Under a deadline, the field wins every time.

But the field's cost recurs and the builder's cost does not, and the recurrence is enormous. One five-second field, in a product with two hundred users touching it ten times a day, burns roughly a thousand hours of human time a year. For one field. The build-side fix was an afternoon.

Nobody decides to tax their users. Forms grow because asking is one line of markup and retrieving is engineering, so under schedule pressure the form is where cost gets quietly externalized. Each field is individually defensible, the sum never gets reviewed. It is the same pattern as alert feeds multiplying in an ops room, none of the fields were chosen, exactly. They accumulated.

There is an organizational half too, the person who owns the form is almost never the person who fills it in two hundred times a month. The cost and the decision live in different rooms.

You know these forms. The incident form that asks which service is affected, when the alert that opened it named the host. The one that asks for a severity the monitoring system already declared, and a start time the platform watched happen. The checkout that asks whether your card is a Visa, when the first digit of the number you just typed says so. The support portal that asks for your account number while you are logged in to your account.

None of these are asking for information. They are asking the user to be the integration.

The rule is one sentence, do not ask a user for data your system can retrieve itself. The first corollary handles uncertainty, when you can retrieve a value but might be wrong, prefill it and let the user correct it. A correction costs less than an entry, and unlike an entry, a correction teaches the system something.

The second corollary is why this compounds beyond any single field. The first retrieved field resets the bar, once "the system fills it" is the default, every new feature starts from "what can we already know?" instead of "what should we ask?". That is the real payoff. The drops do not just add up, the rule changes what the builders reach for first, and after that the bucket fills itself.

This rule has driven Signal9's design since day one, and its limit case is our favorite proof, a Signal9 alert record requires zero user input. It arrives parsed, identified, grouped, and timed from the raw signal, carrying the exact firing time, the resolved system, the readings, and its own history, detail no manual entry could supply at any speed. The rest of the platform follows the same slope, the incident that opens with its system, service, severity, and start time in place, the inventory nobody types in, the feedback report the assistant drafts from what it just watched. And we still catch ourselves violating the rule, which is how we know it is a rule and not a habit.

Should a form ask for information the system already has? No. Retrieve it, and if the retrieval might be wrong, prefill and let the user correct it. Asking costs every user on every interaction for the product's life, retrieving costs the builder once. A correction is cheaper than an entry, and it teaches the system, which an entry never does.

Why do forms ask for data the system already knows? Deadline economics, not malice. Asking is one line of markup, retrieving is a join, an integration, or an inference. The cost of asking is externalized to users in increments too small to bill, and the person who owns the form is rarely the person who fills it in two hundred times a month.

How does Signal9 apply this rule? At the limit, whole record types ask for nothing, a Signal9 alert record is built entirely from the signal, no user input, and arrives with the exact timing, the resolved system, the readings, and its history attached, more than manual entry could ever supply. Downstream records inherit the habit, an incident born from an alert opens with its system, service, severity, and actual start already in place, and prefilled values are correctable, with corrections treated as signal.