Node

#How It Works

Every organization is a tree of Nodes with a single root, and the root is itself a Node rather than a separate abstract container. Each Node draws its behaviour from one unit type (configured in CA-UNITYP), which in turn fixes its archetype (CORE, SUPPORTING, GENERIC, CONTAINER, or UNSPECIFIED — see Archetypes below). Unit type, archetype, and contract-node status are kept deliberately distinct; collapsing them is a modelling error.

From the moment it exists, a Node carries its own financial surfaces: one Cap Table and one default Wallet, plus an offering wallet for each Offering it owns. One special case shapes topology: signing a JOINT_VENTURE Revenue Split Contract atomically creates a new contract-node — a real Node with its own identity, wallets, and cap table — and that status is one-way.

#How It Connects

A Node sits at the centre of the model: topology, catalog, agreements, value, and ownership all attach to it.

• Organization — the rooted tree of Nodes; the root is a Node.
• Offering — what a Node whose archetype permits it makes available externally.
• Bundle — combines Offerings owned by Nodes.
• Contract — Nodes are the parties a Contract binds.
• Milestone — gates contract behaviour between Nodes.
• Wallet — Nodes hold a default wallet plus per-Offering wallets.
• Ledger Event — financial facts that drive each Node's P&L view.
• Cap Table — ownership of a Node, expressed in basis points.
• CA-UNITYP — defines the unit types a Node can take and the archetype it inherits.
• CA-UNILIF — defines the unit lifecycle basis a Node moves through.

#Statements

The statements below fix each rule precisely.

Identity & classification

• A Node is an organizational unit; it is never a product or offering.
• A Node belongs to an organization and has an identity and a name.
• A Node has a unit type; it inherits its archetype from that unit type.
• A Node archetype can be CORE, SUPPORTING, GENERIC, CONTAINER, or UNSPECIFIED.

Topology

• A Node has a parent reference when it sits below the organization root.
• The organization root is itself a Node at the top of the hierarchy.
• The Node hierarchy is rooted and acyclic.
• A Container Node contains child Nodes and does not own Offerings.
• A Container Node can still participate economically where the role does not require an owned Offering.

Financial surfaces

• A Node has a default wallet and a cap table from creation.
• A Node has offering wallets for the Offerings it owns.

Participation & configuration

• A Node can own Offerings when its archetype permits it.
• A Node can participate in Contracts.
• A Node can carry a lifecycle stage.
• CA-UNITYP configures Node unit types.
• CA-UNILIF configures the lifecycle basis used by Nodes.

#Archetypes

A Node Archetype is the semantic classification a Node inherits from its unit type. It tells you what kind of unit a Node is and, in the current release, whether it carries any behavioural rules beyond the label itself. O2A defines a closed set of five archetypes; a Node inherits exactly one of them through its CA-UNITYP unit type.

Four of the five archetypes are classification-only labels: in the current release they carry no behavioural rules and place no constraints on offering ownership, contract participation, or topology. Only CONTAINER carries rules.

• CORE — a unit central to the organization's value proposition.
• SUPPORTING — a unit that supports core units (operations, enablement, shared functions).
• GENERIC — a unit that does not fit a more specific archetype.
• CONTAINER — a parent business-unit Node that contains child Nodes and owns no Offerings. (The only archetype with behavioural rules — see Container Node below.)
• UNSPECIFIED — the absence of an explicit archetype choice.

Archetypes are distinct from contract-node status: a contract-node can have any archetype.

#Container Node

A Container Node is a parent business-unit Node that contains child Nodes and owns no Offerings. It gives O2A a name for parent business units that group child Nodes while keeping hierarchy, offering ownership, and contract participation distinct.

A Node whose archetype is CONTAINER cannot own an Offering and cannot be the seller in a Purchase contract where seller status depends on owning the sold Offering. It can still participate economically in any role that does not require owning an Offering — buyer, investor, investee, Revenue Split participant, ownership holder — when the relevant Contract rules allow it.

• A Container Node is a Node archetype.
• A Container Node contains child Nodes.
• A Container Node owns no Offerings.
• A Container Node can participate economically where the role does not depend on owning the sold Offering.
• A Container Node can be a buyer, investor, investee, Revenue Split participant, or ownership holder when the applicable Contract rules allow that role.

#Operations

Node operations are how organizational units enter the model, move through their lifecycle, and leave it. Because Nodes carry topology, ownership, and participation, these operations are tightly governed: they answer to unit-type configuration, the rooted-hierarchy rule, the per-unit-type lifecycle basis, and the investment locks that protect equity holders.

