# 0006 — Ingest is an interface, not an appliance **Status:** Accepted **Resolves:** whether a publisher must sign at the customer's premises, on hardware the company supplies, or may sign in a virtual machine fed by the customer's own API. The question was never posed to the substrate — which has always taken an interface — but was answered the other way in the commercial model behind [QRCA-FIN-001](../corporate/QRCA-FIN-001-ip-valuation.js), and an unexamined assumption that reaches a valuation is one worth writing down. ## Decision A publisher ingests through the `Source` interface. The supported deployment is a **virtual machine running the substrate, reading the customer's historian over an API the customer exposes.** No hardware is supplied, installed, or carried as a cost of service. Three commitments follow: 1. **The signing key belongs to the publisher, wherever it runs.** What the signature establishes is that *this publisher said this*, and it establishes that identically in a rack, a cloud tenancy, or a cabinet on a turbine deck. Location is an operational choice, not a property of the record. 2. **Provenance is declared, never implied.** A record carries an `attestation` naming its time source and provenance. An API-fed observation says so. It does not borrow credibility from the room the signer sat in. 3. **Device-level provenance, if a counterparty ever requires it, is a separate product with a separate attestation.** It is not the base case, and it must not be smuggled into the base case by describing the ordinary deployment as though it had hardware properties it does not have. ## What prompted this A reading of the valuation's cost line. The memorandum carried $1,200 a site a year for "an edge appliance at roughly $1,500 on a five-year life… a secure element and an interface to telemetry the facility already produces," and before that $14,000. Asked why the equipment was there at all, no answer survived contact with the trust model. ## The reasoning **The appliance sits downstream of the boundary it appears to defend.** Put the box in the customer's plant, on the customer's network, reading the customer's historian, and it signs whatever that historian tells it. A customer willing to misreport can misreport upstream of the signer — by configuring the historian, by adjusting a scaling factor, by feeding the tag a different tag's value. The appliance does not witness the sensor; it witnesses the same database an API would expose. It is a signing box in a place that sounds reassuring, and against the adversary that matters — a dishonest publisher — it buys nothing an API does not. **What the receipt actually provides never depended on the hardware.** The properties this system sells are non-repudiation and tamper-evidence *after* the statement: the publisher cannot later change what it said, and cannot say different things to different parties. Those come from the append-only log, the anchored root, and witnesses who refuse a rollback or an equivocation — decisions 0001 and 0003 — and every one of them holds identically whichever machine held the key. The appliance was never load-bearing for the claim; it was load-bearing for the *impression* of the claim, which is worse than useless in a system whose entire argument is that nothing needs trusting. **The code never believed in it.** `service/publisherd.py` takes a `Source` and calls `observe(interval)`; the only working implementation is the HTTP market ingest under `ingest/`. Nothing in `src/` has ever referenced a device, a secure element, or a serial interface. The hardware existed in one commercial document and nowhere in the substrate — which is the clearest possible evidence that it was decoration rather than architecture. **Why declaring provenance is the honest substitute.** The temptation is to argue that an API-fed reading is *as good as* a device-signed one. It is not, quite: a device with an attested boot and a sensor-side interface would narrow the window for upstream substitution, for counterparties who care. The answer is not to claim the narrower property, nor to buy hardware nobody asked for, but to say in the record what the record knows. `attestation` already carries `time_source` and `provenance` for exactly this, and a reader who needs more can require more. ## What this changes The commercial model, not the protocol. Per-site cost falls from $1,200 to $300 — per- tenant compute, monitoring and alerting, and a managed signing key — because there is no appliance to amortise, no spares pool, and no truck. Onboarding becomes an API integration rather than a site visit, and the roles that do it are integration technicians. The staffing schedule and build rate in the valuation are **unchanged and deliberately so.** Whether integrating against a customer's historian is faster than commissioning a box is a question about throughput that nobody here has measured, and moving that number on the same day as this decision would bury a measured change under an unmeasured one. ## What this does not settle **Whether a hardware tier should exist.** If a tolling counterparty demands device-level provenance as a term, the tier is a product decision with its own pricing, and this decision constrains only that it be sold and attested as what it is. **What an API integration actually costs to build.** Historians differ — OSIsoft PI, Ignition, vendor SCADA exports — and the connector work is real. It is carried in engineering payroll rather than per-site cost, which is right if connectors are written once per system and wrong if they are written once per customer. Revisit when there are enough integrations to tell which. **Reversal conditions.** If counterparties in the target segments routinely require device-attested provenance as a contract term — not as a preference — then the appliance returns as the base case, and the cost line returns with it. Nothing in the protocol resists that: `Source` is an interface precisely so the answer can change.