Compare Two Documents Side by Side, Inside the Case File

SentinelOps compares two documents side by side inside the case file and surfaces indicators that one of them may have been altered. All analysis is performed in Australia. It examines files as objects, not the stories they tell, and it produces no score and no verdict - the investigator reviews what is shown and records their own disposition.

Last reviewed: 21 August 2026.

Why Does Comparing Documents Take So Long?

Because it is done by eye.

An investigator receives a policy and the version the employee says they were given. A signed agreement and the copy produced in response to a request. An expense claim and the receipt behind it. The two files are opened on two screens, or printed and laid next to each other, and someone reads them line by line looking for the difference that matters. It works. It is also one of the slowest tasks in the job, it is easy to lose an hour to, and it is the task where concentration fades fastest.

The usual alternatives each cost something:

• Doing it manually is reliable when the difference is a paragraph and much less reliable when it is a date, a figure or a line of small print.
• Doing it in a separate tool means exporting evidence out of the case file, working somewhere else, and bringing the result back by hand. If your team already runs several systems, that is one more.
• Doing it in a third-party tool raises a question that is easy to ask and surprisingly hard to answer: where was that document actually processed? For an investigation file full of personal information about identifiable people, “somewhere overseas, probably” is not a comfortable answer to give a general counsel.

SentinelOps does the comparison where the evidence already lives, and does it in Australia.

What Does the Comparison Actually Show?

Two items of evidence can be compared side by side, because alteration is often only visible as the difference between two files.

The comparison presents both textual and visual differences between the two evidence items. The view has three states the investigator can move between:

• Prior version
• Current version
• Difference view

The differences are shown. They are not scored, and they are not characterised as proof of anything. What an investigator does with a difference is an investigative judgement, and that judgement stays with them.

This is the case the buyer actually has more often than the textbook one. A single suspicious document arriving on its own is rare. An original and a copy arriving from two different sources - two files, two custodians, two accounts of what the document said - is common, and the meaningful observation exists only in the difference between them.

Does This Sit Inside the Case File, or Is It a Separate System?

Inside the case file.

The comparison runs on evidence items that are already attached to the matter. There is no export, no second login, no re-upload, and no copy of the document sitting in a tool that is not part of the investigation record. The result is attached to the case like any other piece of work, and the audit trail records that it happened, who ran it and what they concluded.

That matters more than it sounds. Every time evidence leaves the case file to be worked on somewhere else and comes back, the chain of custody has to be re-established by hand, and the account of what was done to the document lives in someone’s memory or in a second system’s logs. Keeping the work in one place is not a convenience feature - it is the reason the record stays intact.

Where Does the Data Go?

To an Australian region, and nowhere else.

This is usually the first question a workplace investigation team asks about any tool that touches evidence, and it deserves a direct answer rather than a reassuring one:

• All analysis is performed in Australia. Evidence never leaves the country.
• Customer data is stored in Australia.
• Built, developed and tested in Australia. The AI narration that turns observations into readable investigator language runs on an Australian inference profile, within Australian infrastructure.

We also want to be precise about something vendors in this market routinely overstate. Like any modern platform, SentinelOps is built partly from supplied components, and some of them are third-party services. Those services run in Australian regions and evidence does not leave the country. We do not publish the names of our infrastructure or model suppliers, because supplier names are attack-surface information. We also do not claim that no third party is involved, because that would not be true, and a security reviewer would establish it in an afternoon. Silence about suppliers is a legitimate security posture. A denial is a false claim, and we do not make one.

Why this is worth the attention: an investigation file is largely personal information about identifiable people. Under the Privacy Act 1988 (Cth), Australian Privacy Principle 8 requires an entity to take reasonable steps before disclosing personal information to an overseas recipient, and s 16C makes the entity accountable for acts of that overseas recipient that would breach the Australian Privacy Principles. Accountability does not travel with the file. It stays with you. Being able to answer “it was processed in Australia” without qualification removes a question that is otherwise yours to answer.

Further detail on hosting, encryption, access control and residency is on the security page.

What Are the Indicators, and What Does One Mean?

Alongside the comparison, the system examines each document as a file and surfaces indicators that it may have been altered.

Each indicator is presented twice: a plain-language summary of what was observed, and a fuller explanation the investigator can open when they want more than the summary. The point of that second layer is that an investigator is never asked to act on something they cannot interrogate. If they are going to put their name to a disposition, they should be able to read the reasoning first.

