Back to the journey

Interactive design argument

When good parts disagree

A small contradiction changed how we think about systems that must work together.

The question

How do good parts become a good whole?

A shared game might bring together a bridge, a wood supply and a space that players can build in. Each part can follow its own rules. The harder question is whether those rules still work together.

Our early design gave a tree of owners a central role in organizing shared meaning. The research asked whether that was enough—and whether a different structure could let independently made systems meet more freely.

This is an illustrated design argument. The small puzzle below demonstrates a logical problem; it is not a recording of the engine.

The challenge

Every pair fits. The whole does not.

Give three values, x, y and z, either 0 or 1. Now ask them to satisfy these three rules. A checkmark in the table means that one rule holds.

Choose the rules to combine

All eight possibilities are shown. Each rule works alone; each pair works together. No row satisfies all three.

0 of 8 possibilities

No way to satisfy all three.

A and B make x equal z. C requires the opposite. Each pair has a solution, but the three together do not.

All eight assignments 0 and 1 are the only possible values.
x · y · zx = yy = zx ≠ zFits selected
rules?
000✓✓—No
001✓—✓No
010———No
011—✓✓No
100—✓✓No
101———No
110✓—✓No
111✓✓—No

Rule holds Rule does not hold

A + Bx, y, z = 0, 0, 0

A + Cx, y, z = 0, 0, 1

B + Cx, y, z = 0, 1, 1

Checking every pair does not establish that the whole can work. The shared rules need to be considered together.

The alternatives

Three ways to connect the parts

The consultation kept three serious approaches in view. The question was how each could express shared rules without hiding important assumptions.

Trees with shared agreements

Keep recursive owners and their local responsibilities. Package rules that cross between them as explicit joint contracts.

Can cross-connections stay clear without pushing all their meaning up to a common ancestor?

An open web of contracts

Let a shared rule connect every participant it concerns. Implementations propose actions; their connections must establish the relevant obligations.

Chosen research reference

Can those boundaries support independent additions and efficient implementations?

Assemble actions from constraints

Describe an action through the conditions and effects it requires. An interpreter must find and carry out a legal transition.

Can this express richer joint behavior without hiding game policy inside a universal solver?

These are competing design approaches. Choosing a reference model does not establish a faster runtime or a general solution to composition. The alternatives remain open to comparison.

What changed

Give shared rules an explicit home.

A rule can belong between several systems. It does not have to move up to their nearest common ancestor.

The revised design makes joint contracts explicit: each shared rule has a meaning, an owner and obligations for its participants. Local trees still help organize bounded responsibilities and implementation.

For a paid bridge, inventory owns balances and construction owns creation. Their joint contract ties the accepted build, the charge and the creation together. The occupancy contract accounts for what can block the gap.

Shared rules connect independently owned systems Construction and inventory both connect to a paid-creation contract. Construction and the crane both connect to an occupancy contract. The shared rules cross between participants rather than being placed above them in one ownership tree. ConstructionInventoryCranePaid creationone accepted build, one chargeOccupancywho can block this space?
Illustration of shared responsibilities. The connecting lines describe obligations, not messages or a running engine.
What this argument establishes

The Boolean puzzle is a complete finite example: all eight assignments are visible. It establishes that pairwise compatibility does not, in general, guarantee joint compatibility.

The bridge and crane are a paper scenario from the composition research. They explain why shared rules and the set of relevant contributors matter. They are not an execution trace or a claim that the proposed mechanism has been implemented.

The design decision adopts owned joint contracts and an open network of obligations as the reference semantic model. Recursive, graph-based and relational implementations still need comparison. There is no proven runtime winner here.