The ObliNet cooperation protocol

From rules to infrastructure

The protocol defines shared rules. Accepted commitments and dependencies form a network. Compatible tools, durable records and delivery of changes to affected participants should gradually form the ObliNet infrastructure. Publishing rules or an AI instruction is insufficient: common formats, versions, participant identity, access rights and compatibility checks are needed.

Who does what

Participants

Clarify goals, interests, constraints and resources; agree conditions, accept commitments within their authority, confirm outcomes and initiate revisions.

AI

Interprets information, proposes commitments and links, identifies possible contradictions, models options and explains consequences. Its assumptions remain distinct from confirmed facts.

Information system

Stores records and versions, checks formal constraints and access, tracks resources, preserves history and delivers notifications. Automated actions stay within authority granted in advance.

What a participant confirms

Acknowledged

Information received; no commitment accepted yet.

Agreed

Agreement with the specified part of a decision.

Commitment accepted

Responsibility for a specific outcome under stated conditions.

Action authorised

Permission within the participant’s authority.

Outcome accepted

Confirmation, supported by evidence, that agreed criteria have been met.

Each confirmation records the participant, content, scope of authority, time and version of conditions. One “agree” does not imply responsibility for an entire project. Material changes require new confirmations from affected parties; earlier confirmations remain in the history.

A minimum commitment record

Who → to whom → outcome → deadline → conditions → resources → dependencies → who accepts the outcome and by which criteria. Also record the basis, authority, version, confirmations, evidence and revision or dispute procedure. A resource promised more than once requires a joint feasibility check.

An executor’s responsibility is considered alongside commitments to supply resources, decisions and access. Managers, support services and the system operator also have verifiable commitments. A group’s commitment relies on its representative’s authority and supporting internal commitments; only information needed by other parties is disclosed.

How the protocol works

1. Clarify each party’s goals, interests, capabilities and constraints.
2. Prepare a proposal and check the joint feasibility of commitments and dependencies.
3. Obtain required confirmations from authorised participants and record the active version.
4. Support execution; when conditions change, show consequences and agree a new version.
5. Provide evidence, check criteria and accept the outcome or open a dispute.
6. Review deviations and propose testable improvements to cooperation rules.

Proposal → conditions checked → confirmations → active version → execution → outcome verification → acceptance. Refusal, dispute and revision are possible. An AI proposal, an instruction and an accepted commitment have distinct statuses; “done” does not replace acceptance.

Illustrative example: the venue becomes unavailable

A team is preparing a concert. The venue service commits to a hall and electricity; the performer commits to preparing sound under these conditions; the organiser confirms readiness against agreed criteria. The hall becomes unavailable. AI may suggest a courtyard, but this is not yet an agreement. The system shows that sound depends on electricity and posters on the address. The service confirms the new venue and power, the performer a feasible deadline, and the organiser authorises the change within their authority. The new version takes effect after required confirmations. Readiness is checked against evidence; if no acceptable option exists, refusal or revision is recorded rather than invented consent.

When interests differ

AI helps compare options for allocating work, time, resources, benefits and risks: what each party gains and gives up. Participants determine acceptability. No agreement is a valid outcome; the protocol cannot guarantee aligned interests. Potential includes knowledge, learning, mutual help and new combinations of capabilities, as well as reserves and recovery, rather than maximum utilisation of people.

What the research will test

First modelling, then a limited pilot in a real organisation. Compare the protocol with a well configured ordinary workflow using the same tasks, data, resources and comparable AI support. Assess the contribution of meaningful confirmations and connected commitments: accepted outcomes, violations, recovery time after changes, errors and disputes, participant time and total costs. Benefits must justify additional work. Set success thresholds, stopping rules and evaluation procedures before trials; record negative and inconclusive results too.