SOLUTIONS · 09
Every decision leaves a record.
When an auditor asks why a request was blocked, the answer is not a log line but an evidence package with the full reasoning behind the decision. Wardline builds that package without storing the text, and makes it provable that the record has not been altered since.
THE PROBLEM
A log line is not evidence
Keeping the prompt to explain a decision means moving personal data into logs, backups and every system that reads them. Not keeping it means nobody can say later why the decision was made.
The record itself is the second question. Anyone with admin rights can change a database row. An audit needs to be able to check, independently, that a record has not changed since it was written.
HOW IT WORKS
Step by step
Six-layer package
Any decision other than ALLOW, and any decision with a flag, produces a six-layer package: decision, reasoning, sub-category, evidence, confidence and action map. A flagless ALLOW produces compact evidence.
Position, not text
Evidence carries the message number, byte range, entity type and validation result. Instead of the text it stores a keyed HMAC, so you can see that the same value repeats without being able to read it.
A chain per tenant
Each record includes the hash of the previous one, and a single writer maintains the chain. Inserting a record or editing one breaks every hash after it.
Immutable storage and timestamps
Records go to storage with object lock enabled. Each day the tenant’s Merkle root is sealed by the internal timestamping service.
Verification and SIEM
The proof path for a record is available from the API and can be verified independently with a command-line tool. Alerts go to your SIEM through Splunk HEC, syslog, Microsoft Sentinel or a signed webhook.
DECISIONS
Which decision you get, and when
| Decision | When | Example reason code |
|---|---|---|
| ALLOW | A flagless ALLOW: compact evidence with the decision, reason code and version information. | POLICY.DEFAULT_ACTION |
| MASK | For every masked value: position, entity type and validation, never the value itself. | POLICY.MASK_APPLIED |
| DENY | A dependency was unreachable and the application fails closed: the refusal, and which dependency failed and why, are in the evidence. | POLICY.FAIL_CLOSED |
EXAMPLE
A question six months later
Internal audit asks about a request masked in March in a call centre application. The analyst opens the evidence package by event ID: which rule matched, which entity was found at which byte range, which policy version applied. The auditor takes the proof path for that record and verifies on their own machine that the chain links to the sealed root for that day.
| Decision | MASK |
|---|---|
| Event | evt · tenant chain position 88412 |
| Layers | 6 · full package |
| Policy | v37 · signature verified |
| Seal | daily root · timestamped |
| Reason codes |
|
| Flags | none |
| Risk score | 0.99 |
CONFIGURATION
What administrators control
Retention
How long evidence and audit records are kept, aligned with the object lock period.
Content view
Off by default. If the organisation chooses, a masked content view can be enabled for authorised roles, and turning it on is itself audited.
SIEM targets
Which event types go to which target; target addresses are subject to the egress allowlist.
Roles
Who can see evidence is governed by the eight-role permission model.
RELATED
Capabilities that work alongside
See it on your own traffic.
In a demo session we walk through this flow with examples your security team picks, in the console’s evidence viewer.
Request a demo