Meet the reference profile¶
The first six chapters introduce notation and three small teaching models. The remaining chapters describe the larger reference profile: one particular asymmetric system with two seats, objects, locations, procedures and ending conditions.
The teaching models are separate specifications. A wallet example does not implement every payment mechanism, and the tutorial priority model’s A and B labels do not automatically identify the reference profile’s SideA and SideB roles. Follow the package and exact input identity with every definition and result.
Two different roles¶
SideA develops and protects locations, deploys eligible objects, and completes objectives through the profile’s permission, progress and completion rules. SideB initiates traversals, interacts with barriers, inspects eligible locations and items, and can claim objectives under its own procedure.
These are different sets of opportunities. Sharing a data structure does not give the seats equal starting resources, legal operations, observations or objectives. The turn chapter explains their schedules; traversal and inspection explains their interaction.
Both roles use explicit resources and object state. A physical card, its current live occurrence, its owner, its controller and the executor of an effect remain separate concepts. A participant may inspect only the information granted by the relevant visibility and procedure contracts.
Build the state before its procedures¶
Start with zones and setup. Identify which objects and metadata exist, how their areas are represented, and who supplies the setup choices. Then read turns and ending, object operations, and the interaction chapters.
A procedure records more than an end result. It can owe payment, an instruction, a child return, checkpoint work or reactions. Abilities and use, availability and lifetime, and composition explain those obligations at progressively wider boundaries.
Read a contract with its suppliers¶
Some operators compute a result directly. Others receive a proposed state, a legality decision, an effect witness or an external schedule. Their guards do not independently implement every supplier. For example, the full payment interface consumes a supplied candidate state, while the wallet tutorial implements its concrete debit itself.
The reference keeps those supplier boundaries visible. Its finite models use explicit fixtures and parameters; a passing configuration does not establish all providers, arbitrary metadata or a complete game implementation.
Neutral labels carry explicit definitions¶
ResourceUnit, ActionPoint, Barrier, Progress and the seat labels have their meanings in this profile. Synthetic item and example identifiers select structured data and equations. Their numbers do not imply unstated rules or a card catalogue.
Use the vocabulary guide for label namespaces and their source contexts. Use the reference index to find a particular contract. Then follow evidence to distinguish a prepared assertion, a finite exploration, an intended failure and a source-correspondence claim.
The goal is an inspectable formal reference that can also inform another design. A new design must choose and check its own roles, constructors, permissions and providers; inheriting the vocabulary does not transfer the evidence.