Human-readable rendering of golem.md
The Golem Covenant
A v0.1 draft standard for AI agents with bounded, answerable, revocable power.
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.
An agent becomes golemic when it is given hands: the ability to speak, spend, sign, access, summon, deploy, publish, delete, route, or escalate.
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.
Citation map
Each label names a bounded claim. 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.