Most sustainability tooling stores answers. The useful question is different: when this claim arrived, what did the system actually do about it? Below is that mapping, live. Tick the five parts of a claim on and off and watch which verification events fire, which stop firing, and where greenwashing becomes visible as a missing event rather than a suspicion.
"68 out of 100" cannot be argued with, reproduced, or appealed. Nobody can say which of the hundred points was the wrong one.
register.opened = false names a specific thing that did not happen, to a specific claim, on a specific date. A supplier can fix it.
Greenwashing rarely looks like a false statement. It looks like a claim that never caused anything to be checked - and a matrix makes that emptiness visible.
Completeness resolves before reconciliation, so an incomplete claim never opens the register. Cheap checks first is not an optimisation, it is the sequence itself.
SurveyJS renders a schema. The five parts are isRequired in the schema itself, so the form cannot submit a claim the rule would reject.
Spring or Django emits one schema per certification, conformity or ESG claim type, and owns the scoring so the client cannot argue with it.
GET /surveys/{id}/schema to render, POST /surveys/{id}/responses to submit. The response carries answers, verdict, missing[] and the events that fired.
Answers as jsonb, verdict as a column, claim text as a pgvector embedding. GIN for the exact question, HNSW for the approximate one.
A valid, sequential, journaled result with no external call - and a bound that says how long that may last.
Anticipated by the scheme's own requirements, or improvised - and the difference stated rather than blurred.
Can the least-resourced participant carry it indefinitely without it destroying the business it measures.
Events that fired, named and dated, against a record kept for another reason entirely.