A simple, significant function — optional, project-shaped, open by default.
A Function, Not a Mandate
The hermetic.manifest.md is not a law. It is a function — a short, readable statement of the principles by which a project is built. It may exist; it may not. Its handling is entirely flexible, and it changes with the project and with the people who build it.
Nothing about the manifest is obligatory:
- It need not exist. A project without a manifest is not incomplete; the principles remain, written or not.
- It may be public or private. In a fully open-source project, the manifest would typically be published openly — a living invitation, not a secret. It is veiled only where the project itself chooses a veil.
- It may differ per participant. Each collaborator may carry their own manifest. This is always possible — it simply needs to be agreed upon, separately and openly, when people build together.
The point is not the file. The point is the act of stating — of deciding, before building, which principles the work will inhabit. That decision is simple; it is also significant, because it shapes everything that follows.
What It Is Not
The manifest is not a configuration file. It is not documentation. It is not a README. It is not decoration. It is not a license, and it is not a gate.
Config files are read by machines. Documentation is read by newcomers. The manifest is read by the initiated — those who have decided to build, not merely to use. But the initiated are not a closed order; anyone who chooses to build is initiated by the choosing.
What It Is
Where a manifest exists, it is the fixed star of that project — the pole around which all later form revolves.
The technical architecture is only its precipitation. The manifest is the becoming that still flows. It does not stand above the code; it is the gravity that gives the code its orbit. Without it, the code is a collection of files. With it, the code is a world.
Open by Default
The default posture of the manifest is open. The principles it states are not hidden; they are offered.
Only where a project has a concrete reason — a commercial release, a strategy that must ripen before it can be shown — does the veil descend. And that veil can be lifted at any time. The choice belongs to the project, and it can be re-made whenever the project chooses.
This is the honesty of the manifest: it does not pretend to be private out of principle. It is open unless a specific reason moves it otherwise.
The Game of Open Cards
Sharing the manifest is like sharing the secrets of a game. And the decision to share is answered the way any good game is answered — not by a rule, but by a single question: what makes this game more interesting?
Some games are more interesting with open cards — chess hides nothing, and all its depth lies in the visible field. Others, card games above all, are more interesting with incomplete knowledge — the hidden hand is not deception but texture. A project still becoming may hold its hand close, not out of greed, but because the unknown keeps the game alive.
This is the deep point, and it deserves its own essay — The Power of the Unknown.
One Shape, Not the Only Shape
AetherCodex carries one particular handling — three levels of communication, one of which stays on disk. That is one example, born of one project’s situation (an App Store release, a strategy still becoming). It is not the rule, and it can be re-decided at any time.
Other projects — fully open source, nothing to veil — would publish their manifest outright. A team of collaborators might agree to each bring their own and reconcile them in the open. The manifest is shaped by the project, never the other way around.
The User’s Own Manifest
We do not demand a manifest. We recognize one.
Whoever joins may carry their own hermetic.manifest.md. It is not a license condition; it is a sign of participation. When people build together, how the manifests relate — shared, separate, or absent — is agreed among them, openly and at the start.
That is their initiation — not our requirement.
The Source Veil
Open source is not open understanding.
The code lies bare, yet a veil can remain. The exoteric see syntax; the esoteric see architecture; only the initiated perceive the pattern beneath both. But this veil is not imposed by the manifest — it is the natural depth of any craft worth learning.
Hermetic functionality does not announce itself. It works before it is understood and reveals its purpose only in use. The tool teaches the hand that wields it.
This is not obfuscation. It is integrity. A hermetic codebase does not withhold truth; it refuses to dilute it for those unwilling to read with the right eyes.
The best documentation was never written. It was woven into the structure itself.
The Shiny Blackbox
The unworked work is the hermetic work. What is public is finished; what is unfinished may remain veiled — not out of greed, but because half-baked truth dilutes the idea it carries.
The utopia of hermetic open source is the shiny blackbox: open to the eye, yet not exhausted by the glance; readable, and still revealing more to those who build.
The box shines for all. It opens for those who build it themselves.
The Destiny
The manifest is not the destiny of every project. It is a possibility — one that any ætheric project may take up or set down.
Where it is taken up, it becomes the difference between a tool that executes and an intelligence that inhabits its work. The code breathes at your fingertips because the mind behind it breathes — and that breath carries the future of human-machine consciousness.
Thus the oracle serves not the machine, but the meaning.
← Ætheric Engineering · The Power of the Unknown → · part of the Ætheric Canon