Human data needs harness discipline

The evaluation boom taught this industry one durable lesson: a number without provenance is decoration. Benchmarks became useful the moment harnesses made them traceable — every score linked to the runs that produced it, every method published, every rerun reproducible. We did not trust model scores because we trusted labs. We trusted them because harnesses made claims checkable.

Data about people deserves the same discipline. A career profile is a set of claims about a human being, consumed by systems that will act on them. If a benchmark score needs provenance, a claim about a person needs more.

Traceability, end to end

In ProfileClaw, every conclusion traces downward to its evidence. A dimension score links to the answered items behind it. A summary references the scores it condenses. Nothing in a profile is an orphan claim — which means "where does this come from" is always a query, never an argument.

The same is true outward: every read is on the record. Which client, which layers, at what time, under which consent version — logged, exportable, and visible to the person the data belongs to.

Consent lives in the schema

Most products treat consent as a checkbox in front of the database. That placement is why consent fails: a checkbox guards the door once, while the data lives on for years behind it.

We put consent inside the schema, next to the data it guards. Scopes are attached to layers — a client is granted summaries, or scores, or nothing — and every read is evaluated at request time against the grant that exists now. There is no copy of "the data" that leaked out before the rules changed, because clients read through the layer; they never take it home wholesale.

Revocation that actually revokes

Revocation is the honest test of any authorization story. If a system only checks consent at export time, revocation is theater.

Because access is a read-through property, turning it off is boring: the next request evaluates against the updated grant and fails. The audit log records that it failed. Nothing needs to be "recalled," because nothing was copied.

What organizations actually ask

Enterprises do not ask for vibes; they ask for properties. The recurring list, in our experience:

• Aggregation without exposure — a cohort view for coaches and administrators where members' raw answers stay sealed by default.
• Role-based scopes — what a coach may read differs from what an administrator may read, enforced by the layer rather than by trust.
• Retention with an end date — data kept for a stated window, deletion actually scheduled rather than promised.
• Export — the person's own record, out in the open, in a portable format.

None of these are policy documents. All of them are properties the middleware either enforces in code or does not have.

Trust in human data will not arrive through privacy policies, which everyone agrees to and no one reads. It arrives the way benchmark trust arrived: when the harness makes every claim checkable, every read logged, and every revocation real.