Valeur.Products · Evidence Chain
Let your file carry who said what, and when, on its own face
A claim file is usually assembled months after the event, by someone who was not there. The questions that person has to answer are not technical: where did this line come from, who said it and when, has it changed since. If the answer is not inside the file, the answer is in somebody’s memory — and the other side knows that too.
A file is not an argument. The output never says “you are right”; it shows what came from where and when, and leaves blank the places it cannot show.
- Where did this line come from? — every section is built from its own records.
- Who, and when? — the producer and the moment of production sit inside the file.
- Has it changed since? — the content is sealed, and the seal does not look at fields outside the content.
- What if a section has nothing behind it? — it comes back empty. It does not get filled.
A file does not assemble itself; people assemble it
The cost of that work never shows up in the file. It shows up in hours — hours spent finding someone who remembers the answer the file does not carry.
14.1 hours per week per person were reported in non-optimal activity, 5.5 of them spent looking for project data and resolving conflicts. In the same study, an average of 52% of all rework globally was attributed to poor data and communication.
PlanGrid & FMI · Construction Disconnected, 2018. This is self-reported survey data (599 respondents), and PlanGrid, which commissioned the study, is a construction software company — so the figure was gathered by a party measuring the problem its software claims to solve. It is placed here as the industry’s own statement together with that caveat, not as a measurement of ours.
Valeur does not claim to reduce those hours. We have not measured them, and we do not credit ourselves with what we have not measured. Valeur builds the file out of thirteen named sections, each with its own producer, and seals the content with SHA-256. It computes that seal without looking at the moment of production, the status, or the seal itself — so the same content produced twice yields the same seal.
TODAY: All thirteen section kinds have their own producer. A file is built from the sections asked for; a section not asked for is absent, and a section with nothing behind it is present and empty.
Thirteen sections, thirteen separate producers
The list below is not a summary but the complete set of sections a file can contain. Behind each line is a separate producer in the product tree that constructs that section; the two lists match one to one, with no kind lacking a producer and no producer lacking a kind.
- Project record — the contract’s identity and the scope the file was produced for.
- Timeline — the order of events, each tied to its own record.
- Field captures — records taken on site, with the moment and the person who took them.
- Inferences — conclusions derived from records, with the record they derive from.
- Nonconformances — nonconformance records raised, and their status.
- Extension of time — the time claimed and the events it rests on.
- Claims — the claim chain and the basis of each link.
- Camera and scan findings — drone and helmet camera frames, marker counts, point-cloud density; every raw file with its own digest.
- Programme — the works programme and the movements on it.
- Quantities and amounts — the claim in quantified form.
- Correspondence — notices and their replies, with dates.
- Contract clauses — the clauses relied on and their text.
- Ledger proof — the file’s own integrity record.
ScopeA file is built from the sections asked for; asking for all thirteen does not return thirteen full sections. On a project with no camera work the eighth section comes back empty — empty, not populated with produced content. A section existing does not mean there is data in it.
TODAY: The mapping between section kinds and producers was checked in both directions as this page was written: no kind without a producer, no producer without a kind.
The content is sealed, and the seal ignores three fields outside it
The seal is a single number computed from the file’s content. Which fields go into it matters, and so does which fields do not — each of the three left out would, if included, have made the seal useless.
SHA-256( canonical JSON( file content ) ) → lowercase hexadecimal
- The seal itself
- Outside the computation. A digest that fed its own output back into its input could not be written in the first place.
- Moment of production
- Outside the computation. The same content rebuilt tomorrow yields the same seal. Included, the seal would verify the clock rather than the content, and two identical files would look different.
- Status
- Outside the computation. Finalizing a file does not change its seal. Included, sealing would be the one operation the seal could not survive.
The result is something a reader can hold us to: the same content always gives the same seal, and a file’s seal does not change when it is finalized. If the seal changed, the content changed — there is no other explanation.
TODAY: The seal is SHA-256 over canonical JSON, in lowercase hexadecimal. The choice and order of sections is digested separately as well: the same sections asked for in a different order is a different file.
Three states, and finalizing happens from only one of them
The state a file is in determines what can be done with it. The value here is not that the states exist but that the transition between them can be refused.
Draft
The file is built and can still change. This is the state you work in.
Finalized
The content is re-sealed and the file is known by that seal from then on.
Issued
The file is known in the form in which it was handed out.
RuleFinalizing happens only from draft. A request to finalize a file that is already finalized or issued is refused, and the reason given for the refusal is the file’s current state. This is not a warning; the operation stops.
TODAY: Three states are defined and the gate between them is one-way. A file can be exported in four formats.
What the file is built around
An evidence file does not always carry the whole project, and most of the time it should not. One of the five targets below is chosen, and only the records tied to that target enter the file.
- Project
- No narrowing; every record attached to the project enters the file.
- Activity
- Only the events, nonconformances, extensions of time and claim chains tied to that activity.
- Variation order
- Records reached through the variation’s events — those attached to the events directly, and the claim chains that reference them.
- Claim chain
- The chain itself, and the records reached through the activity the chain is attached to.
- Nonconformance
- A single nonconformance record and the events reached through its activity.
Scope is a filter, not a summary. A narrowed file is not an abridged version of a wide one: a record not tied to the target never enters the file, and because it never enters, it is not in the file’s seal either.
TODAY: All five targets narrow by their own rule; none of them is an alias for another.
What this file does not do
All three are true today and none of them is waiting on a release. Saying what an evidence file is not is the condition of saying what it is.
-
01
The seal shows immutability, not correctness
The seal shows that the content has not changed since it was sealed. It does not, and cannot, show that the content was correct to begin with: a wrong date seals just as firmly as a right one. The question the seal answers is “has this changed”, not “is this true”.
TracedThe seal is computed over the canonical form of the file’s content and performs no check on the content itself.
-
02
An empty section is not a roadmap item
An empty section does not mean it was never built. It means that project has nothing behind it. On a job with no camera work, a full camera section would be the sign that the file could not be trusted.
TracedSection producers work from the records found in scope; with no records, the row count is zero.
-
03
Internal consistency is not acceptance by a tribunal
That a file is internally consistent and sealed does not mean any court, arbitral tribunal or dispute board will accept it. Admissibility is a matter for the procedure you are subject to, not for this file.
TracedThe code that produces the evidence file carries no field and no step that judges admissibility; the file makes no such claim.
The structural figures on this page
All four were read out of the product’s own definitions as this page was written. None is a measurement of an outcome; each is a property of the material.
- Section kinds
- Thirteen. Each has its own producer and the two lists match one to one.
- Scope targets
- Five. Project, activity, variation order, claim chain, nonconformance.
- States
- Three. Draft, finalized, issued — and finalizing happens only from draft.
- Export formats
- Four. Not four copies of the same thing: one gives the whole file, one a readable report, one the package with its attachments, and one only the timeline and quantification rows.
TODAY: All four were read from their definitions. Figures mean something as their counterparts are verified, not as they grow; each of these rests on a mapping checked in both directions.
Frequently asked
Does the seal prove the file is correct?
No. The seal shows the content has not changed since the moment it was sealed. Whether the content was correct to begin with is a separate question, and the seal does not answer it. A wrong record seals just as firmly as a right one.
If I produce the same file twice, do I get two different seals?
No — if the content is the same, the seal is the same. Because the moment of production is held out of the computation, the same content built today and tomorrow yields the same seal. If the seal changed, the content changed.
Does finalizing a file change its seal?
It does not. Status is also held out of the computation; finalizing changes the file’s state, not its content. The content is re-sealed during finalizing, and the same content yields the same seal.
Can I finalize a file that is already finalized?
No. Finalizing happens only from a file in draft; for a file that is finalized or issued the request is refused, and the reason given is the file’s current state.
One of the sections came back empty. Is something missing?
Most likely not. Sections are built from the records found in scope, and a section with nothing behind it in that scope comes back empty. Empty means unfilled — which is to say, not invented. If a record you expected is landing in an empty section, the problem is not the section but how that record is tied to the scope.
Will this file be accepted as evidence in court?
We cannot say so and we will not. Admissibility depends on the procedure and the forum you are subject to; it is not a ruling software can make about its own output. The only thing the file claims is that the content it carries has not changed since it was sealed.
Let us look together at which questions your file already answers.
The meeting is not a pitch: we take one of your claims and look together at which sections come back full, which come back empty today, and why the empty ones are empty.