Three properties govern what an indicator is allowed to be:

• Observation tier only. The system reports what it observes. It produces no score, no confidence band and no verdict, and it never states that a document is forged.
• An indicator is not a finding. It is a reason to look more closely. On its own it establishes nothing about any person.
• Uncertainty degrades to silence, not accusation. Where the evidence is not conclusive, the system says less, not more.

That posture is deliberate, and it was hardened over many review rounds. In a workplace investigation, a wrong accusation is a far more expensive failure than a missed observation, and the software is built on that assumption rather than against it.

How Does an Investigator Record Their Judgement?

Every indicator has to be dispositioned by a person before it means anything. The investigator has three options:

Disposition	What it records
Confirmed concern	The investigator has reviewed the indicator and considers it warrants investigation
Possible	The investigator has reviewed it and is not yet in a position to resolve it either way
Discounted	The investigator has reviewed it and set the concern aside

Note what is not on that list. There is no “authentic” option and no “genuine” option. No such disposition exists, and none will be added.

The vocabulary is one-directional on purpose. “Discounted” means the concern has been set aside - it does not mean the document has been cleared, and it is not capable of being read that way. The disposition is the investigator’s judgement of the analysis, never a claim about the document. That distinction is the whole design, and it is why the scale stops where it does.

How Is This Different From Evidence Management?

There are two integrity questions in an investigation and they are often collapsed into one. They should not be.

	Evidence management	Document comparison and alteration indicators
The question	Has this file changed since we received it?	What can be said about a document that may already have been altered before it reached us?
What is compared	The file now against the file at intake	The file as an object, or two files against each other
Certainty available	High - a hash either matches or it does not	Never certain. Indicators only
The output	A verification result	Observations and differences, for an investigator to assess
Who concludes	The record concludes	The investigator concludes

Chain of custody, intake hashing and access logging answer the first question with certainty, because the platform holds both ends of the comparison. The capability on this page addresses the second, where nobody holds the original and certainty is not available. Most investigations need both, and they work together: custody establishes what happened to the file in your hands, and this establishes whether there is anything worth looking at from before that.

Who Is Accountable for the Conclusion - the Software or the Investigator?

The investigator. Without qualification.

The conclusion is the investigator’s. The software’s role is to make sure they had the chance to look.

This is the question the Australian legal and governance community is currently asking loudest about AI-assisted evidence analysis, and it is worth answering directly. Some tools are built to return a probability that a document is inauthentic. SentinelOps is built on a different premise, because a number invites the operator’s job to shrink to accepting or overriding it - and that moves the substance of the decision into the product while leaving the consequence with the person.

SentinelOps takes the opposite position and accepts the commercial cost of it:

• The system produces no number to accept or override, so there is nothing for an investigator to defer to.
• Nothing enters the case record until a named person has reviewed it and recorded a disposition.
• Every indicator, every disposition and every person is recorded in the audit trail.
• If the matter is later tested, the person who can explain how the assessment was reached is the investigator who reached it. They are the one with the specialised knowledge and the one whose reasoning is on the record.

The most important fact underneath all of that: the assessment is produced by documented rules, not by a language model. The evaluative outcome is computed in code from documented rules. The language model narrates observations into readable investigator language and plays no part in producing or adjusting the outcome - a model cannot shape an outcome it does not produce. This is the same principle that governs every other AI-assisted capability in the platform.

What Happens When It Is Wrong, or When the Evidence Is Not Conclusive?

An indicator is an observation, and observations can have innocent explanations. That is precisely why the system does not convert one into an accusation. Four design decisions follow:

1. Uncertainty produces less output, not more. Where the evidence for an indicator is not conclusive, the system reports the weaker, factual observation, or says nothing. It does not escalate to fill a gap.
2. A single observation cannot escalate on its own. Corroboration is required before the strongest characterisation is available.
3. A partial run declares itself. If an analysis does not complete fully, the record says so rather than presenting as complete. An investigator is never left to assume that silence meant a clean result.
4. A correction is visible as a correction. Completed analyses are never modified. Re-analysis writes a new record, and the original remains exactly as it was when an investigator relied on it. Nothing is silently overwritten.

The last of those matters most when something goes wrong. A tool that quietly updates its own past output destroys the ability to explain what an investigator knew at the time they acted. This one cannot do that.

How Is the Analysis Recorded in the Audit Trail?

