Skip to main content

Proof & Accountability

After an autonomous effect, can you prove what authority was actually in force?

Logs show that something happened. That is rarely the question afterwards.

A consequential autonomous action creates harder questions. They arrive weeks later, from people who were not in the room.

The questions a log does not answer
01
What power had been delegated?
Not what the credential permitted. What the organization actually delegated for this work.
02
Who was entitled to approve it?
A named person or body inside the organization, entitled to grant that power at the time.
03
Was it current?
Power granted for a migration two quarters ago may not still be in force today.
04
What decision was made?
The action proceeded, or it did not. Either way there should be a record of the call.
05
What effect occurred, or was prevented?
What landed, and what was stopped. Prevention is an outcome worth establishing too.
06
Can someone outside the live WhiteFin runtime verify the evidence?
Without our software running, our people present, or our interface open.

The difference

“We monitored it” and “we can establish it” are not the same sentence.

Most organizations have the first one. Telemetry, dashboards, an event trail. It is real work and it is worth having.

The second one is a different thing. It is a record another party can check for themselves. The distinction is invisible until someone with standing asks a hard question, which is the worst moment to discover you only had the first.

We monitored it

A record you produced.

Written by your systems. Stored in your systems. Read back through your interface and explained by your people. In calm conditions that is enough. Its credibility rests on your organization’s account of itself, and after a consequential incident reasonable people will test that.

We can establish it

A record someone else can check.

The reviewer checks it themselves, on their own machine, without you in the room and without taking your word for any step. That is a higher bar. It is also the only one that holds when the questions get serious.

A record you made is an account. A record someone else can check is evidence.

The questions that arrive with the incident

Four rooms. The same six questions.

Incident review. The board. A regulator. Internal audit. They arrive at different times, with different authority, and they converge on a short list.

None of them is asking for a dashboard. Each is asking whether the organization can still account for the power it gave away.

01
Asked by · Incident review

What Authority was valid?

Not what was technically possible, and not what the token allowed. What bounded power the organization had deliberately delegated to this system, for this work, at that moment.

02
Asked by · Audit

Who was entitled to approve it?

Delegated power widens for a new use case and narrows after an incident. Every change was somebody’s decision. Each one should still point back to a person entitled to make it, long after the meeting is forgotten.

03
Asked by · Incident review

What decision was made?

The action was allowed, or it was refused. A decision nobody recorded cannot be defended later, however sound it was at the time.

04
Asked by · The board

What effect occurred, or was prevented?

Boards ask what happened. They ask just as often what nearly happened, and why it did not. Both belong in the record.

05
Asked by · Regulator

Can the evidence be independently verified?

Evidence that only the vendor’s own system can read is weak evidence. It puts the vendor between an institution and its own account of what happened.

06
Asked by · Everyone in the room

Is the scope of the claim explicit?

What the evidence covers, and what it does not. A claim with no stated boundary is not a stronger claim. It is a weaker one, and an experienced reviewer reads it that way.

Independent verification

A reviewer should be able to check the record without us.

Evidence only the vendor can read is weak evidence. It places us between an institution and its own account of what happened. So we hold ourselves to a standard that is uncomfortable to publish honestly.

The principle

Customers should not need WhiteFin in order to verify WhiteFin.

That is the standard we hold ourselves to. It is a principle and a goal, not a finished capability claim. Here is the honest version of where it stands today, in full:

Where it stands today

Evidence bundles export with a standalone verifier that runs on the recipient’s own machine using only the Python standard library and cryptography — no WhiteFin install, no network. Verification is strongest when the signer public key was pinned out of band at install: with the pinned anchor, a re-signed bundle fails; without it, the verifier proves internal consistency rather than provenance. The signing key is held by the deployment, so a valid signature attests that the record has not been altered since it was written — not that WhiteFin wrote it.

Read the last sentence again. It is the part most vendors leave out, and it is the part a serious reviewer asks about first. We would rather you find it here than find it yourself in an evaluation.

Whose evidence it is

The deployment holds the keys and the records.

WhiteFin runs inside the customer environment. The evidence is produced there and it stays there. The signing key is held by the deployment, not by us.

That is a design requirement, not a feature. Evidence you have to request from a vendor depends on that vendor still existing, still cooperating, and still being in business on the day you need it. An institution should not have that dependency sitting inside its own account of what happened.

How the deployment operates

WhiteFin is customer-hosted. There is no phone-home, no analytics endpoint, no update check, and no license-server call — licences are signed files verified offline. Any outbound traffic goes to model or embedding providers the customer configures, and can be disabled.

Where that constraint does not apply to you, it never comes up. Where it applies — regulated, sovereign, private, or disconnected environments — nothing else gets discussed until it is answered.

Honest scope

We state what is covered. We do not imply the rest.

The tempting move for a vendor is to leave scope vague and let the reader assume it covers everything. That assumption survives exactly until the first person checks. We would rather be narrow and correct.

WhiteFin declares what is governed and what is not. Evidence covers the declared governed scope.
Activity outside that scope is outside the claim. We say so, rather than letting the silence do the work.
The declared scope is specific, and it belongs in a technical conversation with your architects. It does not belong in a headline on a web page.
We do not publish coverage percentages, governance scores, or benchmark figures. A number nobody outside can reproduce is marketing, not evidence.
A record establishes what was decided and what happened. It is not a statement that delegating the power was the right call. That judgment stays with the organization.

Partial visibility does not become a universal claim by being described carefully.

Standards reference

Where this has already been examined outside WhiteFin.

Selected WhiteFin execution-proof objects were mapped to the RFC-0509 Receiving-Boundary Reliance Grammar in a controlled bilateral exercise; see https://3pmobile.com/standards/rfc-0509-mapping.

The WhiteFin reference page, including the published file and its checksum, is at whitefin.ai/standards/rfc-0509-mapping.

What would you need to establish, and to whom?

If an incident review, a board, a regulator, or an internal audit is going to ask what authority governed an autonomous action, that is a concrete requirement. Bring it and we will tell you plainly what we can establish, what we cannot, and where the boundary sits.

We use cookies for analytics to understand how visitors use our site. No advertising cookies. Privacy Policy