Create Node brings a new organizational unit into existence under a unit type from CA-UNITYP, which fixes its archetype, and places it in the operating tree without breaking the rooted, acyclic shape.

• Create Node creates a Node.
• Create Node uses a valid CA-UNITYP unit type.
• Create Node preserves the rooted acyclic hierarchy.

Change Node Lifecycle Stage moves a Node's lifecycle metadata along the stages of the effective CA-UNILIF basis for that Node's unit type.

• Change Node Lifecycle Stage changes the Node lifecycle stage.
• Change Node Lifecycle Stage uses an effective CA-UNILIF basis.

Terminate Node ends a Node, and is blocked while an active Investment contract still exists on it so a Node carrying investor exposure cannot be quietly terminated out from under its investors.

• Terminate Node terminates a Node.
• Terminate Node respects active Investment Contract locks.

#Lifecycle

The Node lifecycle is organization-specific rather than a fixed state set baked into the standard. It is the maturity progression an organization defines for its own kinds of units — configured in CA-UNILIF, attached per unit type, and therefore reaching a Node through the unit type it references. An organization can keep it simple or break it into stages depending on how it sets things up.

Organizations treat a new unit differently from an established one — what it may sell and how its P&L is governed can change as it matures. Letting each organization define its own unit stages, rather than hard-coding a global set, is what makes those stage-sensitive rules possible without forcing every organization into the same shape.

Unit lifecycle stages are organization-specific configuration values authored in CA-UNILIF, which requires CA-UNITYP. A Node does not carry a stage directly; it inherits the lifecycle basis through its unit type. CA-UNILIF is optional to author explicitly — if it is not authored, the effective lifecycle basis collapses to one default stage, so a single-stage default is always available.

The stages matter because downstream configuration reads them: a unit lifecycle stage can constrain CA-PLMGMT financial-governance rules and can constrain CA-GTMACC external-client access rules. The unit/Node lifecycle is kept explicitly separate from the Configuration Artifact governance lifecycle, the contract lifecycle, the milestone lifecycle, and offering status; contract-node status, in particular, is an origin property of a Node and not a unit lifecycle stage.

• Unit lifecycle is configured in CA-UNILIF.
• Unit lifecycle applies to a Node through its unit type.
• Unit lifecycle can use a single-stage default.
• A unit lifecycle stage can constrain CA-PLMGMT rules.
• A unit lifecycle stage can constrain CA-GTMACC rules.
• Unit lifecycle stages are organization-specific configuration values.

#Financial View

Node P&L is the profit-and-loss picture for a single Node over an explicit period. It pulls together the Node's revenue, fixed costs, realized offering cost of goods, allocated shared costs, and resulting net. It is a derived view recomputed from the Node's Ledger Events and configuration policy every time, never edited directly and never stored as its own ledger.

Node P&L is where the classified event stream becomes an answer to "is this Node making money this period?" Because it is a pure function of the events and policy, the same period always yields the same numbers, and every line resolves back to the events behind it. Correcting a number means recording a compensating Ledger Event; the P&L itself is never adjusted.

For the selected period, revenue is gathered from Product Sale events and from inbound Contract Split events routed to this Node. Fixed costs come from the Node's fixed-cost Ledger Events. Realized offering cost of goods comes from offering cost-of-goods events, grouped by the offering whose P&L receives the cost. Allocated shared costs come from the Node's general cost-of-goods pool, spread across offerings by the Node's shared-cost allocation policy. Net is revenue minus fixed costs, realized offering cost of goods, and allocated shared costs.

• A Node P&L view includes revenue, fixed costs, realized offering cost of goods, allocated shared costs, and net.
• Node P&L revenue includes Product Sale revenue.
• Node P&L revenue includes inbound Contract Split revenue.
• Node P&L fixed costs derive from fixed-cost Ledger Events.
• Node P&L realized offering cost of goods derives from offering cost-of-goods Ledger Events.
• Node P&L allocated shared costs derive from shared cost allocation.

For the cross-cutting financial concepts the view sits on, see Source Truth and related pages.

#Configuration

Two Configuration Artifacts govern Node behaviour:

• CA-UNITYP — the unit-type taxonomy that fixes each Node's archetype and hierarchy rules.
• CA-UNILIF — the per-unit-type lifecycle basis.

#Why It Matters

Everything structural in O2A hangs off Nodes. They form the organization's shape (a rooted tree), they carry the financial surfaces where value and ownership live, and they are the parties contracts bind. Get the Node model right and topology, money, and agreements all line up; get it wrong and nothing downstream reads correctly.