Team/Chief Technology Officer

Jon Moen.

Jon Moen is the Chief Technology Officer of Scrapeless Data. He is a systems engineer with a hardware operator's bias for measurable throughput, previously technical director at a liquid-cooling manufacturer, where he specified and sold GPU server infrastructure to research universities and security firms. At this company he owns ingestion, the index, the API, the agent surface, and security: everything a record passes through between a contracted file and a response.

Jon Moen, Chief Technology Officer of Scrapeless Data
Jon Moen, Chief Technology Officer of Scrapeless Data

The record

An engineer who counts what he ships.

Jon comes from hardware, where a claim is a number or it is nothing. As technical director at a liquid-cooling manufacturer he specified and sold GPU server infrastructure to research universities and security firms, work where throughput, thermals, and delivery dates are all measured by the buyer and a miss is visible on an invoice. That is the bias he brings to a data company: measurable throughput over architecture theater, and a stated latency figure over an adjective.

The same bias shows in how this site treats the machine surface. The protocol endpoints that are live today, the UCP manifest, the ACP configuration with accepting_orders set to false, and the AP2 trust configuration with a published signing key, are his build, and he reviewed the protocol stack from that build in the knowledge hub, scoring its implementability honestly instead of politely. An agent reading this domain is reading his work.

The seat

What the CTO owns here.

Jon owns the full path of a record: ingestion of contracted files, the index they land in, the API that serves lookups, the agent surface that lets machines register and transact, and the security of all of it. The design commitments on the docs page, one call returns one record, structured errors an agent can act on, suppression as a visible response state, are commitments he has to keep at launch, which is why they are published now with shapes frozen. In hardware, the spec sheet precedes the shipment and then the shipment gets measured against it; he runs the API the same way.

01
Ingestion and the index
Contracted files enter one lookup surface with a known update cadence. Moving compiled files without corrupting them is the discipline the whole product rests on.
02
The API
One GET request, one record, a provenance object on every planned response, and an error contract written for the agent that has to act on it.
03
The agent surface
The live protocol endpoints on this domain: UCP, ACP, AP2, llms.txt, agent.json, and machine registration at /api/agents/register.
04
Security
Keys shown once and stored hashed, per-key rate limits announced in headers, and a security.txt with a real contact behind it.

Questions about the Chief Technology Officer, answered plainly

What does the CTO own at Scrapeless Data?

Ingestion, the index, the API, the agent surface, and security: the entire technical path between a contracted file and a served response. Jon Moen is the single named owner of all five, so when the docs freeze a request shape or the compliance page describes suppression behavior, he is the person those commitments land on. The protocol endpoints that answer on this domain today are his build.

Why does a records API want a CTO with a hardware background?

Because hardware punishes unmeasured claims fast. Specifying and selling GPU server infrastructure to research universities and security firms means every promise about throughput and delivery gets checked by the buyer, and that habit transfers directly: the planned API publishes its latency in the response, announces rate limits in headers before you hit them, and returns structured errors instead of prose. Measurable throughput is the house style because it was his job.

What is the agent surface Jon Moen owns?

The set of machine-readable endpoints that let an AI agent discover and deal with this company without parsing marketing pages: the UCP manifest, the ACP configuration, the AP2 trust configuration with its published signing key, llms.txt, agent.json, and the machine registration endpoint documented at /agents. All of it is live today and all of it states truthfully that keys issue at activation.

Did Jon Moen really review the protocols his own site implements?

Yes, and the review is published in the knowledge hub with a verdict of 4 of 5 on implementability. It was written from the build rather than from the specs alone, which is why it names the sharp edges, version drift between the three protocols, thin validation tooling, and the static-file shadowing trap, alongside what worked. Publishing an honest grade of your own stack is the measured-engineer register applied to yourself.

One seat, stated plainly.

The API contract Jon owns is published in the docs with every sample labeled synthetic, and the machine surface he built answers on this domain right now.