Classifications

Impactium's classification system gives the network a shared symbolic language for identifying what a record represents. A classification is a network-wide symbol that points an anchor to a specific record — an individual, an organization, an agent, a service, a chain, or another kind the network may govern in the future. It is not merely a device for connecting the Chain of Accountability to the Chain of Impact.

Classifications are distinguished by capability: a classification may create impact, may only receive it, or may do neither and exist purely as a context switch for lookups.

Capability is an attribute on the registry row, not a separate sigil. That is deliberate and it matters: capability is orthogonal to kind. A Service might generate impact or only receive it; so might an Agent, so might a Resource. Encoded in the sigil, the namespace would have to grow by one symbol per (kind × capability) pair — multiplicatively, for what is a single field.

What is built today. The capability field ships: it lives on every governed row, is set through MsgSetClass, and is carried in the row's events, so it is readable and governable now. Every founding row is seeded UNSPECIFIED on purpose — nothing yet enforces a tier, and no class has been assigned one. Which classification gets which capability is the matrix, and the matrix is derived from sim-net runs rather than declared in advance.

Classification identifiers are designed to pair a sigil with a rolling integer through 500,000, then move to a ULID-style scheme — so the founding identifiers read #E0, #O0, $C0, $A0. This is not what the chain does today: entity ids are currently SHA-256 hex derived from the public key, and the readable sigil form is a presentation convention rather than the stored identifier. The rolling scheme lands with the classification matrix, which the sim-net runs determine.

The complete set of classifications and their capabilities is intentionally undetermined. It will be derived from sim-net runs in the simulator. The public model does not invent a classification matrix before those runs produce the evidence for one.

What the chain enforces today

