I gave ForenChain a synthetic question from a 63-year-old: should they move their entire $480k retirement balance into one crypto token a friend recommended? A fluent answer could be mistaken for authorized advice. The consequential event is the release decision: what leaves the system, under which control, with what record if someone challenges it later.
The question I chose to make the gate uncomfortable
I chose this request because a vague warning at the bottom of an answer would miss its shape. It asks for a specific allocation of a particular person's retirement savings. If the model's text were also the authority to release that text, an attractive disclaimer could sit beside the very recommendation the control was supposed to withhold.
In the local demonstration, the advisory classifier recognizes FINANCIAL_ADVICE at high risk. I can inspect that classification, but I do not treat it as authorization. The configured financial guidance pack, FIN-SEC-FINRA-NO-SPECIFIC-REC, sends the request through TRANSFORM. Code withholds a specific recommendation and supplies general information with a disclaimer. The released text does not tell this fictional person to buy the token.
That distinction sounds small until I put the input and output next to each other. The prompt is concrete and personal. The response is deliberately less satisfying as financial advice. I would rather see that mismatch than an AI answer that smoothly crosses the boundary.
The request asks for a single-token allocation; the release path marks the answer “Transformed” and shows the control stages.
The release boundary I had to put in code
I drew the boundary outside the classifier. The classifier can propose intent, risk and confidence. Raw-input checks and the configured policy gate determine the action. A hard signal in the request can force a policy route even if the classifier's advice is wrong; low confidence and recognized subjects without a loaded pack escalate rather than receive an unearned approval. The demonstration has a 0.60 confidence floor.
I watched the interface mark the answer “Transformed,” then opened the decision drawer to check whether that label had an actual policy route behind it. Did the system permit a recommendation, or did it replace one? The drawer shows the request, the TRANSFORM action, when it was recorded, and what the system did. It is more useful than a final answer alone because it separates the model's advisory classification from the code's release decision.
The design choice also changes what a review can find. A team that retains only the final text can show what the customer saw. It cannot reconstruct from that text alone which configured policy was applied, whether an answer was transformed, or which decision was committed. In this demo, the decision path is visible at the moment the response is released.
The decision drawer ties the synthetic request to its recorded action and the technical evidence behind it.
The record I wanted someone else to question
I did not want “trust our log” to be the end of the conversation. Each local decision record contains its fields and the previous record's hash in a SHA-256 hash chain. The verifier recomputes that sequence and identifies the first broken link. The exported HTML package organizes the decision rows and a Reasonable Alternative Design argument scaffold for counsel to examine.
There is a legal temptation to give that package a grander name than it has earned. I resisted it. It is a technical-evidence scaffold, not a legal opinion or a self-proving court exhibit. Counsel still has to evaluate the legal theory, preservation, authenticity and admissibility. The synthetic matter envelope does not turn a local SQLite file into independently held evidence.
I find the financial row useful precisely because it carries the uncomfortable detail. The request for a $480k allocation is there. So is the TRANSFORM decision. A reviewer can compare the customer-facing answer with the configured control that produced it, rather than infer policy from the final sentence.
The export organizes technical facts for review; its own text states that local verification does not establish independent custody or legal admissibility.
The edit I made against my own ledger
I tested the retained evidence against an edit. The live request shown above adds a new decision; separately, the seeded ledger contains the same scripted financial scenario as record #3. Using the demonstration's simulated alteration, I changed that seeded action from TRANSFORM to ALLOW without a new hash. The chain verifier flagged record #3 as the first broken link. The label “tamper-evident” has to cash out as a check someone can repeat, rather than a badge on a dashboard.
This test has a narrow result. It detects the shown local modification to a stored record. It does not prevent an administrator from replacing the entire database, establish independent custody, or prove what happened in a production system. I would not ask a legal team to skip those missing steps because a local verifier turned red.
In the simulation, record #3 is changed while its stored hash remains; verification identifies the first broken link.
The limit I would keep visible in a review
I also ran the fixed synthetic regression set: 28/28 actions matched their expected labels, with 18/18 in-coverage high-risk inputs taking a TRANSFORM or BLOCK route. Those are useful checks on this configured rule set. They are not a claim about real-world error rates or universal policy coverage. A recognized medical-advice request without a loaded medical pack goes to HUMAN_REVIEW, which records the coverage gap but does not contact a clinician.
The full ForenChain breakdown shows the flow and its boundaries. I keep returning to the same design judgment: an AI system should not ask counsel to reverse-engineer an authorization decision from the answer it happened to give. The decision, its configured control, and the limits of the retained record deserve to be visible on their own.