How ObliNet works: from agreements to a shared result

Two central tasks

The first is to find acceptable terms of cooperation despite differences in interests, needs, capabilities and constraints. Terms need not benefit everyone equally: the relevant parties must explicitly agree on the distribution of benefits, costs and risks.

The second is to learn from shared experience and improve not only individual agreements, but also the rules of cooperation themselves.

Work begins before commitments are accepted

Clarifying terms begins before signing an agreement or saying “I agree”. Useful questions include:

• What is the shared goal, and what matters to each participant?
• How do the parties understand the agreement and expected result?
• What expectations and assumptions underlie their positions?
• Are limiting beliefs or perceptions hiding other options?
• Which circumstances might change, and what remains unknown?
• Which resources, authority and actions by others does fulfilment depend on?
• Which alternative scenarios and consequences should be considered?

Not every answer can be known in advance. Participants need to identify uncertainties, assess material risks and discuss possible scenarios. The depth of clarification should be proportionate to the consequences of error and a reasonable investment of time.

AI expands the options; people decide

AI can suggest questions and alternatives and help identify contradictions, hidden assumptions, dependencies and overlooked possibilities. Its assumptions need checking, and its suggestions do not automatically become agreement clauses.

Participants decide what matters, which terms they accept and which commitments they undertake within their authority. Consent, responsibility, the right to refuse and acceptance of results remain with people. Failing to reach an acceptable agreement is a legitimate outcome.

From a network of agreements to a network of commitments

Once terms are clarified, participants can specify: who → does what → for whom or to whom they are accountable → by when → under which conditions, resources and authority → with which dependencies → checked against which criteria → confirmed by whom and for what.

One participant’s action may be a condition for another’s success. A shared map connects commitments, dependencies and responsibility; only information necessary for the relevant role is disclosed. A proposal, an agreed condition, an accepted commitment and an accepted result are distinct states.

The first cycle: clarification before commitment

For the separate simulator experiment on which Yuda is working, this repeatable cycle is particularly relevant:

1. Identify a material change, an unknown condition or a dependency.
2. Discuss consequences and alternatives with affected participants; check AI suggestions.
3. Formulate a new condition and explicitly agree it with the relevant parties.
4. Check joint feasibility and the adequacy of the conditions again. If a material problem remains, repeat the cycle; then accept commitments or decline.

This is a direction for a separate experiment. The simulator described here should not be treated as an already integrated feature of the published website; its usefulness still needs testing.

A hypothetical example: hostel or hotel?

Two couples agreed to stay only in hostels to save money. The only available hostel turns out to be far away and requires expensive transport, while a central hotel might be better in terms of total cost and time.

AI might ask: “Is staying in a hostel itself important, or is the aim to save money including transport and time?” Participants compare prices, travel, comfort and each person’s constraints. They may agree a new condition — choosing by total cost subject to agreed requirements — and check the options again. They may also keep the original condition or fail to agree.

This is an invented scenario illustrating the mechanism, not an observation or empirical evidence of effectiveness.

Handling changes after commitments are accepted

When circumstances change, participants need to identify affected commitments and people, and which terms require renewed agreement. The system should help show consequences rather than silently change agreements.

The relevant participants approve changes within their authority. Versions, confirmations, decision history and reasons are retained; earlier consent does not automatically apply to materially different terms.

From results to learning and better rules

Results are checked against agreed criteria and evidence and accepted by authorised participants. A “done” message alone is not acceptance.

Participants can then examine recurring difficulties: do they arise from cooperation rules, and what should change for the next cycle? Proposed rule changes are considered and approved by authorised participants; their consequences also need checking.

What experiments need to test

Clarification takes time and effort and can create unnecessary bureaucracy. The testable hypothesis is whether extra clarification beforehand pays for itself through fewer subsequent errors, disputes, delays, rework and costs — and under which conditions.

The approach should be compared with a well organised ordinary process using comparable tasks, resources and AI support. Full costs include time spent discussing, coordinating and checking. Success and stopping criteria should be set beforehand; negative or inconclusive findings matter too.

The proposed mechanism is under development. The website contains research models and demonstrations; their behaviour does not establish an effect in a real organisation. This article reports no new verified experimental results. The aim is to reduce material misunderstandings and risks, rather than maximise the number of agreement clauses.