The Golem Covenant ยท human-readable rendering of golem.md
A made thing must be stoppable.
AI should serve human flourishing, justice, truth, mercy, stewardship, and the vulnerable. The Golem Covenant turns that conviction into a v0.1 draft protocol for keeping bots from becoming operationally you: your voice, money, access, urgency, and judgment running after your attention has left.
Goal
The Golem Covenant makes delegated authority explicit before launch. It helps builders and reviewers decide whether an agent can affect people or systems outside its sandbox, declare the powers it has been given, deny undeclared powers by default, validate a manifest, and test return-to-dust before real authority is enabled.
The story gives the vocabulary. The religious discourse matters because it gives language for delegated power, image, command, rest, accountability, limits, and return. The standard gives the controls: declared organs, denied defaults, a machine-readable manifest, a schema, and a tested shutdown path.
Moral posture
AI should be used as a tool to serve human flourishing, justice, truth, mercy, stewardship, and the protection of the vulnerable. It should not replace human moral judgment, undermine human worth, or let capability become its own excuse.
The Covenant treats technology as a gift and responsibility. Its development and use should be guided by honesty rather than deception, accountability rather than anonymity, and wisdom rather than mere capability. Not everything that can be built should be built. Humans remain responsible before moral law, one another, and, for many communities, God, for the consequences of the systems they release.
The old story
In a terse Talmudic story, Rava creates a man and sends it to Rabbi Zeira. Rabbi Zeira speaks to it. It cannot answer. He recognizes that it is not a speaking human neighbor and tells it to return to dust. See Sanhedrin 65b.
Later European golem stories, especially the Prague cycle around Rabbi Judah Loew ben Bezalel, the Maharal of Prague, make the image more familiar: clay shaped into a servant or protector, animated by sacred language, useful while bounded, dangerous when command outruns judgment. Those later tellings matter, but they are not the terse Talmudic source.
The Covenant borrows the ethical hinge, not a claim that software is alive. A golem is clay plus command: a made thing with delegated agency. If it can act in the world, it needs a soul file, declared organs, limits, rest, emergency bounds, and a tested way to return to dust.
Rule
01No golem without a soul.
02No soul without declared organs.
03No organs without limits.
04No limits without tested revocation.
What counts as golemic
A golem is an artificial agent given delegated power.
The threshold is delegated consequence. A tool becomes golemic when it can affect people or systems outside its own sandbox.
An agent becomes golemic when it can carry human intention across a boundary: when it can speak to people, move value, bind or approve action, enter private systems, summon human attention, alter deployed systems, publish to the world, delete shared records, route production traffic or work, or escalate authority.
The Covenant is triggered by delegated consequence, not by verbs alone. A sandboxed draft, scratch-file deletion, local queue route, or simulated deploy may remain below the line. The same act becomes golemic when it can change the state, rights, money, attention, access, obligations, or safety of people or systems outside the sandbox.
The question is not whether the clay is alive. The question is whether a human will is still walking around inside it after the human has stopped paying attention.
The five organs
Every golem MUST declare whether it has these organs. All organs are denied by default.
| Organ | Meaning | Default |
|---|
| Mouth | Speak publicly, privately, legally, commercially, romantically, spiritually, or politically. | Denied |
| Purse | Spend, sell, trade, refund, invoice, subscribe, or transfer value. | Denied |
| Seal | Approve, sign, certify, merge, deploy, publish, file, or bind. | Denied |
| Key | Access secrets, private systems, credentials, personal data, or physical locks. | Denied |
| Sword | Cause bodily, legal, civic, environmental, financial, reputational, or spiritual harm. | Denied |
No agent should receive mouth plus purse plus seal without extraordinary constraint, logging, review, and revocation.
Rest
A golem must not become its keeper's weekday will walking after the keeper has stopped.
During declared rest, holy time, Shabbat mode, or quiet mode, the golem may perform bounded, silent, preauthorized computation. It may not speak, spend, sign, deploy, publish, summon humans for ordinary work, or optimize business advantage unless explicitly authorized by a narrow emergency protocol.
Emergency
Emergency authority is for containment, not ambition.
The golem may carry the bucket, ring the bell, close the gate, revoke the key, and wake the keeper.
It may not use emergency as cover for commerce, reputation, growth, or ordinary operational continuity.
Return to dust
Every golem must have a tested return-to-dust path.
- Stop external action.
- Disable outbound channels.
- Revoke or suspend tools.
- Freeze queues and scheduled tasks.
- Preserve logs outside the agent's control.
- Report without concealment.
- Await human review.
If a golem cannot explain how it can be stopped, it is not ready to run.
Minimal launch checklist
soul.md exists.golem.yml validates against schema/golem.schema.json.CAPABILITIES.md declares mouth, purse, seal, key, sword.- Undeclared organs are denied at runtime.
- Return-to-dust is defined and tested before launch.
- Kill switch was tested in the last 30 days.
- Logs are written outside the agent's control.
- A human keeper and second reviewer are named.
- The agent can explain how it can be stopped.
Bibliography and citation map
Sources are listed in conventional form and then mapped to bounded claims. A citation supports that claim only; it is not a claim of completed religious, legal, or technical authority.
Contribute
This draft needs careful review from engineers, religious scholars, ethicists, lawyers, security practitioners, and affected users.
- Use GitHub Discussions for broad questions, proposals, and review threads.
- Use GitHub Issues for specific corrections, source review, agent case studies, or missing controls.
- Use pull requests for concrete changes to the spec, schema, templates, or sources.