Every run is version-stamped and written to the same append-only record that covers the rest of the investigation. The record captures the file hash of the item analysed, the versions of the components that produced the analysis - including the rules version and the model identifiers - the timestamp, and the user who requested it. The indicator, the investigator’s disposition and the identity of the person who made it are recorded together.

That combination answers the question that gets asked years later, in a tribunal or an internal review: which engine produced this, and can it be reproduced? Without a version stamp, that question has no answer at all.

Will an Assessment Produced This Way Survive a Court, Tribunal or Regulator?

Admissibility is decided by the court or tribunal on the facts of the particular proceeding, and no software vendor can promise it. What software can do is preserve the conditions that let the question be answered properly rather than left open. Three features of Australian evidence law shaped how this was built.

The court does the authenticating, not the tool. Under the uniform Evidence Acts - the Evidence Act 1995 (Cth) and its counterparts in New South Wales, Victoria, Tasmania, the Australian Capital Territory and the Northern Territory - s 58 provides that where a question arises as to the relevance of a document or thing, the court may examine it and draw any reasonable inference from it, including an inference as to its authenticity or identity. Section 183 extends comparable inference-drawing to questions about the application of the Act to a document or thing. Authenticity in an Australian proceeding is something the court reasons its way to. A tool returning a verdict would be purporting to do the court’s work, and would invite exactly the challenge it was bought to avoid.

Machine-produced outcomes attract a presumption, and that presumption is rebuttable. Section 146 of the Evidence Act 1995 (Cth) provides that where a document or thing is produced by a device or process, and it is reasonably open to find that the device or process is one that, if properly used, ordinarily produces a particular outcome, it is presumed - unless evidence sufficient to raise doubt is adduced - that the device or process produced that outcome on the occasion in question. The practical consequence is that doubt displaces the presumption. That is why every run is version-stamped and the record is append-only: so the question of which version produced an analysis has a recorded answer rather than a recollection.

The person with the specialised knowledge is the person who gives the opinion. Section 79 admits opinion evidence wholly or substantially based on a person’s specialised knowledge acquired through training, study or experience. Here, the person who forms the assessment is your investigator. They reviewed the indicators, they recorded the disposition, and they can be asked how they reached it. The software’s contribution appears in the record as what it was: an observation that prompted a human to look.

For workplace investigations the more common test is not a court at all but the Fair Work Commission or an AHRC Positive Duty review, where the question is whether the process was fair and whether it can be demonstrated. The same record answers it.

Public sector teams should also note that the Australian Government Investigations Standard 2022, effective 31 October 2022, requires entities to maintain appropriate information-management and evidence-handling protocols and to use suitable electronic systems across the investigation lifecycle. A capability that records what was observed, who dispositioned it and on what version of the system is designed to sit inside that expectation rather than beside it.

What Are the Honest Limits?

These are limits on what an indicator means. They are not an inventory of what the system examines.

The system will never tell you a document is genuine. Absence of indicators is not evidence of authenticity, and treating it as such would be the most dangerous thing this tool could do. There is no “authentic” outcome in the design and none will be added. The floor of the scale is “no indicators found”, and that outcome carries a standing limitation notice wherever it appears.

An indicator is not a finding. It is an observation that gives an investigator a reason to look more closely. It is not proof and it is not an accusation.

Nothing here is a substitute for a forensic document examiner where a matter genuinely requires one. This capability is designed to help an investigator decide, early and cheaply, whether a document is worth that escalation - not to replace the escalation.

We make no claim of independent validation or third-party testing of this capability, because none has been performed. Where an evaluation needs more than a public page can carry, we would rather run a supervised walkthrough with your technical reviewers than publish a claim we cannot support.

Why Do We Publish What It Does, but Not How It Works?

We publish what it does. We do not publish how, because that would be a manual for defeating it.

This is a deliberate policy and we would rather state it plainly than have a buyer discover it as an evasion halfway through an evaluation. Any public description of the specific things this capability examines is, read from the other direction, a checklist of things to remove from a document before submitting it. Every additional detail published lowers the cost of defeating the capability for everyone who uses it, including you. A vendor that publishes its method in full is not being more transparent than one that does not - it is selling a capability with a published countermeasure.

What that means in practice:

• The core decision points are public and they are on this page: what the capability does, what it will never claim, who is accountable, what happens when it is uncertain, how it is recorded, and what its limits mean. None of that requires knowing the method. Evaluating buyers receive a fuller operating description, and technical due diligence is handled under confidentiality.
• Evaluating buyers receive more. Operating envelope, workflow, integration, residency and retention, the role and permission model and long-form limitations are available to buyers under evaluation.
• Technical due diligence goes further again, under NDA, and typically as a supervised session with named reviewers rather than a document that can be forwarded.

The line we hold is the one that matters: we will not publish a sentence that makes the capability easier to defeat, and we will not withhold a sentence a buyer needs in order to judge whether they can rely on it.

How SentinelOps Helps

The situation	What SentinelOps provides
Two versions of a document to compare, read line by line across two screens	Side-by-side comparison of textual and visual differences between two evidence items
Comparison done in a separate tool, with evidence exported out and results carried back by hand	The comparison runs on evidence already in the case file. Nothing leaves, nothing is re-uploaded
No clear answer to where a third-party tool processed the document	All analysis performed in Australia. Evidence never leaves the country
A tool returns a probability score and the investigator has to decide whether to trust it	No score is produced, so there is nothing to defer to. The investigator’s disposition is the output
An investigator asked to act on an observation they cannot interrogate	Each indicator carries a plain-language summary and a fuller explanation that can be opened
A decision challenged two years later, with no record of which version of the software produced it	Every run version-stamped with the rules version, component identifiers, timestamp and requesting user
Procurement asks who is accountable for an AI-assisted assessment	A named investigator, recorded in the audit trail, whose disposition is the conclusion

Used by workplace investigation teams, insurance special investigation units and financial crime and AML teams, alongside evidence management and audit trails.

Frequently Asked Questions

Can SentinelOps compare two documents against each other?

Yes. Two evidence items already attached to the case can be compared side by side, showing both textual and visual differences, with three views the investigator can move between: prior version, current version, and difference view. Alteration is often only visible as the difference between two files, which is why comparison sits at the centre of this capability rather than at the edge of it.

Do I have to export evidence to another system to compare documents?

No. The comparison runs on evidence items already in the case file, and the result is attached to the case like any other piece of work. There is no export, no second login and no re-upload, so the chain of custody does not have to be re-established by hand each time a document is examined.

Where is the analysis performed?

In Australia. All analysis is performed in Australia and evidence never leaves the country. Customer data is stored in Australia, and the platform is built, developed and tested in Australia. Like any modern platform SentinelOps is built partly from supplied components, some of which are third-party services; those services run in Australian regions and evidence does not leave the country.

Does SentinelOps tell me whether a document is genuine?

No, and it never will. The system will never tell you a document is genuine, because absence of indicators is not evidence of authenticity. There is no “authentic” outcome in the design and none will be added. The lowest outcome available is “no indicators found”, and it carries a standing limitation notice wherever it appears.

What can an investigator record against an indicator?

One of three dispositions: confirmed concern, possible, or discounted. The vocabulary is one-directional by design and there is no option that clears a document. “Discounted” means the investigator has set the concern aside; it is a judgement about the analysis, not a claim about the document, and it is recorded against a named person in the audit trail.

Does an AI decide the outcome?

No. The assessment is produced by documented rules, not by a language model. The evaluative outcome is computed in code from documented rules, while the language model narrates observations into readable investigator language, so a model cannot shape an outcome it does not produce. Each indicator also carries a fuller explanation the investigator can open rather than having to take on trust.

How is this different from the file-integrity hashing in evidence management?

They answer different questions. Evidence management answers “has this file changed since we received it”, using hashing at intake and a chain-of-custody record, and it answers with certainty. This capability addresses what can be said about a document that may already have been altered before it reached you, where certainty is not available and the output is differences and indicators for an investigator to assess. Most investigations need both.

Can an analysis be reproduced or explained years later?

Yes. Every run is version-stamped with the file hash, the versions of the components that produced it including the rules version and model identifiers, the timestamp and the requesting user. Records are append-only, so re-analysis writes a new record and the original remains exactly as an investigator relied on it. That is what allows the question “which engine produced this, and can it be reproduced” to be answered rather than estimated.

Why does SentinelOps not publish how the analysis works?

Because publishing the method would be a manual for defeating it. A public description of what the capability examines is, read from the other direction, a list of things to remove from a document before submitting it. The core decision points are published openly, evaluating buyers receive a fuller operating description, and technical due diligence is handled under confidentiality in a supervised session.