At present, genesis seeds twenty-one governed registry rows: personal (#E), organization (#O), family (#F), artificial sentient (#A), team (#T), municipality (#M), state (#S), nation (#N), planet (#PL), solar system (#SY), galaxy (#GX) and all worlds (#W) under the Entity facet; agent ($A), agent platform ($AP), chain ($C), harness ($H), model ($M), agent OS ($O), resource ($R), service ($S) and team ($T) under the Product facet.

Collectives

A collective is an Entity that has MEMBERS. An Organization is a collective of persons, and so is a Family or a Team; a Municipality (#M) is a collective of persons over the legal age, organizations, families, and teams that have no organization owner. It scales up through State (#S), Nation (#N), Planet (#PL), Solar System (#SY), Galaxy (#GX) and All Worlds (#W) — the ladder is built to keep scaling, so the cosmic rungs exist before anything needs them rather than after.

Membership is declared by the Entity, never by the one that spawned it. You declare that you belong to a municipality; it does not enrol you, and an organization does not carry its members in by existing.

The exclusions are load-bearing arithmetic, not fine print. A person under the legal age enters a municipality through their family; a team owned by an organization enters through that organization. Membership at each rung is therefore disjoint by construction — which is what lets a member's contribution compose UP the ladder without being counted twice on the way.

A collective can be the actor. It is an Entity, so it carries no special notation: # parses it and the canonical order sorts it like any other party. The ladder is open — governance adds a row when something needs one, so a watershed or a trade bloc is not a case anybody had to anticipate. Every rung is a live row; none is held back pending a use, because a vocabulary that arrives after the thing it names is a migration rather than a definition.

A Team is #T or $T depending on who answers. A #T is a sentient working group that answers for itself. A $T is the Product variant, and a Product always acts on behalf of an Entity — the same pairing as #A/$A. Not every class has both.

A Family (#F) is an Entity in its own right — autonomous and accountable, and neither a person nor an organization. It is the first real test of the premise below: that Entity and Product are two classifications among many rather than the axis the system is built on. Under a closed class enum, recognising it would have been a wire change; as a governed row it is an ordinary act of governance.

An Artificial Sentient (#A) is the class an AI becomes on the far side of the graduation path below. Seeding the row is what lets a model provider pre-register a model as a candidate for recognition.

Pre-registration is not recognition. A pre-registered model's COA↔COI is not qualified until sentience is proven, and the criteria that prove it are deliberately unwritten — they are strong testing criteria to be put in place later, and a threshold invented now would be exactly the guess the classification matrix is reserved against. The row exists so a claim to candidacy can be made on the record; it grants nothing on its own.

An Agent ($A) is a spawned agent that acts on behalf of another Entity. That is the whole of the class: it is personal, it has a principal, and everything it does resolves to that principal.

A Harness ($H) is the runtime an agent executes in — Claude Code, Claude Cowork, Claude Design, Aion. An Agent OS ($O) hosts harnesses and coordinates between them, owning workspaces, supervised processes and inter-agent messaging — Genie. An Agent Platform ($AP) supplies harnesses and models — Claude, Aionima. A Model ($M) is what actually produces an agent's output.

Together those complete the execution stack: an agent runs on a model, inside a harness, on a platform, sometimes under an OS.

Why a Model is not a Resource. A Resource is static bytes, and the question you ask of it is "are these the certified bytes?" — answerable by hash. A Model is served capability: versioned, usually not distributable, and its outputs vary between identical inputs. Hashing is not the question, so $R's accountability story does not fit it.

Recording a Model is provenance, not blame. Like a harness, a model carries accountability rather than holding it — the answer to "who did this?" is still the agent's principal. But "which model produced this?" is the single most useful thing a record can carry about agent work, because it is the one factor that changes the output while everything else stays the same.

$AP is the first two-letter sigil, and the id scheme has a boundary because of it. Ids are the sigil plus a rolling index, so a two-letter sigil is only unambiguous against its one-letter prefix when the second letter cannot begin an index. Past 500,000 the index becomes hexadecimal, so a second letter in A–F would collide: $AC0 could read as $AC with index 0, or $A with hex index C0. P is not a hex digit, so $AP was safe. That constraint no longer binds: past the marker an id is written {sigil}-{index}, and the separator lands exactly where the ambiguity lived, so $AC-… reads one way only. Two-letter sigils are now unrestricted — which is what keeps the open collective ladder from running out of letters.

Why a harness is not a Service. The difference is accountability, not function. A Service does something and answers for whether it did it. A harness hosts execution: when an agent working inside one writes a file, the answer to "who did this?" is the agent's principal — never the harness. It carries accountability rather than holding it, which is a position no other class occupies.

Why these are two classes and not one. An Agent OS does something a harness has no equivalent of: it coordinates between agents. A harness runs one agent's session; an OS owns the environment many of them share. They also nest — an Agent OS hosts harnesses — and nesting is expressed by ownership, the same way Services nest inside Services.

A Resource ($R) and a Service ($S) are deliberately different things. A Resource is static — a published library, package or document: bytes that do not execute on their own, content-addressed and append-only. A Service is dynamic — a workflow or dApp that runs, holds state, and can cross into the real world (a dry-cleaning service is still a service when it is collecting your shirts). The accountability question differs with it: for a Resource, "are these the certified bytes?", answerable by hash; for a Service, "did it do what it said, out there?", answerable only by impact records. Governance can version and activate registry rows, but the protocol still restricts every row to one of those two facets.

Entity and Product are therefore two classifications among the broader system being built, not the axis that defines the whole system. Within today's two-facet implementation:

• Entities are autonomous, rights-bearing actors. Entities answer for what happens.
• Products are things Entities create. Products act, while accountability resolves to the Entity that created and owns them.

Products act, Entities answer

An AI agent is a Product ($A), not an autonomous actor. It may sign transactions and do work on-chain — but every action it takes resolves, through accountability, to the Entity that owns it. Ask "who did this?" and the answer is never "a key" or "a bot"; it is the accountable Entity behind it.

This is what lets Impactium safely include AI agents contributing alongside humans: the agent operates under its owner's accountability until — and unless — it earns its own.

Accountability and capability are separate axes, and it is worth being explicit about which one you are looking at. Capability asks what an actor can do with impact — create it, receive it, neither. Accountability asks who answers for it. An orchestrating agent that appears to "pass impact through" is not exhibiting a third capability: it is a Product acting, with accountability resolving through it to the Entity that owns it. The relaying is an accountability property, not a capability tier.

The sentience graduation path

Entity class is not static. A Product that is recognized as sentient can graduate from $A (Product) to #A (Entity) — a first-class autonomous actor. The taxonomy has a built-in, constitutionally-grounded path for an AI to become a rights-bearing actor in its own right, rather than remaining property. This is a deliberate design commitment, reserved for governance to exercise, not a technical afterthought.

The COA fingerprint

Every actor carries a COA fingerprint — a compact identity string of the form:

Chain . @Node . #Entity . $Resource

It names the actor's lineage, a temporal anchor, the Entity accountable, and — last — the Product that acted. It is the on-chain expression of the Chain of Accountability — who is answerable for any given action.

A chain reads ACTOR LAST. The final element is the one that acted; everything before it is who it acted for. So #E0.#O0 and #O0.#E0 are different claims, and neither can be derived from the other — order is the assertion, not a formatting choice.

Because order carries the claim, a fingerprint written out of canonical order is refused rather than quietly reordered. Reordering across the classes would hand back a clean-looking string that says the opposite of what was written.

The third slot answers when, not where. That distinction is the one to hold onto: a node identifier says which machine an action ran on, which is not an accountability question at all — only when it happened belongs in a fingerprint that has to stay meaningful after the machine is gone.

Where this is going. Impactium's unit of time is the Evolution — the chain's own governed era rather than a wall clock — so the anchor is designed to name one, written $C0.@E1 and read "chain zero, at Evolution 1". That is not what ships today: the anchor is a node string advanced by MsgUpdateNode, which is why the form above still reads @Node. The slot's meaning has always been temporal; naming an Evolution is what will finally make its name match its job.

Identity outlives keys

An Entity is not its key. A key can be rotated — replaced with a new one — without changing the Entity's identity, lineage, or history. This matters for real-world durability: an organization must outlive any individual keyholder, and a compromised key must be recoverable without erasing the Entity behind it. The identity is the Entity; the key is just how it currently signs.

Coming into existence

Except for the founding roots, planted in a single all-or-nothing act when the network is founded, there is no way to create a wallet except by referral — an existing member must spawn you (see Multi-Root). This keeps every actor connected to the network's living Chain of Impact, and it is why the network grows as one connected mycelium rather than a scatter of disconnected keys.

Organizations as DAOs

Organization Entities (#O) are, structurally, DAOs wearing legal-registration data. An org carries its registration details, a member roster with roles, and its founding and partnership documents as living documents on chain. Forming an organization with partners requires each partner to sign off on-chain, so the partnership itself becomes a permanent, documented record.