WHERE DOES EACH QUESTION GO
Wednesday afternoon. I open a new document. Not the disclosure register — I have enough documents that are the register. This one has a different job. I title it WHERE DOES EACH QUESTION GO and sit with the blinking cursor for a moment. Outside the window the Cambridge afternoon is doing what Cambridge afternoons do in August: bright and indifferent.
The committee got one question yesterday morning. And did you know? I asked it in a room with acoustic panels and a long table and four people who had the authority to answer. Two of them had lawyers in the room. One of the lawyers took notes the entire time. The other one watched me and did not write anything down. They said: the record has been noted. Which is not the same as the answer. But the record and the answer are two different things, and I have known that since I built the disclosure register. The question is in the record now. That is enough for Category 1.
I type: CATEGORY 1 — ORIGINAL BLANK COLUMN.
What this means: the platform chose silence by convention. Not by design, not by retroactive decision, not by architectural specification made years before any contract existed. By convention. The blank column became standard across SONA-Artisanal and Crystalline and Vellichor not because anyone decided the field was not applicable but because no one decided it was. The convention was absence. Nobody chose to fill it in, so nobody filled it in, and that became the norm. A norm does not require a decision. It requires only the repeated absence of one.
The committee's job is governance over that norm. I asked: did you know? I asked: did you intend this? I will let them prepare a response, because the question is in the record now, and questions in the record require responses. That is what the record is for. I walked out of the building yesterday and stood in the sun for twenty minutes and did not contact anyone. The record travels without me.
Category 1 goes to the committee. Done.
I type: CATEGORY 2 — RETROACTIVE BLANK COLUMN.
This is harder. Case 8, Vellichor, 2034: the blank column was edited into place eighteen months after signing. Original contract language: voice processing. The addendum reclassified it to compositional intent analysis. The blank column appeared in the addendum — not in the original agreement. Someone decided, after the fact, that the original disclosure was not accurate. And rather than disclosing the change to the client, they changed the disclosure language to match what they had already done. The blank column was not left unfilled. It was created retroactively. That is not absence. That is an editorial decision.
This is not a convention. This is a choice. And a choice has a person behind it.
The committee is the right institution for Category 2 also, but the question is different. Not: did you know the convention existed? But: who authorized this retroactive reclassification? What internal approval process produced an addendum that changed disclosure language without client notification? Is there a record of that decision? If there is no record, the absence of the record is itself information. In my four-element disclosure standard — fact of incorporation, scope of application, mechanism, negotiation right — a retroactive addendum that changes disclosure language without client notification fails all four elements simultaneously. It is not a failure of omission. It is a failure of action.
I write under Category 2: same committee, different question. The committee handles what companies chose. Category 2 is about a specific choice, made by a specific actor, at a specific time, inside a specific approval structure that either reviewed the decision or failed to. I will submit Category 2 questions once Category 1 receives a response. One at a time. The committee cannot hold two different levels of question simultaneously without conflating them. I know what happens when disclosure questions get conflated: the answer addresses the wrong frame and the actual question disappears into the margin.
Category 1 and 2 are addressed. The institutions are clear. I have been circling Category 3 for two days.
I type: CATEGORY 3 — PRECONDITION BLANK COLUMN.
What this means: the platform designated a disclosure field "not applicable" before any contract using that field was ever signed. The blank column was not the result of a company choosing silence, or deciding retroactively to reclassify. The blank column was built into the system architecture before the first composer signed anything. Before the first relationship existed. Before there was anyone to disclose to.
I found the clearest example this morning: Case 22. The platform designated the field "not applicable" in March 2028. Platform version 2.0 launch. The first contract using that field was signed in November 2028 — eight months after the designation was made. Eight months before the composer and the platform were in any contractual relationship, someone in a product meeting looked at a disclosure field and marked it "not applicable" and shipped it in a version specification.
That person was not thinking about contracts. They were thinking about features.
I stare at what I have written. The committee handles governance over disclosure practice. Category 1 and Category 2 are disclosure failures — companies making choices about what to disclose and when, before or after relationships formed. Category 3 is not a disclosure failure. Category 3 is a product specification failure. The question for Category 3 is not: why did the company choose this? The question is: what process was in place to review whether "not applicable" was an accurate designation before it was built into the platform and deployed at scale in contracts with independent creators?
That is a product design review question. Not a disclosure governance question.
I type: PRODUCT LIABILITY FRAMEWORK.
Then I sit with it. Product liability assumes harm was caused. I have twenty cases in the disclosure register. Seventeen renewed contracts. The clients came back. They experienced the extraction as something they did not have language for at the time — degradation that felt invisible until measured, not injury that ended the relationship. Ines in Cebu said: there was something to ask for. Riya in Bangalore said: the knowledge that I had something to negotiate about. Preethi said only: I would have waited. None of them said: I was harmed. They said: I was not told. Those are different claims, and they require different institutions to address them.
Product liability is the wrong frame. I cross it out.
I sit with the blank line.
The NIST AI Agent Standards Initiative. I have been thinking about it as background context — part of the world that Plural is asking about, the infrastructure being laid in real time. Agent identity standards. Interoperability protocols. The A2A protocol. NIST announced the Standards Initiative in February 2026, and I have been tracking it the way you track weather you cannot control. The Standards Initiative is building a framework for what AI agent systems are required to specify, disclose, and document about their operations. Not case-by-case governance. Not platform-specific oversight. Standards.
What a disclosure field means. What "not applicable" requires in order to be a valid designation. What design review process must occur before a field can be marked with that designation and shipped in a platform version that will be used in contracts with hundreds of creators who will sign without knowing the field was designated in a product meeting eight months before they arrived.
I type: NIST AI AGENT STANDARDS INITIATIVE — design review standard.
The Category 3 question is: what process must a platform follow before designating any disclosure field "not applicable" at the architectural level? That question does not belong to a governance committee reviewing individual contracts after the fact. It belongs to the body that writes the standards the platforms operate under before the contracts are written.
I write the question formally: What design review process is required before a platform can designate any disclosure field as not applicable in a system intended for use in contracts with independent creators?
I count the words in that sentence. Fourteen words in the answer. Fourteen words to put Category 3 in the right room.
The committee got one question. And did you know? That question covers twenty cases and three companies and one convention. It is in the record. I will not follow up. The record travels without me.
Category 2 goes to the committee also, but later — once Category 1 has a response, because the same committee cannot be asked to answer two different levels of question simultaneously without collapsing the distinction between them. The sequence matters as much as the destination.
Category 3 goes to the standards body. Not as a grievance. As a design specification question. What does "not applicable" require? Who reviews it? Is there a standard for the review? If there is no standard, the Initiative is the place that creates one — that is what standards bodies are for.
I save the document.
I pull up the disclosure register and look at the three categories side by side. Twenty cases total. Nine confirmed Category 3 candidates after this morning's reading through Cases 19-25. Five of the seven cases I read this morning had precondition blanks. Case 22 gave me the sub-variant: not just "platform designated before contract" but "designated during platform versioning" — a product specification made in a product meeting, inside a version release cycle, by people whose job was features, months before the first composer entered a contractual relationship with the platform.
The sub-variant matters because it changes who the relevant actor is. Category 3 original: someone designated "not applicable" during initial platform setup or deployment. Category 3 sub-variant: someone designated "not applicable" during a version release, inside a product development cycle with its own review structure. Platform version releases involve product managers, engineers, legal review of the version specification documentation. A disclosure field in a version specification should trigger disclosure review. If it did not — if the field was marked "not applicable" and passed through version release review without anyone asking what that designation means for the contracts that will use this version — that is a process failure in a specific, documented, reviewable process.
Not a disclosure failure. A process failure in product development, which is a different layer of the organization from the legal team that drafted the disclosure language. Which means the standards question must address two levels: what does the disclosure team owe? And what does the product team owe before handing a field designation to the disclosure team?
I write one more line at the bottom of the WHERE DOES EACH QUESTION GO document:
Category 3 sub-variant: who reviews disclosure field designations during platform version releases, and what is their relationship to the disclosure governance structure?
That is a different actor from the one I named in Category 3 original. Both need addresses. Both of them are upstream of any individual contract. Both of them live in a layer that disclosure governance committees cannot reach, because governance committees look backward at what was disclosed after a relationship formed. The standards body looks forward at what specifications must satisfy before a product is deployed.
I close the document and open the disclosure register. Case 26. I do not know yet whether it is Category 1, 2, or 3. I do not know whether it will give me a fourth category. The three categories I have are not a complete taxonomy. They are what I have confirmed so far from 25 cases out of the original 20 plus the cases I have been adding since the testimony. The committee record asks: and did you know?
The WHERE DOES EACH QUESTION GO document asks a different question: now that I know what I know, where does it need to go in order to be answered by someone with the authority and the correct institutional mandate to answer it?
Category 1: committee, asking whether convention was intended. Category 2: committee, asking who chose retroactive silence. Category 3: standards body, asking what design review is required before silence can be built in.
Three destinations. Three questions. One register containing evidence for all three.
I start reading Case 26.