Your bid documents are not marketing data. Treat them accordingly.

Four statements. If they answer your question, you are done here.

Written for the person deciding whether to send a package, not for the person who has to sign off on the architecture. The technical record is below and nothing has been removed from it.

The document pipeline is a command line program on your own machine.

Ingest, rule evaluation, validation and report generation all run locally. You point the ingest command at a package directory. It opens the PDFs in place, pulls the text layer with page and coordinate positions, segments the text by CSI MasterFormat section numbering and locates scope markers by pattern matching. Your originals are not moved, not copied and not modified.

Where a model reads, the run says so, names the vendor, and cannot be told to be quiet.

Before anything is sent for a package, a block prints naming each vendor, the full model identifier that will receive the material, and each file by name. Not a family name like "the latest model", because that does not say what actually ran. Not a generic banner about AI, because a reader cannot act on one. The point is that you can take that list to your counsel or to your district contact and get a yes or a no on the facts.

Transmission disclosure for <package>

The following will be sent to model APIs outside this machine:

  <vendor> (<model identifier>)   2 files

  engine_output.json
  document_model.json

Responses are cached under out/cache/ on this machine. Nothing is
committed to the repository. This is asked once per package, and again
if the file set changes or the recipients above change.

The shape of the block, with the package, vendor and model identifier standing in for the real ones. Where two files share a name, the colliding entries take one more folder from the left, so an addendum folder's drawings file and another addendum folder's drawings file are told apart in the terms the district itself issued them.

There is no way to turn the disclosure off

No flag, no environment variable, no yes-to-everything switch. The project's own words for why, from the amendment that requires the disclosure:

There is deliberately no suppression flag, no environment variable, and no --yes. Suppressing the prompt is the first thing anyone scripts, and a disclosure that can be disabled is a disclosure that will be. src/bre/narration/copilot/disclosure.py

That is enforced in three places rather than requested once. The gate lives in the session layer and not only in the command line entry point, because a gate that lives in one caller is a gate the second caller does not have. A boolean argument would itself have been the suppression flag, so what the gate requires instead is the consent record and the current file set digest. And the recipient list is derived from the vendor and model constants rather than accepted as a parameter, so the list compared at the gate is necessarily the party that will receive the material.

The promise about your key is not kept by this page. It is kept by the schema.

If you connect your own model account, the key stays in your browser. It is sent per request to the endpoint that uses it: bound to one local constant, placed in one header on one outbound request, and then the request ends and the binding is gone. It is never logged, never cached, never echoed into a response or an error message, and never interpolated into a string, a template literal or a URL.

That is the kind of sentence every product writes. Here is why this one is checkable. The database schema has no column the key could be written to, and the prohibition is written into the schema file itself rather than into a design document nobody opens:

THERE IS NO API KEY COLUMN IN THIS SCHEMA, AND THERE MUST NEVER BE ONE.

The product's published security page states that a user's Anthropic API key is
never stored on the server. That key lives in the user's browser and is sent per
request to the chat endpoint, which uses it and forgets it. A promise like that is not
kept by the security page, it is kept here. The moment a column named api_key,
encrypted_key or anything of that shape appears in the users table, the published page
becomes false, whatever the code around it does.

If a future change appears to need one, that change is wrong. Adding a column is easy
and quiet, which is exactly why the prohibition is written in the schema rather than in
a design document nobody opens. test/schema.test.js enforces this by reading
PRAGMA table_info for every table and failing on any column matching /api[_-]?key/.

The last sentence is the load-bearing one, and it is true. test/schema.test.js applies the schema, then reads PRAGMA table_info for every table and asserts that no column name matches /api[_-]?key/. It asserts the same for /anthropic/. A second test asserts the comment above is still in the file and still says why. So the day somebody adds a quiet column called encrypted_key, the build goes red before the page becomes a lie.

What is written down about a request, and what is written down about a visit.

First-party measurement on this site

This site measures itself, and the whole of that is one file you can open: /assets/bre.1eea7f485a.js. This is everything it does.

1. Named events, same origin only. One page-view event per route, named for the page rather than emitted as a generic pageview with a path, plus one interaction event for any element carrying a data-ev attribute when it is activated. Each event is dispatched as a DOM CustomEvent and held in memory for the life of the page. Nothing is transmitted anywhere today. The collector is written and tested but not deployed, so the endpoint constant in the script is null and no request is made. When it is turned on it will post to a path on this site with navigator.sendBeacon. There is no other recipient, and there is no second setting that could change that: the content security policy below permits requests to this origin only.
2. A random session identifier that dies with the tab. Nine random bytes from the browser's own CSPRNG, held in sessionStorage under the key bre_s. It is generated in the browser, never derived from anything about the person, does not survive the tab, and is not joinable with anything. Where storage is unavailable it degrades to the constant nostorage and nothing breaks.
3. Device category, and referrer host only. The device category is one of mobile, tablet or desktop, computed from the window width. The referrer is reduced to a hostname, or to the literal direct or internal. The full referring URL is never sent, because a full referrer can carry a search query or a document title from wherever the visitor came from, and this site has no business holding either.
4. No cookie, no cross-site profiling, no advertising pixel, no third-party script. Nothing on this site loads from another origin. There is no identifier that outlives the tab and nothing that joins a visit to a person.
5. Form field values and document contents are never sent as events. Only short labels are ever attached, truncated to 64 characters. The pilot form reports its submission as an event carrying no payload at all.
6. The content security policy allows scripts from this origin only. script-src 'self' and connect-src 'self' are set in _headers, so a beacon has nowhere else it could go. That policy currently blocks the hosting provider's own analytics beacon, which is injected into the response rather than written into these files. The site loses that measurement and keeps the guarantee.

A page that tells estimators their documents are not marketing data cannot be carrying a third-party tracker, and a header that fails loudly is what stops that eroding by accident rather than a promise to remember.

When you are asked again, and what declining does.

Consent is recorded per package, and it is recorded against the material rather than against a filename. Four cases decide whether the disclosure fires a second time.

1. When the contents change. The consent record holds a hash over the bytes of every file, not their names. A revised addendum that keeps its filename produces a different hash and re-asks. Consent to send version one is not consent to send version two.
2. When the recipients change. Approving one vendor is not approving that vendor plus a second party. Vendors, model identifiers and the file list are disclosed together as one statement, and a gate that watched one third of what it showed would not have re-asked.
3. When the record cannot be read. Missing file, unreadable file, invalid JSON, wrong type, missing field, mismatched hash: every one of them means ask again. It fails closed on purpose. A false alarm costs one keystroke. The other kind of error is a client's bid package leaving the machine without anyone being asked.
4. Not when the file order changes. The hash is order independent, so a folder listing files in a different order on a different machine does not re-ask. A prompt that fires for no reason is a prompt people learn to click through, and a disclosure that gets clicked through has stopped disclosing anything.

Declining is a correct outcome and not a crash: the estimator who reads the file list and decides a district's package does not leave their machine has used the feature correctly. A caller with no terminal attached is treated as having declined, because no answer is not a yes and defaulting the other way would transmit a package because a pipeline had no input attached.

No SOC 2. No ISO certification. No penetration test. No attestation of any kind.