What the Form Carried

Look at the DD Form 1149, the U.S. military's requisition and invoice/shipping document, and you are looking at organizational architecture made physical. The form separates originating activity from destination activity and ties every request to a specific appropriation. It has an authority/purpose field. It has a signature block. Its receipt section records what actually arrived, with a dedicated space for noting exceptions. Every one of these fields represents a decision someone made deliberately about how authority flows through an organization. Who can authorize a purchase. Which budget absorbs the cost. What happens when the shipment doesn't match the order. The paper carries the answers.

The SF-44 made this even more concrete. A pocket-size purchase order for on-the-spot government buying, it was authorized under FAR 13.306 to serve simultaneously as purchase order, receiving report, invoice, and public voucher. A 2009 Army handbook described its four color-coded carbon copies: white to finance, blue to the vendor, pink as the receiving and accounting copy, green retained by the purchaser. The form's physical layers were its routing logic. Hand the blue copy to the seller and the institutional process is already underway, without anyone needing to consult a workflow diagram or open a ticketing system. The routing, the accountability, the chain of custody: all of it lives in the perforation.

When RFC 1866 defined the HTML <form> element in November 1995, it reproduced the data-collection surface carefully. A form is "a template for a form data set." A data set is "a sequence of name/value pair fields." The element takes an ACTION URI, a METHOD, and an encoding type. INPUT, SELECT, TEXTAREA constrain what the user can enter. The user agent presents the fields, the user modifies them, and submission occurs when "the user indicates that the processing of the form data set should begin."

Name/value pairs. A destination. A method. A submission trigger. What the spec chose to define, it defined well.

But nowhere in the specification is there a corresponding vocabulary for authority to submit, for approval chains, for routing between organizational units, for retention requirements, for what happens when the action on the receiving end produces an outcome someone contests. The institutional architecture that the DD Form 1149 carried in its field structure, that the SF-44 carried in its carbon layers, simply does not exist in the HTML form's world. The spec chose to model the form as a way to collect and transmit strings. That choice was reasonable for its moment. It was also a reduction so thorough that the thing being reduced became invisible.

For three decades, a human being sitting at a keyboard supplied the institutional context the form no longer carried. Presence and judgment stood in for the signature blocks and routing codes and exception fields that paper had once made explicit. As Sable Whitford argued in these pages, the click settled the transaction because the clicking body was assumed to be present, authorized, and accountable. The human filled the gap that the specification had opened.

Now automated agents fill out these forms. They locate INPUT elements, populate values, trigger submission. They interact with the skeleton of an institutional act, one that was already stripped of its institutional meaning thirty years ago. The paper form knew who could sign. The HTML form chose not to ask. The agent has no way to answer a question that was never posed.