From a read-only connection to a finding you can defend

EVIDENT reads three surfaces, and answering only the first is how an inventory ends up wrong. A database holds personal data. Application code writes some of it into logs, where no schema can see it. An API hands it to somebody else entirely. Those are three surfaces this platform correlates, not a claim that personal data lives in only three places — object stores, queues, data lakes, backups and third-party systems hold it too, and they are outside what this reads today rather than outside the problem.

EVIDENT reads all three, matches them against each other, and keeps the reasoning.

What happens, in order

1. You point EVIDENT at a source. A read-only connection to PostgreSQL, SQL Server, MySQL, MariaDB, Oracle or SQLite, and a repository it can read.
2. It reads the catalogue: tables, columns, types, constraints, foreign keys and comments. Structure, not rows — that is the default and it is the mode most security teams will approve.
3. It reads the code that maps onto that catalogue. Entity Framework, Prisma, TypeORM, Sequelize, SQLAlchemy, Django and JPA are read as the mappings they are, so a field in code is matched to the column behind it.
4. It reads what you expose. OpenAPI descriptions and GraphQL schemas are reviewed for the questions a security reviewer will ask of them.
5. Deterministic rules produce candidate classifications, each with a confidence and a stated reason.
6. The correlation engine looks at combinations rather than single columns, because a date of birth beside a postcode is a different risk from either alone.
7. Anything the rules cannot settle waits for a person — in a review queue, and on the field itself wherever it is drawn.
8. A confirmed decision becomes part of the evidence-backed assessment. A corrected one does not: naming a different element is recorded with who did it and when, and leaves the field open for review, because a correction nobody has checked is a better proposal rather than an answer. Reports are export views of that state rather than the source of truth, and on a later run the earlier decisions and the evidence behind them are still there — what changed comes back for review.

The pipeline, and where it is going

Sources -> Connectors -> Normalised evidence
                                |
                      Rules and correlation
                                |
              Findings, risks and evidence gaps
                                |
                Framework mapping + human review
                                |
                   Remediation -> Verification
                                |
                        Immutable history

The part that matters is WHY

Any tool can produce a list of findings. The question a reviewer asks about every line of that list is how you know — and that is the question most tools cannot answer.

Every finding EVIDENT produces names the evidence it came from and the exact version of the rule that produced it. Where a conclusion was inferred rather than observed, it says so, states its confidence and lists what it rested on. You can disagree with one finding without having to distrust all of them.

What it tells you it could not see

Every tool in this category produces findings. Many do not produce the other half: the list of things they never checked.

A report that does not say what it could not examine is a report a reader assumes is complete. EVIDENT states its limits inside the document, under their own heading — whether a token is really validated, whether authorisation is enforced per record, whether there is any rate limit at all. That is the reason a report from it survives being read by somebody whose job is to disbelieve it.