TriStruct

Fix it in place before it can be altered.
Proof that survives a breach.

Recover only the data that is sound “CleanRecovery”
A record of the work itself, AI use included “WorkflowAudit”

Immutable Evidence Architecture
Japanese Patent No. 7892230 — Granted
PCT filing in preparation

Challenge

Once data is compromised, it does not come back.

79.8%Could not restore
from backups
66.7%Because the attacker had
encrypted or deleted it
51.7%Investigation and recovery
cost over JPY 10 million
20.6%Took more than
one month to recover

National Police Agency of Japan, 2025

After a ransomware attack, what is left is data and backups whose damage cannot be traced. Analysing incomplete data will not bring back what is no longer there.

The data you need to restart the business exists only before the breach.

IEA

Fix the data in the state it had
the moment it was created.

Keep it with Root Authenticity.

When a record changed, which record it was, which account made the change, and what changed.

Not a periodic snapshot: proof that can only be taken at the moment of the change, for each record.

Is this data really what it was?
If the state at the moment of creation is still held, that question can be answered.

Value

Holding evidence that cannot be erased
changes what your service can do.

Each record stays exactly as it was entered and becomes evidence that cannot be erased, record by record.
Evidence that carries its own authenticity changes what you can prove and what you can restore.

What you can now prove

From AI inputs and outputs and business operations through to security records.
IEA fixes whichever items you declare in its settings.

Audit trail vendors
Instead of collecting the logs a system emits, your own product generates an audit trail with nothing missing.
Security vendors
Records that are complete and cannot be erased let you show the scope of a breach in concrete terms — when, which data, by which account, and how it was changed.
Record detail
Record detail

The screen decrypts the original for viewing.
A Merkle tree makes each record independently verifiable by a third party.

What you can now restore

Material for recovery accumulates record by record, right up to the moment the breach is found.

System vendors
Even when the business system has been tampered with, your own system holds the material to put it back as it was.
Backup vendors
You can offer recovery up to the latest data, past the last backup point, with compromised records excluded.
Record list
Record list

Because records are selected individually, compromised ones can be left out of the restore.

Patent

A data proof method that does not allow a confirmation without evidence.

Japanese Patent No. 7892230 — Claim 1 (excerpt, translated)

(1) Receiving, at a data processing device, an irreversible confirmation operation on the target data — an operation whose effect cannot be undone — or detecting that such an operation has been established.

Before the confirmation there is nothing settled to fix; after it, differences from the entered state can creep in. Unless the evidence is taken at the same moment as the confirmation, you cannot say that what you fixed is what was entered. Specification [0019], [0027]

(2) Generating, in response to the confirmation operation, verification information that contains at least a hash value of the target data.

Without a hash of the target data, you cannot show that what survived is the same as what existed before the breach; you can only estimate it by analysis. Specification [0020], [0021], [0028]

(3) Transferring and storing that verification information in an area where the correspondence between the evidence and the confirmation operation cannot be altered afterwards.

If the evidence sits where it can be rewritten, the evidence itself can be changed later, and it no longer establishes authenticity. Specification [0015], [0022], [0029]

(4) Control that excludes a partial-success state in which only the confirmation operation succeeded — by rolling it back, holding it, prohibiting the commit, or treating the confirmation as not established.

If business data is allowed to stand without evidence, you cannot raise a question about data appended by illegitimate means.
Unless the success or failure of the save is assured, you cannot exclude the possibility of records that were never saved and are simply gone. Specification [0023], [0025]

(5) Making successful storage of the verification information in the external area a mandatory condition of the confirmation — as one indivisible process, through a single transaction, or through a protocol that allows the move to the confirmed state only once the external area has acknowledged the save.

Unless the confirmation, the generation and the successful storage are indivisible, a gap opens in the middle of the processing where authenticity cannot be shown. Specification [0022], [0041]

Principles

Protecting the business in the face of a data breach

1. Why we build it

Not every intrusion can be prevented, and lost data cannot always be recovered.
Once a data breach is taken as the premise, what has to be proven is not only whether data was altered, but that none of the data itself is missing.

For that, what is needed is not to rely on verification after the breach alone, but a mechanism that settles success or failure at the point of storage and can prove that the data exists.

Attack methods keep growing more sophisticated as time goes on.
What we aim at is not to rely on defence alone, but to make sure in advance that the data needed for recovery remains and can be retrieved.

For those who run a business.
What technology can do, we deliver through technology.
That is where we stand.

2. How we designed it

We designed the technology on three principles.

First, it can fix any data created in the course of business.

Text, files such as documents and images, and other binary data included — whatever the format and whatever the kind of work, the original is stored in a verifiable state.

Second, it places no burden on the existing system or on whoever implements it.

Performance and availability of the business are not impaired, and changes to the existing system, processing load and the work needed to introduce it are held down as far as possible.

Third, it does not sacrifice the strength of the proof.

Even when the system is breached, which original is the correct one can be proved without relying on the breached system.
And the data needed for recovery can be identified one item at a time.

To achieve this, we built it so that it depends on no particular product or technology, and obtains the original by a method suited to whatever it connects to.

We do not fit the existing system to the technology. We fit the technology to the existing system.
That is our design philosophy.

3. What we built and verified

To realise these principles, we implemented capture of the data, generation and storage of verification information, independent verification, and recovery.

We have carried out verification on ten systems of differing structure — groupware, ERP, electronic medical records and others — across both on-premises and cloud environments.

On each system we confirmed the following:

  • Capture of the business data
  • Generation and storage of the verification information
  • Fitness for recovery at the level of each individual item of data

We have also completed a demonstration of a verification method using a Merkle tree based on RFC 6962, as a means of allowing independent verification by a third party.

Connecting IEA to an existing system and putting it in place takes from a few hours to a few days, depending on the environment.

Please note that the method of capture and the scope that can be assured differ with the structure of what IEA connects to and the functions available there, so suitability has to be confirmed for each environment.

How we work with you

External connection methods. No change to your system, or a minimal one.

Available under a B2B licence.

If you would like to deploy IEA, please talk to the system vendor you already work with. Demonstrations are available to vendors and to end-user organisations alike.

01

Demonstration

We show IEA running in our own environment, online.
Detailed technical information is disclosed after that.

02

Mutual NDA

We sign a mutual non-disclosure agreement.

03

Reference implementation (paid)

We connect IEA to your product and measure the effect.

04

Licence agreement

We hand over the reference code. Proposals to customers, integration and maintenance stay with you.

Contact

Request a demonstration, or talk to us.

Please do not use this form for sales or solicitation.

Open the form

We use what you send only to answer your enquiry and to contact you about it. See our privacy notice.

Start with a demonstration.

Japanese Patent No. 7892230, granted and published. The core technology is covered by that patent, and further applications are in progress.
IEA is in use and under evaluation at several healthcare providers.

partner@tristruct.co.jp