DataByte
Explainability Fabric

Proof, not assertion.

Governance is a property of the architecture here. Every action becomes a decision record carrying what authorised it, the chain is cryptographically verifiable, and compliance controls run continuously against live platform state.

An action evaluated against policy before it runs, allowed or refused, written to a hash-chained audit store that produces controls, evidence, and framework mappings continuously
Explainability

Every action carries the rule that allowed it.

Every meaningful action on the platform is captured as a structured record with fixed fields. It carries the full trust chain behind the actor: the human, the identity provider that authenticated them, the service acting on their behalf, and the token that established the delegation. Each hop is auditable on its own.

Alongside that sits the action in a canonical vocabulary, the resource in a platform-wide naming scheme, the policy version that authorised it with the rules that fired, and the effect it had. Because the records are causally linked, you can walk from an outcome back to the decision that caused it.

That is what explainability means here. When an auditor asks why a change was permitted, the answer is a record, and the record names the rule.

Refusals carry the same discipline. Every control returns a sentence someone can act on, together with the state that would have let it pass: the capacity still free, the transitions currently open, the approval roles outstanding. A refusal nobody can act on is a refusal that gets routed around.

Five dimensions on every record
  • Identity. the whole delegation chain, from human to provider to service to token
  • Action. a canonical, machine-readable action type and the intent behind it
  • Resource. a stable platform-wide identifier for whatever was acted on
  • Policy. the policy version consulted and the rules that decided the outcome
  • Effect. what actually changed, so cause and consequence stay joined
Immutability

Tamper-evident, which is the version you can prove.

Most platforms that claim immutable audit mean retention settings, revoked delete permissions, and access control on the log. None of that survives a database administrator with raw SQL access or a compromised privileged account. It prevents alteration until it does not, and then leaves no trace.

The standard worth holding is different: alteration has to be mathematically detectable, including by an insider. Each record hashes its own fields together with the hash of the record before it. Change one character and every hash downstream stops matching. Exactly one process is permitted to write to the audit store, and it is unreachable from any business service.

How the audit chain is made tamper-evidentThree consecutive decision records. Each stores a hash of its own fields and the hash of the record before it, so changing any field breaks every link that follows. A single writer, the audit ingestion service, computes and signs the chain. The Merkle root of each segment is published to an external anchor outside the platform, so an auditor can verify history independently.Audit Ingestion Service, the only process permitted to writeDecision Recordn − 1record_hashprev_hashsignatureDecision Recordnrecord_hashprev_hashsignatureDecision Recordn + 1record_hashprev_hashsignatureAlter one field and every hash after it stops matching. The break is detectable.Merkle root published to an external anchorso verification needs no access to our systems
Each record carries a hash of the one before it.
Compliance as code

Controls that execute, on a schedule, against real state.

A control here is a versioned artefact held under source control. It states the condition that must hold, carries the query that checks it against live platform state, defines what counts as evidence, maps to the framework clauses it satisfies, and specifies what happens when it fails.

Policies are declarative and version-controlled, evaluated by Open Policy Agent before an action runs. Preventive controls make a non-compliant action impossible; detective controls sweep the audit history for violations that slipped through. Both are continuously verified for drift.

Each control also declares which of its inputs it trusts. A claimed current state is checked against the stored one, an approval is verified against the role that approver holds at the moment of the decision, and an order total is recomputed from its lines. Whatever the caller says about itself is treated as a claim to verify.

The five parts of an executable compliance controlOne control carries an assertion stating the condition that must hold, an evaluation query run against live platform state, an evidence specification, a mapping to the framework clauses it satisfies, and a remediation specification describing what happens when it fails.One controlversioned, executable,evaluated on a scheduleAssertionThe condition that must hold, checkableEvaluation queryRun against live platform stateEvidenceWhat counts as proof, integrity intactFramework mappingThe framework clauses it satisfiesRemediationOn failure: alert, correct, or change state
Controls evaluate against live state, continuously.
Pre-built control library

You do not start at zero coverage.

A new deployment inherits 70 controls across 16 domains, already evaluating and already producing evidence on the day it is switched on. One control frequently satisfies clauses in several frameworks at once, so the mapping is many-to-many and adding a regime mostly reuses controls you already run.

SOC 2 Type II

CC6 logical access is the densest overlap. Tenant isolation, role and attribute-based access, and API authorisation each evaluate on every request, and the authorisation record is the evidence.

GDPR

Articles 5, 6, 9, 17, 21, 30 and 44 to 49 have executable representations. Lawful basis, purpose compatibility, withdrawn consent, Article 21 objection, transfer mechanism and retention expiry are all decided before the operation runs.

PCI DSS

Requirements 3, 4, 7 and 8. Sensitive authentication data can never be persisted, PAN leaving the cardholder environment unmasked is refused, and a card number in a log value is caught by Luhn checksum whatever the field is called.

ISO 27001

Annex A.9 access management, A.9.4 secret handling, and A.12.1.2 change control. Credential-shaped values are detected by pattern, and a secret past its rotation window fails on its own.

SOX

IT general controls and business process controls. Self-approval is refused across payroll, procurement and release, approvers are checked against the role they hold at decision time, and an approval lapses when the artefact it covered changes.

CIS Kubernetes Benchmark

Sections 5.1 and 5.2, with controls cited by number in the policy metadata. Wildcard RBAC grants, privileged containers, writable root filesystems and anonymous bindings are refused at admission.

At audit time

Continuous assurance, so the audit stops being an event.

Point-in-time assessment leaves you exposed between cycles and turns every audit into a scramble for evidence. When controls evaluate continuously and evidence accumulates as a by-product, the posture is already there when someone asks.

  • A live compliance posture they can interrogate at any moment, including the months between audit cycles.
  • Evidence assembled continuously and exported with its integrity verifiable, so nobody spends the week before an audit gathering it by hand.
  • A chain they can validate themselves, with no privileged access to our systems and no need to trust our word for it.
  • For any given change: who initiated it, which policy version allowed it, what it touched, and what changed as a result.

Looking for our own certifications and how we are audited as a company? That is security and trust. This page is about the controls the platform runs for you.

Bring the control that failed your last audit.

We will write it as an executable control on the call and show you the evidence it produces.