# Prereg H1: coding-agent evidence readout Status: fixed before launch. Do not edit the rules below while a window is open. The launch dates, the audience list and the SHA-256 of this file go in `docs/launch-record-h1.md`, not in this file. This file must not change after its SHA-256 is recorded. ## Hypothesis Security and platform leads at companies with 20-300 developers that use coding agents will pay for an evidence readout. The readout maps agent use to SOC 2 CC8.1 as a one-page pack. It also shows how the same evidence fits AIUC-1. Sources: datapce business-intelligence note 2026-10-13 (market C) and problem-search log 2026-10-12. Tiers $3.5k / $10k / $20k. Confidence medium-low. Demand is ASSUMED. ## What this test can show The test measures a first step: a verified request for a readout. A request is free and commits the sender to nothing. A PASS does not show that anyone will pay. Payment is a separate, later test. A KILL or INCONCLUSIVE result shows only that this page did not draw requests at this exposure. ## Measure The count of qualified readout requests by e-mail to jkn@datapce.com in the window. Exposure is the second measure: page loads of `/` in the web server log, and public posts of the page. ## Window The window is 21 days. Day 1 is the date in `docs/launch-record-h1.md`. The owner sets that date before any link to the page is posted. The window starts at 00:00 UTC on day 1. It ends at 23:59:59 UTC on day 21. The owner decides the result 12 days after the window ends. This leaves time for replies and confirmations. ## Qualified request A request is qualified if all six points are true. 1. It arrives by e-mail inside the window. 2. It comes from a company address. A company address is on a domain that is not free mail, and the owner can find the company website for that domain. 3. The sender is a security, platform, engineering or compliance lead. 4. The sender asks for a readout. 5. The owner replies within 2 working days. The reply asks the sender to confirm in writing: company, number of developers, coding agents in use, and the date of the next audit or renewal. 6. The sender confirms within 7 days of the owner reply. The confirmation shows 20-300 developers, at least one coding agent in use, and a named audit or renewal date. ## Never counts 1. Own contacts (people the owner knew before launch). 2. Any person the owner sent the page to by direct message. 3. A second request from the same company. 4. Vendors that sell to datapce, and GRC or security vendors and their staff. 5. Auditors, consultants and advisers. 6. Students and job seekers. 7. A request without a written confirmation. ## Exposure rules 1. A page load is a request for `/` with status 200 or 304 in the nginx log. Count 304 because the page sends `Cache-Control: no-cache`. 2. Remove the owner's own addresses and known crawler user agents. Non-target readers stay in the count. 3. A public post is readable without an account, links to the page, and has a date inside the window. 4. An audience is one place on the audience list in the launch record. The list names 3 or more separate audiences before launch. 5. Share the page only in public posts. Log each post (date, audience, link) in the private request log. 6. Log each request on the day it arrives. Record: date, company, role, developer count, class, counts or not, rule number. 7. After the window, publish the request log with company names removed. ## Measurement gate Complete and commit every prereg item before the page goes public. The items are: dates, audience list, posts plan and hash. The window must not open until the launch gate in `docs/launch-record-h1.md` is complete. Day 1 must come after the commit of the completed prereg items and after the deploy checks. Do not post a link to the page before day 1. Do not count page loads before day 1. The gate proves that the log shows the real client address, and that the log survives a pod restart. If the gate fails, fix the deploy first. Do not open the window with unmeasured exposure. ## Thresholds | Result | Rule | Reason | |---|---|---| | PASS | 3 or more qualified requests from 3 companies | Test A3 in the business-intelligence note passes at 2 scoping calls in 14 days. A request is weaker than a call and the window is longer. So the bar is 3. | | KILL | 0 qualified requests, 500 or more page loads and 3 or more audiences with a public post | At the assumed rate, zero requests in 500 loads is rare. See the table below. | | INCONCLUSIVE | Everything else | 1 or 2 requests, or exposure below the floor. The data cannot separate demand from no demand. | SOC 2 or DPA condition: a condition reply is an e-mail inside the window, from a company address (point 2), that makes a datapce SOC 2 report or a datapce DPA a condition before the sender will ask for or buy a readout. A condition reply counts here even when it is not a qualified request, and it never counts toward PASS. The "Never counts" list still applies, except item 7: a condition reply needs no written confirmation. One company counts once. Take the set of qualified requests and condition replies of the window. Suppose it has at least 1 company and every company in it makes the condition. Then the result is KILL of the services path. This rule applies at any exposure and overrides PASS. It follows test A3 in the business-intelligence note: "every reply demands datapce's own SOC 2/DPA first" closes the services path, fails the 2027-03-31 gate early and starts the vendor conversations now. ### Error rates (ASSUMED rate) The rate of 3 requests per 200 target loads (1.5%) is an ASSUMPTION. No source gives it. Page loads include bots and non-target readers. The share of target readers is unknown. Chance of zero requests at the assumed rate (false KILL): | Loads | All loads are target | Half are target | One quarter are target | |---|---|---|---| | 200 | 5.0% | 22% | 47% | | 500 | 0.05% | 2.3% | 15% | So the floor is 500 loads, not 200. Chance of 3 or more requests (PASS), before the checks in "Qualified request", for a Poisson count: | Mean requests | Chance of 3 or more | |---|---| | 1.5 | 19% | | 2.5 | 46% | | 3 | 58% | | 7.5 (the assumed rate over 500 loads) | 98% | The checks in "Qualified request" lower these chances. A true positive can still end INCONCLUSIVE. ## Second window 1. Run a second window only after an INCONCLUSIVE result. 2. The second window has the same rules, the same floors and a new audience list. 3. Count only requests and posts dated inside the second window. Do not add the counts of the first window. 4. If the second window is PASS or KILL, that result stands. 5. If the second window is INCONCLUSIVE, stop. The idea is not confirmed. Do not build the readout on this evidence. Do not run a third window. ## Owner actions | Result | Action | |---|---| | PASS | Reply to each request within 2 working days. Quote a fixed scope and price. Build the readout for the first scoped request. The 2027-03-31 gate of 3 engagements stands. | | KILL | Take the page down within 3 days. Record the result in the research log. Close market C. Keep the engine as an open asset. Start the vendor conversations. | | KILL (SOC 2 or DPA condition) | Close the services path. Record that the 2027-03-31 gate fails early. Start the vendor conversations now. Take the page down within 3 days. Record the result in the research log. | | INCONCLUSIVE | Run the second window. Do not change the rules. | ## Open assumptions 1. The 3-request bar, the 500-load floor and the 3-audience floor are ESTIMATES, not measured rates. 2. A1 is untested: SOC 2 auditors now ask for evidence of AI-coding-tool changes under CC8.1. If A1 is false, market C has no 2026 trigger. 3. AIUC-1 is a standard for companies that sell AI agents. It is not required of a company that only uses coding agents. 4. AIUC-1 E015 requires logs of agent inputs, outputs and retention. Per-decision rule records are the stronger form, not required. 5. No buyer has been contacted. The control map has no auditor review. 6. The vendor gap ("the event does not say which source matched") comes from a read on 2026-10-13. Re-read it on launch day.