Terminology

This book uses the following terms consistently.

Contract Artifact

A published contract source bundle with canonical metadata such as:

• contract_id
• family_id
• version_id
• code hash
• ABI hash
• storage layout hash

The artifact identifies executable code and interface shape.

Contract Instance

An instantiated contract bound to an artifact family.

The contract instance holds:

• persisted storage;
• lifecycle state;
• settlement metadata;
• accepted version bindings.

The contract instance identifies persisted state, not just code.

Accepted Version

An actor-specific artifact selection for a contract instance.

When present, the ledger resolves calls for that actor against the accepted artifact instead of the instance default artifact.

Local Execution

Execution of contract code by the TREA runtime before ledger commit.

Local execution produces an execution result. It does not guarantee that the ledger will accept the resulting effects.

Execution Result

The output produced by the runtime after a successful call.

It includes:

• storage writes and deletes;
• emitted events;
• effects plan;
• cost receipt.

Effects Plan

The ledger-facing accounting portion of the execution result.

It includes operations such as:

• send(...) lowering;
• post(...) plans;
• correction lineage for reversal and reclassification.

Ledger Commit

The ledger-side validation and persistence step after local execution.

The ledger validates:

• lifecycle state;
• resolved artifact family;
• accepted version binding;
• posting routes;
• policy constraints;
• final accounting admissibility.

Accounting Intent

The journal-shaped economic meaning expressed by a contract through post(...) or canonical helper intrinsics.

Accounting intent is explicit. The runtime does not infer loan, fee, or accrual meaning from generic state changes.