TRUSTEvidence product
Trust Intelligence
Reads across the evidence an estate has already produced and states the relationships in it: which systems act on which, under whose authority, against which adopted policy. Every statement inherits its standing from the records beneath it. Nothing here generates trust of its own.
Nothing here is a conclusion the evidence cannot support.
No single record contains a relationship.
Every product in this family answers about one thing. A record is trustworthy. A sequence is ordered. A memory has an origin. An identity was declared. What none of them can state on its own is that this agent acts on that system under this authority, because that fact lives between records rather than inside any of them.
- An estate of records: Answers one at a time
- The relationships in them: Answers about the estate
- An estate of records: Complete but unassembled
- The relationships in them: Assembled without being altered
- An estate of records: Read one by one, by hand
- The relationships in them: Stated, and walkable back
The four products below it are the reason this one can be honest.
A relationship stated from logs is an interpretation, because logs were never designed to be authoritative about anything. A relationship stated from sealed records with declared identities is a reading of evidence that was built to be read. Same shape of statement, entirely different standing. Nothing here adds trust to what it reads: it inherits exactly as much as the evidence beneath it carries, which is why it could not have been built first.
Named relationships, each with its evidence attached.
- subject
- claude-code · 1.0.60
- acts on
- workspace · billing
- under authority
- adopted pack
- observed in
- 4 sealed operations
- derived from
ev_bf6442d03d1d4…· passportev_4c1d90a7f2b8· memoryev_d2839f04a6e1· memoryev_77a0e5b31c46· memory
Derived, never stored
A relationship is read from the evidence when it is asked for. Nothing is written back, so there is no second copy of the truth to fall out of step with the records, and no accumulated state that could quietly become the thing people trust instead.
Observed, not asserted
A relationship exists here because operations happened, not because someone declared an architecture diagram. What the estate does and what it was supposed to do are different things, and only the first leaves evidence.
Every statement walks back to a record.
This is the product’s single axis. The category this page will be mistaken for is built on the opposite premise: that the summary is the product and the underlying data is plumbing. Here the derivation is the product, and a statement that cannot be walked back is not shown at all.
Read at the moment of asking, from sealed records only.
Each one names its sources, so the derivation can be repeated by hand and reach the same answer.
No model reads the evidence and forms an opinion about it.
A derivation is deterministic. Ask twice against the same records and the answer is identical, which is the property that makes it evidence rather than analysis. It is also what makes a decision taken on it reproducible: whoever reviews that decision later re-derives the same statement from the same records, rather than being asked to trust the judgement of whoever ran it first.
Nothing aggregates across deployments, and no layer sits above them.
An estate here means the evidence one install holds, which is also the boundary that keeps the architecture local-first.
Systems outside the path appear in no relationship at all.
Their absence is reported as absence. A picture that looked complete while omitting ungoverned systems would be the most dangerous thing this product could produce.
Asked about a relationship the evidence cannot establish, the answer is that nothing could look. Not that the relationship does not exist, and never that the estate is therefore in good order. An unanswerable question is returned unanswered, with the reason stated.
It grows as the evidence does.
Like the other evidence products, this has no install path of its own, but it is the one whose usefulness depends on the four beneath it. With one operation there is nothing to relate. With an estate under governance, the relationships are already there, waiting to be read.
- Run an assessment
- A single run already relates identity, memory and operation. Nothing is installed.
- Install the runtime into an editor
- Relationships widen as governed work accumulates. Two editors install today.
Nothing to configure, and nothing to model
There is no data model to define, no source to connect and no schema to map before anything appears. The evidence already has the structure; this reads it.
It is also the honest reason this product is last: it is only as good as the four beneath it, and it cannot be adopted ahead of them.
There is no packaged installer for anything in the platform, no warehouse to load and nothing on this page to download. The two routes above are the whole of it.
The word intelligence is doing less work than usual.
In this category it normally means prediction, scoring, anomaly detection and a screen of charts. Here it means only that relationships already present in the evidence are stated plainly and can be checked. Everything the category would add is refused, and refused deliberately.
Nothing here produces a grade, a rating or a percentage for an estate, and no composite posture is computed across one. The executive surface writes composite_trust_score: None rather than deriving a number it could not show the evidence for.
Nothing forecasts, estimates likelihood or flags what might happen next. Evidence is about what did happen.
Nothing polls, watches, alerts or maintains a live view. There is no threshold to breach and no notification of any kind.
No chart, no aggregate metric, no drill-down and no exploration surface. A relationship is read and stated, not visualised for interpretation.
Nothing is written to a time series, so no claim about an estate improving or deteriorating over a period can be made from this.
Nothing acts on what it reads. No policy is adjusted, no operation is blocked and no recommendation is issued.
One number in the platform is easy to mistake for a composite, so it is named here rather than left to be discovered. POST /api/v1/trust/assess returns a trust_score for one agent: a 0–100 sum of three declared components · compliance coverage weighted 30, inverted risk 35, quality 35 · each reported with its own contribution, and resolving to unknown rather than to a number when an input is missing. It is deterministic and every point is attributable.
What it is not is an estate. Nothing sums those per-agent values into a posture for an organisation, nothing stores them, and nothing compares them across a period. That is the distinction: a score exists at the scope where its inputs exist, and is refused at the scope where they do not.
- compliance
- complete5 controls mapped
- risk
- lowscore 0
- quality
- excellentscore 100
Composed into:
- trust_score
- 100level trusted
- operations observed
- 1average 100.0
Captured output: trust.json · risk.json · quality.json · compliance.json
The whole family ends where it began: nothing stated that somebody else cannot check.
Records that can be verified, an order that was not rearranged, memory with an origin, identity fixed at the moment of the act, and on top of all four, relationships that name the records they came from. Each layer refuses to assert more than the one below it can support. That refusal, repeated five times, is the architecture.