The Eight-Organ System
Governance as creative infrastructure
The Insight
I started from a conviction: the way you organize creative work is creative work. Most technologists treat governance as overhead — project boards, CI/CD, dependency rules.[1] Conway's Law observes that system structure mirrors organizational structure; this project inverts that insight — the organizational structure was designed as an aesthetic artifact. I wanted to find out what happens when you give those decisions the same care as the art they coordinate. The result surprised me: the governance model became the most interesting artifact in the system.[2]
How It Works
Eight GitHub organizations, each representing a distinct organ with a Greek ontological suffix.[3] Alexander's "pattern language" proposes that environments are shaped by named, interrelating patterns — here, each organ is a named pattern governing a domain of creative practice. The naming is not decorative: Greek ontological terms encode the organ's epistemological function.[4]
| Organ | Domain | What It Proves |
|---|---|---|
| I — Theoria | Theory & epistemology | Intellectual depth, recursive systems |
| II — Poiesis | Generative art | Creative systems design |
| III — Ergon | Commerce & products | Product-market thinking, revenue |
| IV — Taxis | Orchestration | Governance design, architecture |
| V — Logos | Public process | Transparency, building in public |
| VI — Koinonia | Community | Collaborative infrastructure |
| VII — Kerygma | Marketing | POSSE distribution, content strategy |
| VIII — Meta | Umbrella | Cross-system integration |
The Registry
A machine-readable JSON registry (registry-v2.json) serves as the single source of truth for all 81 repositories.[5] Fowler's principle of a "single authoritative data source" applies here at the organizational level — every repo entry carries status, dependencies, documentation tier, and promotion state. Automated scripts validate the registry against the live state of every repo, checking CI/CD, documentation, dependency integrity, and constitutional compliance.[6]
{
"recursive-engine": {
"organ": "I",
"status": "ACTIVE",
"tier": "flagship",
"promotion_status": "GRADUATED",
"implementation_status": "PRODUCTION",
"dependencies": ["organvm-i-theoria/myth-engine"],
"portfolio_relevance": "CRITICAL"
}
} The State Machine
Work moves through a formal promotion pipeline.[7] The State pattern from the Gang of Four formalizes how an object alters its behavior when its internal state changes — here, repositories are the objects, and each promotion level unlocks new capabilities and expectations.
Each transition has documented criteria and automated validation. The state machine prevents premature claims and ensures quality at each stage — a project can't call itself "art" until it produces interesting output.[8]
The Dependency Rule
The most important constraint, and the one that generated the most creative tension: no back-edges. Theory feeds art feeds commerce — I→II→III — and that flow is enforced automatically.[9] Martin's Dependency Rule — that source code dependencies must point only inward — is applied here at the organizational level. This forced clean API boundaries and created genuine stakes: theory must commit to art without knowing if it will become commerce. 31 dependency edges, zero circular dependencies, validated on every change.[10]
┌──────────┐ ┌──────────┐ ┌──────────┐
│ I Theoria│───▶│II Poiesis│───▶│III Ergon │
│ Theory │ │ Art │ │ Commerce │
└──────────┘ └──────────┘ └──────────┘
│ │
▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ IV Taxis │◀───│ V Logos │◀───│VI Koino- │
│Governance│ │ Essays │ │ nia │
└──────────┘ └──────────┘ └──────────┘
│ ▲
▼ │
┌──────────┐ ┌──────────┐ │
│VII Keryg-│───▶│ META │──────────┘
│ ma │ │ Umbrella │
└──────────┘ └──────────┘
No back-edges: theory → art → commerce only.
Meta oversees all. 31 edges, 0 violations. Automation
Five GitHub Actions workflows govern the system autonomously, embodying the principle that governance should be executable rather than advisory.[11] Scott warns against "high modernist" schemes that impose legibility from above without local knowledge — these workflows encode both top-down rules and bottom-up validation.
- validate-dependencies — checks the dependency graph on every registry change
- monthly-organ-audit — full system health check with Markdown report + JSON metrics
- promote-repo — handles state machine transitions with pre/post validation
- publish-process — syncs ORGAN-V content to public channels
- distribute-content — POSSE distribution to Mastodon, Discord, newsletter
on:
push:
paths: ['registry-v2.json']
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: python scripts/validate-deps.py
# Checks: cycle detection, transitive depth,
# back-edge blocking across 31 edges Why This Is Art
The choice of eight organs (not seven, not ten) is a design decision. The Greek naming scheme is an aesthetic decision. The no-back-edges rule creates dramatic tension.[12] Csikszentmihalyi's framework situates creativity at the intersection of domain, field, and individual — this system is simultaneously the domain (the eight-organ architecture), the field (the governance rules that evaluate work), and the individual practice (the daily decisions about what to build). The promotion state machine creates narrative arcs for each project. This isn't an engineer who also makes art, or an artist who codes on the side — the governance model, the registry schema, the dependency graph, these are the work.
Results
The system launched on 2026-02-11 with 9/9 launch criteria met. All 8 organs are operational.[13] Deming's quality management principles — measure, validate, improve — are embedded in the monthly audit cycle. 228 validation checks pass across the Platinum validation suite, covering CI workflow presence, CHANGELOG files, architectural decision records, badge rows, and implementation status fields for every repo. POSSE distribution is live (Mastodon + Discord). Jekyll/GitHub Pages publishes 10 meta-system essays (~40K words) with an Atom RSS feed.
65 repositories carry CI workflows. 130 architectural decision records document key design choices. Every repo has a CHANGELOG and documentation tier assignment (7 flagship, 57 standard, 5 archive, 8 infrastructure).[14]
Tradeoffs & Lessons
- Documentation volume vs. maintenance burden — ~339K words is powerful as proof-of-work, but each README is a liability if the underlying repo changes. The registry-as-source-of-truth pattern helps: stats flow from the registry, not from hand-editing.[15]
- Strict dependency rules vs. convenience — The no-back-edges constraint is the system's best design decision and its most annoying one. It forced clean interfaces but also meant rewriting code that wanted to "just import" from a downstream organ.
- AI-conductor workflow — ~339K words were produced using a human-AI co-creation model: AI generates volume, human directs and refines. This is honest and documented. The risk is perception ("AI wrote your portfolio"). The mitigation is transparency: every essay in ORGAN-V explains the process.[16]
- Naming scheme lock-in — Greek ontological naming (Theoria, Poiesis, Ergon) is distinctive but means renaming requires 40+ file edits. This was worth the tradeoff for identity coherence.
References
- Conway, Melvin E.. How Do Committees Invent?. Datamation, 1968. https://www.melconway.com/Home/Committees_Paper.html
- Schön, Donald A.. The Reflective Practitioner: How Professionals Think in Action. Basic Books, 1983.
- Alexander, Christopher. A Pattern Language: Towns, Buildings, Construction. Oxford University Press, 1977.
- Meadows, Donella H.. Thinking in Systems: A Primer. Chelsea Green Publishing, 2008.
- Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, 2002.
- Humble, Jez and David Farley. Continuous Delivery: Reliable Software Releases through Build, Test, and Deploy Automation. Addison-Wesley, 2010.
- Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994.
- McConnell, Steve. Code Complete: A Practical Handbook of Software Construction. Microsoft Press, 2004.
- Martin, Robert C.. Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall, 2017.
- Ostrom, Elinor. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge University Press, 1990.
- Scott, James C.. Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed. Yale University Press, 1998.
- Csikszentmihalyi, Mihaly. Creativity: Flow and the Psychology of Discovery and Invention. Harper Perennial, 1996.
- Deming, W. Edwards. Out of the Crisis. MIT Press, 1986.
- Nygard, Michael T.. Release It! Design and Deploy Production-Ready Software. Pragmatic Bookshelf, 2018.
- Brooks, Frederick P.. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1975.
- Shneiderman, Ben. Human-Centered AI. Oxford University Press, 2022.