# AggloWorks — Draft Project Agent Interoperability Schedule

**Status: concept-stage discussion template. Not legal advice, an executed
agreement, or a production specification.**

Use this outline with the parties and their legal advisers to scope one live
project, six participants, three use cases, and a 90-day pilot. Do not enter
sensitive material into the public prototype.

## 1. Project and participants

- Project name, type, size, contract form, and jurisdiction:
- Owner / funding party:
- Proposed participants and authorised representatives:
- Agent of record for each party, hosting boundary, and responsible operator:
- Proposed operator arrangement: owner-run / independent third party /
  distributed:

## 2. Three bounded questions

| Use case                      | Question                                      | Authoritative parties | Required input artifacts | Exit criterion          |
| ----------------------------- | --------------------------------------------- | --------------------- | ------------------------ | ----------------------- |
| Version truth                 | Which revision governs this scope?            | To agree              | To agree                 | To agree before signing |
| Design / installability       | What is the measured clearance?               | To agree              | To agree                 | To agree before signing |
| Schedule / delivery predicate | Does delivery precede the required milestone? | To agree              | To agree                 | To agree before signing |

Never ask a single party to be the sole authority about its own performance.
Disagreements must be reported, not averaged or adjudicated.

## 3. Stage dependency graph

Record the events and artifacts required for each question. Agree the graph at
kickoff; no model-inferred changes.

| Event / artifact | Prerequisites | Responsible party | Due date or external dependency | Questions unblocked |
| ---------------- | ------------- | ----------------- | ------------------------------- | ------------------- |
| To agree         | To agree      | To agree          | To agree                        | To agree            |

- ANSWERABLE: authoritative inputs exist and are current.
- PENDING: name the prerequisite, owner, and due date or explicitly unknown
  external date.
- PREMATURE: name the stage at which the question becomes askable, and a
  substitute question for now.
- Graph changes require agreement, versioning, and a recorded reason.

## 4. Disclosure policies

Default: **DENY**, enforced inside the owning party's node.

For each capability, counterparty, purpose, and stage, choose: DENY / PREDICATE
/ PROJECTION / ATTESTED_FACT / ARTIFACT / OPEN.

- Mandatory stage-scoped disclosure set:
- Protected categories: commercial rates, prices, margins, personnel-level data,
  unrelated correspondence, unissued WIP:
- Raw documents stay with their owner. Only vetted, redacted, signed extracts
  may be released.
- Who approves redaction and release:
- Rate limits, aggregation thresholds, purpose binding, and inference-risk
  review:
- Monthly disclosure accounting:
- Revocation rights, reason codes, and challenge process:

## 5. Version authority and reliability

- Authority per artifact scope and revision-precedence rules:
- Hash and provenance requirements for every vetted artifact:
- Derivation inputs, method, and reproducible code version:
- DERIVED, ATTESTED, and ASSERTED must be distinguishable. Exclude bare
  assertions from relied-upon Fact Packs.
- Unresolved authority returns UNRESOLVED, never an old upload passed off as
  current.
- Supersession retires dependent answers and notifies consumers; agree
  notification SLAs.

## 6. Response obligations

- Acceptance, response, prerequisite tracking, and escalation SLAs:
- How refusals and timeouts are recorded and witnessed:
- How queued questions are answered when prerequisites clear:
- Human decision-makers for consequential actions and disputes:

Answering, refusing, and escalating must not be metered. A fee must never affect
whether a refusal is visible.

## 7. Ledger and governance

- Append-only, hash-chained event format:
- Independent witnesses and counter-signature requirements:
- Per-party access scope and retained copies:
- Recorded questions, intent, routing, pinned revisions, policies, answers,
  refusals, timeouts, disagreements, derivations, and human escalations:
- Audit, replay, export, correction, and exit rights:
- Corrections are new entries with reasons, never silent rewrites.

If a vendor operates the routing or ledger service, specify independent
witnesses, inspectable client and derivation code, migration rights, and
operator replacement. Neutrality cannot rest on the operator's promise alone.

## 8. Pilot plan and measurements

- Weeks 1–2: agree the Schedule, policies, graph, authority map, and baseline.
- Weeks 3–10: run the three use cases on approved inputs.
- Weeks 11–13: adversarial tests, measured review, export, and continue-or-exit
  decision.

Measure: RFI count/cycle time; cited-answer time; questions closed without email
or a meeting; stale-revision incidents; chasing hours; coordination rework;
participation cost for small parties; meeting questions closed in the room; time
from prerequisite clearance to answer delivery.

Publish the baseline, success thresholds, measurement method, fee, responsible
operators, and exit criteria **before** signing. No performance outcome is
guaranteed by this draft.

### Deliberate failure tests

1. Refuse a question: is the refusal and its reason visible?
2. Supersede a revision: are affected answers retired and consumers notified?
3. Submit divergent derivations: are both shown and a settling question stated?
4. Alter history: does independent verification detect it?
5. Ask prematurely: does the response name prerequisites instead of guessing?

## 9. Boundaries and legal review

A Fact Pack records evidence, not a legal determination. The system does not
adjudicate, certify, inspect, allocate liability, transfer design
responsibility, predict authority decisions, or monitor individual workers. It
does not replace existing contract notice or dispute requirements.

Agree without-prejudice framing, notice handling, data protection, retention,
deletion, privileged material, controller/processor roles, security incidents,
costs, and liability with project-specific legal advice. Nothing in this
template determines admissibility.

## 10. Approval and exit

- Approved by each party / representative / date:
- Outstanding prerequisites to starting the pilot:
- Written change-control process:
- End-of-pilot export, access revocation, data return/deletion, and operator
  migration:
- Continue / revise / exit decision and date: