CHARTER
Your Charter¶
A Charter is the set of principles your organization writes down to govern its AI agents, kept as an immutable, versioned record with a SHA-256 fingerprint anyone can verify. It is what your policies derive from, and what an audit is measured against.
Your Charter is yours. EKKA holds it, versions it, and prints the fingerprint that proves which text was in force on any given day. The words are written by your organization.
Amending a Charter adds the next version and leaves the old text readable, because a decision made last month has to be explainable against the principles that stood last month.
What is an AI Charter?¶
A short document, in your own words, saying how your organization expects its automation to behave. It is the top of the governance chain:
Charter sets the principles. Policies turn a principle into a rule EKKA checks before a plan runs, a permission is issued, or a plan is created. Grants say which agent may touch which system. Receipts are the signed evidence of what actually happened.
Read top to bottom it answers the question an auditor asks: what did you say you would do, what did you enforce, and what did the machines actually do.
Who writes it?¶
You do. EKKA supplies the courtroom, never the morals. There is no template that decides your principles for you.
What EKKA supplies is the part that is hard to do yourself: a record the database refuses to rewrite, a version history that only moves forward, and a fingerprint that proves which text was in force when a decision was made.
You do not have to take that on trust. Keep your own copy of the file and run
sha256sum on it: if the digest matches what EKKA prints, the text is the text
you adopted. That check needs no EKKA service and no EKKA permission.
How is a Charter different from a policy?¶
A Charter is a principle a person reads. A policy is a rule a machine checks.
| Charter | Policy | |
|---|---|---|
| Written for | people | EKKA |
| Says | "any automation we run has a person accountable for it" | "no plan runs outside office hours" |
| Enforced | by the policies derived from it | before a plan runs, a permission is issued, or a plan is created |
| Changed by | adopting the next version | publishing the next version |
Both are versioned, both are permanent, and neither is ever rewritten in place.
Write one and adopt it¶
A Charter is a short Markdown document. Keep it to principles a person can hold in their head:
# Charter
We ship what we can prove. Every claim about our systems has a check
anyone can run.
Customer data stays where the customer put it. We read it only with
their consent, and the record of that read is permanent.
Any automation we run has a person accountable for it.
✓ Charter adopted. Version 1 governs this organization.
fingerprint fd8cd2f7f0eb7ca22225bab5b82d38b9ad3bbe49a144c0257b8cabdd631bc348
prove this is your file sha256sum charter.md
read it back ekka charter show
How do I prove which version was in force?¶
An auditor's hardest question is not "what are your controls". It is "prove that this was your control on the day this happened". A wiki page cannot answer it: it has one current version and no proof of what it said before.
Every Charter version carries a SHA-256 fingerprint of the exact bytes, and it is not a value only EKKA can compute. Run the standard tool on the same file and compare:
Same bytes, same digest. That is what makes "this is the Charter we adopted" a statement someone else can check rather than take on trust.
Read what is in force¶
CHARTER VERSION 1 (ACTIVE)
adopted 2026-08-24
fingerprint fd8cd2f7f0eb…
# Charter
We ship what we can prove. Every claim about our systems has a check
anyone can run.
Customer data stays where the customer put it. We read it only with
their consent, and the record of that read is permanent.
Any automation we run has a person accountable for it.
check this text yourself sha256sum charter.md
every version ever adopted ekka charter history
The text prints as it was adopted, line breaks included. -v prints the whole
fingerprint instead of the leading characters, and --json gives the same
answer for a script.
Anyone in your organization can read the Charter and its history, including members with view-only access. Adopting and amending is for owners and admins.
Amend it¶
Amending adopts the next version. The previous one stays readable at its own number:
✓ Charter amended. Version 2 is now in force; version 1 stays readable.
fingerprint 4e2a8c9af744236dd2dd24d2e5bf3d63bca129782c3ea92ccf3bfc3139c6ee50
--expect-version is the version you believe you are amending. If somebody
adopted in between, the amendment is refused and the refusal names the version
actually in force, so two people editing the same document do not overwrite each
other.
Adopting text that is byte-for-byte what already stands is also refused. The history never says something changed on a day nothing did.
Every version, newest first¶
VERSION STATUS FINGERPRINT ADOPTED
2 active 4e2a8c9af744 2026-08-24
1 deprecated fd8cd2f7f0eb 2026-08-24
• A version is never rewritten. Amending adopts the next one and the old text
stays readable.
read one of them ekka charter show --version 1
Read an older version by number, and the screen says plainly that you are not reading the rules currently in force:
CHARTER VERSION 1 (DEPRECATED)
⚠ This version is not in force. You are reading what governed this organization in the past.
Why the old versions stay¶
Receipts are permanent, and a receipt from March is read months later by somebody asking whether the decision was reasonable. That question is only answerable against the principles that stood in March. A record that could be edited afterwards would answer it with today's words, which is the one answer nobody can rely on.
So a version is never rewritten and never deleted. Amending moves forward.
See Governance receipts for the record of what your agents
actually did, and CLI reference for every
ekka charter command.