4.5 KiB
title, status, version, created, steward
| title | status | version | created | steward |
|---|---|---|---|---|
| Domain Tree Intent | draft | 0.1 | 2026-05-04 | Bernd Worsch |
Domain Tree Intent
domain-tree exists to provide a reusable organizational backbone for everything-is-code ventures: companies, product families, infrastructure estates, knowledge systems, hubs, services, and the agents that help operate them.
Its purpose is not to replace the work of individual hubs. Its purpose is to give those hubs a shared way to understand where things structurally belong, where they are relevant, and how organizational shape changes over time without losing auditability.
Core Image
Think of a domain tree as a Christmas tree.
The tree itself is structural. At the top sits a Git/Gitea/Forgejo organization or comparable source-control organization. Beneath it are domains and subdomains: the durable branches that express ownership, stewardship, and primary placement.
Resources are pinned to branches by their primary domain. A repository, server, service, user, knowledgebase, policy set, dataset, hub, or helper application should have one place where it actually lives.
Secondary bindings are the lights and tinsel. They connect resources to other branches where they are used, relevant, depended on, documented, operated, or visible. These secondary bindings create utility and beauty, but they are not the structural load-bearing shape of the tree.
Intent
We want a domain model that can be shared across multiple structurally similar domain trees. The same blueprint should support different companies, ventures, labs, projects, or families of systems without each hub inventing its own incompatible notion of domains.
We want domain organization to become a service and repository in its own right, not just a local table inside State Hub or any other single application.
We want primary domain placement to answer: where does this resource live?
We want secondary domain bindings to answer: where else is this resource relevant, used, depended on, affected, or discoverable?
We want domain renames, moves, merges, splits, and resource reassignments to be deliberate, auditable, reversible where possible, and friendly to automation.
We want the model to be useful both to humans and coding agents. Agents should be able to ask where a resource belongs, what else it touches, which tree it is part of, and what impact a change may have.
Scope Of The Idea
domain-tree should eventually describe and serve:
- domain trees rooted in source-control organizations
- domain and subdomain identity
- primary resource bindings
- secondary relevance and dependency bindings
- domain aliases and rename history
- domain moves and structural change events
- resource-neutral bindings for repos, users, servers, services, knowledgebases, hubs, policies, datasets, and future resource types
- APIs or data contracts that other hubs can consume
- local-first exports so dependent hubs can continue operating when the service is unavailable
Guiding Principles
A domain tree has structure. Secondary links should enrich that structure without turning it into an ungoverned graph.
A resource should have exactly one primary domain in a given tree. It may have many secondary bindings.
Domains should have stable identities. Human-facing names and slugs may change; identity should not.
The model should be reusable. NetKingdom, Coulomb, Custodian, or future ventures should be able to instantiate the same blueprint with different contents.
The model should respect everything-is-code practice. Domain structure, policies, migrations, and bindings should be representable as reviewable artifacts, not only as mutable database state.
The model should degrade gracefully. Hubs depending on the domain tree should be able to cache or snapshot enough state to keep working safely.
Non-Intent
This repository is not intended to become the place where all operational facts live.
It is not intended to replace specialized hubs for state, infrastructure, identity, finance, documentation, or agent operations.
It is not intended to make secondary bindings structurally authoritative.
It is not intended to define a complete product or implementation architecture in this first document.
First Useful Outcome
The first useful outcome is a clear workplan and vocabulary that lets State Hub migrate from a single primary domain_id on repositories toward a shared model of primary and secondary domain bindings, while keeping existing dashboards and workflows understandable during the transition.