intrface

Polis Interface

Civic infrastructure that treats government data as something you check, not something you believe.

Open source · pre-deploymentPublic dataCheckable claimsNothing self-reportedPre-deployment
6
Steps from filed document to public check
10
Rules deciding who sees what
Checked on every request. In doubt, denied.
0
Accounts needed to check a claim
Anyone re-checks it without asking permission.
0
Public bodies running it today
Pre-deployment, and this page says so.
Read the source — github.com/basicalex/polis

A governance graph, not a document dump

Polis models what a public body actually produces — decisions, promises, budgets, meetings, officials — as a graph. Every public claim in that graph points back to the source document it came from, and the document carries proof of its own integrity.

Two surfaces, one dataset

A campaigning surface publishes a program. An accountability layer tracks the same program against what was delivered. Both read the same verifiable records, so the promise page and the record page cannot drift apart while nobody is looking.

Every claim has an address

"The council approved the budget in March" is not a sentence in Polis. It is an edge to a decision, which resolves to a filed document, which resolves to a hash, a seal, and a timestamp a stranger can re-check without asking anyone's permission.

Where the trust actually comes from

Four pieces are worth naming, because they are the parts a public buyer or an auditor would go looking for.

  1. 01

    The audit ledger is hash-chained inside the insert transaction

    Each event stores the hash of the event before it, computed and written in the same transaction that inserts the row. Two writers racing each other cannot both win.

    Why it mattersAn audit log you can quietly reorder afterwards is not evidence of anything.

  2. 02

    Documents are verified, not just uploaded

    A canonical hash, an eIDAS-shaped e-seal, and an RFC 3161 timestamp from an outside authority travel with the file. Redaction rules take precedence over publication, so a document can be proved authentic without exposing what should stay closed.

    Why it mattersAuthentic and publishable are two different questions. Systems that answer them together leak.

  3. 03

    Policy gates fail closed

    Ten OPA/Rego modules decide who may read and write what. When the policy layer cannot answer, the request is denied rather than allowed through.

    Why it mattersMost access-control bugs are a check that silently returned nothing and was read as a yes.

  4. 04

    An elected official cannot mark their own promise delivered

    The accountability layer keeps the actor who claims separate from the actor who confirms. A status change to delivered records who confirmed it, and that person is not the subject of the promise.

    Why it mattersSelf-reported delivery is the standard failure mode of a promise tracker.

eIDAS, RFC 3161, GDPR-shaped redaction: the regulation sits in the data model, not in a compliance appendix written after the build.

The status label is part of the product

Polis labels every surface in its own documentation as [verifiable], [demonstration/stub], or [not yet live]. The simulated pilot says it is simulated in its first line.

[verifiable]
Backed by data in the system. Follow it to a source document and check the hash yourself.
[demonstration/stub]
The screen works; what sits behind it is a placeholder. Do not plan a rollout around it.
[not yet live]
Specified and designed. Not built.

This is what an institution buying software should demand, screen by screen. A vendor who can tell you which of their screens is real, which is a demo, and which is a slide has given you something to plan against.

How a document becomes checkable

There are no screenshots on this page — Polis is not deployed, and a screenshot of an undeployed system proves nothing. This is the pipeline as built: from the file a clerk uploads to the verdict a citizen gets.

source file → public verdict

  1. 01

    Document

    A decision, contract, or set of minutes, exactly as filed.

    minutes.pdf

  2. 02

    Canonicalize

    Bytes normalized to one form, then hashed. Same file, same hash, every time.

    sha256 9f3c…21ab

  3. 03

    Seal

    The issuing body signs the hash, not the file. eIDAS-shaped e-seal.

    e-seal

  4. 04

    Timestamp

    An RFC 3161 authority attests that the hash existed at a given moment.

    TSA token

  5. 05

    Registry

    Hash, seal, and token are recorded together and linked to the claims that cite them.

    registry entry

  6. 06

    Verify

    Anyone re-hashes the file and checks it against the record. No account needed.

    verdict: valid

each row carries the row before it

  1. #0140

    document.verified

    Minutes accepted; hash, seal, and timestamp written.

    prev 6b81f4

    self 7d2e94

  2. #0141

    promise.linked

    A program item is bound to the decision it depends on.

    prev 7d2e94

    self 4a17c0

  3. #0142

    promise.status.changed

    Status moves to delivered — recorded with the confirming actor, who is not the official.

    prev 4a17c0

    self c95d3b

Hashes here are illustrative. In the running code, a row's previous-hash is computed and written inside the same transaction that inserts the row, so two writers racing each other cannot end up with two valid chains.

Where a claim has to be checkable.

If you are building something where a citizen, an auditor, or a regulator has to be able to check the claim rather than take it on trust, that is the conversation we want.