The provenance problem

A résumé is a claim, not a record

The evidence that would substantiate it — the pull requests, the review comments, the incident response, the tickets closed — already exists. It sits in tools the résumé never links back to.

The same gap appears on the other side of the table. Staffing and promotion calls do get recorded, but what gets captured is a rating or a narrative: the verdict, not the evidence behind it. So the blind spots repeat, because nothing in the system of record can be re-examined.

Filling that gap with a platform-generated score fixes nothing. It moves the invention upstream — from an unverifiable claim by a person to an unverifiable number from a vendor.

What the system does

CareerOS-AI connects to the platforms where work already happens and derives an evidence-backed account of what someone has demonstrated. Each stage is a real transformation with its inputs retained, so any statement at the end can be walked back to the events that produced it.

Everything downstream of ingestion is shared. Adding a provider means writing one normaliser, not a second pipeline — which is what makes the fifth and sixth integrations cheap rather than compounding.

Why this is not the tools that already exist

Four categories already sit near this problem. Each is built to answer a different question, and none of them is the one above.

These are useful products, and this is not an argument that they are bad at their jobs. It is that three structural choices here are different in kind.

The direction of inference is reversed

The first three categories begin with a claim — a résumé, a profile, a self-rated skill — and process it. This begins with the artifact: the commit, the review, the ticket, the deploy. The claim is the output, not the input. Engineering analytics reads those same artifacts, but aggregates them into team throughput rather than a person's demonstrated capability.

The score is required to show its working

A number that cannot be interrogated is a claim like any other. Every score here decomposes into named components with published weights, absent evidence scores zero rather than being estimated, and the derived confidence figure behind a capability is deliberately never returned by the API — only a band, because a decimal implies a precision the evidence does not support.

The subject holds the controls

Engineering analytics is an org-facing dashboard about people who mostly cannot see it. Here the profile belongs to the person it describes: they set what each audience sees, section by section, and a viewer is told that something was hidden rather than being quietly shown less. That is a precondition for the evidence being offered voluntarily at all.

Scores are decomposed, never asserted

Proof Strength is a weighted average of five components, each measuring a different kind of corroboration. The weights are not a trade secret — they are published on the profile beside the score, so a reader can see which evidence is present and which is absent.

A component with no supporting evidence scores zero. It is not estimated, inferred, or filled in from a comparable profile — the absence is reported as an absence.

Three places the discipline is enforced in code

Stating a principle is cheap. These are the constraints that hold it in place when a feature would be easier to build without them.

Raw confidence never leaves the API

Capabilities are exposed only as a band — High, Medium, Emerging. The underlying confidence score is deliberately not returned, because a number implies a precision the evidence does not support, and a band does not.

Generated prose is rejected if it invents a digit

A short career summary is written by a language model from a fixed set of input facts. Every number in the output must trace to one of those facts, or the summary is discarded rather than shown. Language models are confined to four named jobs — narrative summaries, capability label refinement, self-advocacy drafts, and outcome extraction — and never sit between the evidence and a score. There are no embeddings, no vector database, and no retrieval layer anywhere in the product.

The subject decides what each audience sees

Visibility is per-section and per-audience, controlled by the person the profile is about. When a section is hidden, the viewer is told that something was hidden and why — the reader learns the profile is partial rather than being quietly shown a smaller one.

What the system will not do

A platform that judges people accumulates obligations faster than features. Two are settled decisions rather than intentions.

No protected-class data. Race, gender, age and disability status are not collected, and there is no plan to. Reversing that would require a jurisdiction-by-jurisdiction legal review, a real opt-in consent flow, dedicated encrypted storage, and a named feature that genuinely needs it. Consequently the governance dashboard audits decision patterns — self-staffing conflicts, overridden recommendations followed by poor outcomes — and is not a demographic bias detector, because it has no demographics to work from.

Where this actually stands

The system is built and deployed. Four providers ingest, the pipeline runs end to end, and the profile it produces is publicly reachable. The architecture — evidence provenance, visibility policy, temporal consistency, explainable outputs — is the part that took the time, and it is done.