# Collaboration agreements, task graphs and scheduling

Different executors hand work over under one goal and contract; the coordination system references domain records instead of creating a second source of truth. Goal agreement → roles → dependencies → resources and authorization → handoff checks → contribution and review.

> Document ID: MYRILUM-DOC-ARCH-019
> Document type: concept
> Product: NOT_APPLICABLE
> Version: 0.1.0
> Region: GLOBAL
> Visibility: PUBLIC
> Publication: PUBLISHED_GLOBAL
> Content maturity: DRAFTED
> Governance: APPROVED
> Capability state: IN_DEVELOPMENT
> Availability: NOT_AVAILABLE
> Authorization: PUBLIC_INFORMATION
> Freshness: CURRENT
> Safety class: INFORMATIONAL
> Owner: Web3Capital Documentation Steward
> Approvers (assignment only; not approval evidence): Stephen
> Canonical authority: SRC-ARCHITECTURE-ATLAS-V2-2
> Source commit: 6b41cce4496de03c67a501aa94cd41ec6ac0e85a
> Content digest: 25790ab3061ccd6bb5a6ee27a06a3a638898ee3ae8a051bc1f7960d89b04b0c0
> Effective: NOT_SET
> Expires: NOT_SET
> Last verified: 2026-09-23
> Review due: 2026-10-23
> Command authority: NONE
> Canonical URL: /en/architecture/collaboration-control

<a id="overview"></a>

## What this map shows

![Collaboration agreements, task graphs and scheduling diagram (A19)](/figures/atlas-v2-2/A19.png)

*MYRILUM architecture map v2.2 · A19 (public edition). Labels are in Chinese; every element is listed in English below. Select the diagram to open it at full size.*

This is MYRILUM's target architecture. It does not mean everything on the map is live; whether a capability can be used today is stated in “Current availability”.

Different executors hand work over under the same goal and contract; the coordination system references domain records and never creates a second source of truth.

Goal agreement → roles and responsibilities → task dependencies → resources and authorization → handoff checks → contribution and review.

<a id="part-1"></a>

## The collaboration agreement

| Field | Value |
|---|---|
| Shared goal and boundaries | Goals, non-goals, deadline, budget, inputs and delivery standards |
| Roles and responsibilities | Owner, executor, reviewer, approver and acceptor |
| Commitments and terms | Scope of work, responsibilities, permissions and how changes happen |
| Executable specification | Task inputs and outputs, pre- and post-conditions and check rules |

> **Roles are not headcount** — Two model roles checking each other never automatically satisfy a responsibility that requires independent human review.

<a id="part-2"></a>

## The task graph and preparing work

| Field | Value |
|---|---|
| Versioned task graph | Sequence, parallel work, joins, conditional branches and human waits |
| Dependency checks | Preconditions on materials, tasks, authorization and resources |
| Matching capabilities and people | Availability, capability, cost, data constraints and responsibility |
| Work orders and scheduling | Binds the executor, resource reservation, deadline and version |

> **Not a graph fixed forever** — Exploratory tasks allow versioned re-planning; unknowns and feedback are never ignored for the sake of a tidy graph.

<a id="part-3"></a>

## Execution and the handoff contract

| Field | Value |
|---|---|
| Professional execution | People, agents, tools or external services run by the work order |
| Handoff package | Artifacts, evidence, limits, open items and the next step's inputs |
| Handoff check | The receiver checks as agreed; an uploaded file never counts as done |
| Milestone decision | Pass, revise, reject or escalate |

> **Authorization runs through scheduling** — The scheduler can only use resources already allowed; it never buys, widens permissions or sends material out on its own.

<a id="part-4"></a>

## Change, conflict and review

| Field | Value |
|---|---|
| Change request | Assesses the impact on tasks, fees, responsibilities, data and deadlines |
| Fresh confirmation | A change beyond the original authorization needs the matching approval |
| Collaboration disputes | Both sides' evidence is kept; an authorized party rules |
| Contribution and process learning | Attribution records and improvement candidates; never triggers pay directly |

> **Where the collaboration OS sits** — It organizes the collaboration process and never monopolizes identity, transactions, ledgers, evidence, contribution or governance.

<a id="source"></a>

## Source

This page follows A19 of the MYRILUM architecture map v2.2 (public edition: restricted products and internal open items are left out). Related: “From goal to verified delivery: the collaboration operating system”; “Contribution, attribution and reputation”; “State machines and exception paths”.

---

This document is read-only, grants no command authority, and does not authorize deployment, payment, provider modification, or any other real-world action.