Proof of Authority

A trust layer for consequential document actions where AI can assist, humans authorize, and POA preserves the evidence trail from decision to signature.

Comment

Inspiration

AI agents are becoming capable of creating, modifying, and preparing consequential documents with very little human intervention.

But the risk does not begin at the signature button.

A document can be correctly signed and still contain a material change that the human never intended to authorize.

That led us to a different question:

Where should the boundary between agentic assistance and human authority actually sit?

Proof of Authority is our answer.

What it does

Proof of Authority (POA) is an evidence layer for consequential document actions.

The agent can help structure and draft a document. The human decides what the document should say, which concepts matter, and what is allowed to proceed.

POA then preserves the history around that decision:

  • what the human authorized;
  • what evidence was required;
  • what artifact was released;
  • what the provider reported;
  • what executed document came back;
  • and whether the protected state remained continuous.

The core principle is simple:

The agent provides intelligence. It does not provide authority.

The agentic workflow

POA includes an AI-assisted Beta flow that can begin from a plain human instruction.

For example:

“Create a residential lease agreement.”

The agent proposes document structure and concepts, asks focused questions when information is missing, and produces a draft.

The human can edit, remove, or add concepts the AI missed and decides which changes should require approval.

Only after that human review does POA create the protected state used by the workflow.

The resulting artifact is then read back from the document itself rather than trusting what the model claims it generated.

This distinction matters:

AI proposal ≠ human decision ≠ authorization.

The consequence boundary

Most workflows treat signature as the important human boundary.

POA places an earlier boundary around the decision that makes a document eligible to reach signature.

Before release, POA compares the outgoing document against the human-authorized protected state.

If a protected concept changed without approval, the action is blocked.

If the state is consistent, the document may proceed to the signing workflow.

Foxit integration

Foxit provides the document and signature execution layer.

POA uses Foxit PDF Services to extract and inspect the actual artifact and Foxit eSign to execute the signing ceremony.

After execution, POA retrieves the resulting artifact and verifies continuity against the authorized history.

We validated the complete path with a real Foxit eSign ceremony involving one document and three sequential signers.

The final executed document returned with no unauthorized protected differences in the successful reference run.

Evidence, not conclusions

POA deliberately distinguishes between:

  • human assertions;
  • observations from documents;
  • external provider reports;
  • derived values;
  • conclusions.

It does not claim to determine absolute truth, legal authority, intent, or legal validity.

Instead:

POA preserves the facts from which what happened can later be reconstructed.

A value may be uncertain. Its origin should not be.

How we built it

POA is implemented in Node.js / JavaScript and integrates:

  • Foxit PDF Services
  • Foxit eSign
  • AI models through OpenRouter
  • WebAuthn-based assurance
  • a local append-only, hash-linked evidence ledger
  • deterministic pre-release gates
  • post-sign continuity verification

The agentic layer is intentionally separated from the authorization and release controls. Model output cannot directly call the gate, authorize a baseline, or release a document for signature.

Judge-ready demo

A judge can clone the repository and run:

npm test
npm run demo:workspace
The demo workspace is generated from scratch using the same production code paths used by the application.

It contains fictitious data and clearly marked sim- provider references.

It demonstrates both:

a transaction that passes the gate;
a transaction blocked because material protected values changed.

A real signed Foxit ceremony cannot honestly be reproduced offline without a Foxit account and real signers, so the repository documents the validated live run separately.

Judges who want to test the live integration can connect their own AI and Foxit credentials from Settings.

Challenges we faced

One of the hardest problems was avoiding false confidence.

A model may generate a plausible document but that does not make its output authoritative.

Foxit may report execution, but that does not automatically prove identity, intent, delivery, or legal authority.

Even our demo packaging exposed this problem: real evidence records could not simply be “sanitized” because changing stored content correctly broke their integrity hashes.

Instead, we built a deterministic judge workspace from scratch.

That constraint became part of the product philosophy:

Make evidence stronger. Make the claim smaller.

What we learned

The most useful boundary in agentic document systems may not be “human signs at the end.”

It may be:

the human explicitly decides what matters before the agent is allowed to create consequences.

That keeps AI useful without quietly turning model interpretation into authority.

What's next

V2 expands the evidence model without changing that principle.

Planned work includes:

external ledger anchoring;
stronger authority-grant evidence;
a Matter model for long-lived acts spanning multiple document transactions;
richer participant and channel modelling;
external signer assurance and receipts;
custom-field post-sign continuity.

The Matter model is intentionally not presented as a V1.x capability.

Today, POA preserves the history of one consequential document transaction at a time.

Built With

Share this project:

Updates

Submission history