When a situation is still vague, people naturally start connecting the missing pieces. Explainable Trust moves that reconstruction out of memory and into an inspectable record: what was reported, what is supported, what is inferred, what changed, and what is still unknown.
Type: Built Product Sample<br>Stage: Completed sample app · Runnable locally<br>Evidence basis: Runnable application, implemented end-to-end case flows, repository behavior, automated tests, and product screenshots<br>Last updated: August 2026<br>Boundary: The sample demonstrates case reconstruction, correction, provenance, local persistence, bounded public retrieval, and export. It is not deployed as a production service and does not include shared accounts, cloud collaboration, or an operational verification layer.
Why I built this
The app started from a simple observation: when information is incomplete, the mind does not like leaving the story unfinished. We connect a message to a screenshot, a remembered detail to a public rule, one person's account to another source. That is useful, but over time it becomes difficult to remember where the evidence ended and the reconstruction began.
The burden gets heavier when a situation unfolds across messages, files, corrections, public sources, and multiple possible explanations. The person has to keep reconstructing the timeline, evidence, assumptions, unresolved questions, and next step in their head.
I built Explainable Trust to externalize that work. The product does not try to make uncertainty disappear by producing a more confident answer. It keeps the current state inspectable: what is known, what is only reported, what is inferred, what remains open, and how the reasoning changed when new information arrived.
Customer support and disputes are one use case, but not the boundary. The same problem appears in purchases, public events, personal decisions, and smaller everyday situations where facts arrive gradually and from sources with different strengths.
The product question
An uncertain situation rarely arrives as a clean set of facts. It arrives as fragments with different strengths: a first-person statement, a document, an image, a public rule, a later correction, or a claim that may still be unsupported. The product needs to help reconstruct the situation without collapsing those differences into one confident narrative.
The product question is:
Can an AI-assisted workspace help a person reconstruct a situation under uncertainty without losing the distinction between evidence, report, inference, and what is still unknown?
Because that state can change, a second requirement follows: new information should update the case without erasing how the previous state was constructed.
The working flow is:
Describe → reconstruct → inspect → trace reasoning → correct → reconcile → expose gaps → decide what to check next
How the app works
The core design choice is simple: the model can propose changes, but the application owns the record.
Working demo — one case, two messages
This small test starts with a traffic-accident report. The user describes the collision, suspected drunk driving and leaving the scene, vehicle damage, an X-ray visit, and uncertainty about compensation and legal handling. No official police or medical evidence has been added yet.
1 · The first message becomes a case, not only an answer
The first intake is projected into a case view with a user goal, timeline events, findings, unresolved gaps, and proposed next actions. The response can still explain the current situation in plain language, but the structured record remains separately inspectable.
2 · A later correction changes the affected state
In the second message, the user corrects the accident time from 18:30 to 19:15 after checking dashcam data and adds information about the other driver. The correction is kept as a new source statement rather than silently replacing the earlier one.
The useful behavior is not that the model can notice a correction. It is that the application can reconcile the affected event and claim while preserving the earlier source, the new source, and the revision path between them.
3 · Unknowns stay visible instead of being completed by the model
The case still has no admitted evidence for the official accident record or the medical result. Those remain open gaps, with actions asking for scene images/video and medical documents. A source-linked finding can also preserve its scope and limitation rather than presenting a reported statement as independently verified fact.
That distinction matters here because the product is not trying to turn a user narrative into a verified legal conclusion. It is trying to make reported state, supporting evidence, missing evidence, and next action easier to separate.
4 · Provenance can be inspected as a network
The case graph makes the dependency structure visible: user statements connect to events and claims; those records expose unresolved gaps; gaps connect to proposed actions. A correction can therefore be inspected for what it changed downstream instead of disappearing inside a rewritten summary.
Product decisions
What the completed sample includes
The architectural constraint is deliberate: a provider response is not the case. A candidate revision becomes authoritative only after application-side reconciliation, full-ledger validation, and successful browser commit.
What the sample deliberately does not include
If I extended the sample
The scoped sample is complete, but the original product direction was broader than a standalone case workspace. The longer-term idea is a privacy-preserving resolution channel in which the user keeps control of the case, linked organizations can update the process without taking ownership of the user's record, and the product learns from patterns only when users explicitly allow it.
A real-world pilot would first test the current product behavior:
From case workspace to resolution channel
The next product step would not be to make the app know more about the user. It would be to let the case move between parties while revealing less identity than a normal support workflow.
The design goal would be anonymous at the application layer: the app would not need a conventional user profile, and the server would operate on opaque case identifiers rather than treating real-world identity as part of the product. A user could choose to link a case to a company, platform, insurer, public body, or other responsible party through a bounded case channel. The linked party could then send requests for evidence, status changes, review outcomes, deadlines, or next actions back into the same case record.
For the user, this would turn repeated support contact into a visible process: what the organization has received, what is still missing, who or what is currently waiting, what changed, and what happens next. For the organization, especially customer service, the same structure could reduce repeated explanation, duplicate evidence requests, inconsistent handoffs, and uncertainty about the current case state.
A consented analytics model, not silent data extraction
By default, the individual case would remain private. A separate opt-in would ask whether the user wants to contribute de-identified case signals to aggregate analytics.
The commercial hypothesis is that linked organizations would pay for those aggregate operational signals, not for access to an identifiable person's case. Useful outputs could include where resolution pathways repeatedly stall, which evidence is most often missing, where customers need repeated contact, how long different states persist, and which handoffs create avoidable recovery burden.
That creates a different incentive structure from advertising or hidden profiling: the user gets a clearer resolution pathway and can choose whether their de-identified experience contributes to system learning; the organization gets a better view of recurring operational friction; and the product earns from the analytics or integration layer rather than from making identity itself more valuable.
Build and repository
The public repository contains the runnable application, server boundary, Ledger V3 contract, deterministic proposal application, local persistence, retrieval controls, automated tests, evaluation configuration, and runtime notes.
Open Explainable-App on GitHub →
Read the runtime architecture → · Read the public-retrieval boundary →
Current takeaway
The prototype is most useful to me as a test of one product assumption: explainability is not only a better answer. It is the ability to inspect how a changing case reached its current state, what still supports that state, and what remains unresolved.