Coordination State Audit User Guide

1. Purpose

The Coordination State Audit helps a team understand why a multi-actor system is difficult to coordinate, where shared state breaks down, and which IXO or Qi capabilities could improve the system.

Use it when a programme, project, market, funding flow, delivery network, or governance process depends on several actors who each hold partial information, authority, evidence, funds, or commitments. The audit turns those hidden dependencies into an explicit map that can be inspected, discussed, diagnosed, and improved.

The guide has two parts:

A primer on the conceptual basis of the coordination state audit.
A practical workflow for conducting the audit, including how to use AI during the process.

2. Conceptual Primer

2.1 What is coordination state?

Coordination state is the set of facts, permissions, resources, claims, commitments, and decisions that actors rely on when they coordinate.

Examples include:

Who is authorized to act.
What work has been completed.
Which evidence has been accepted.
Which funds are available.
Which rules or conditions apply.
Which actor is waiting for which confirmation.
Whether a result is trusted enough to trigger payment, reporting, certification, or another state change.

In many real systems, coordination state is fragmented. One actor has a spreadsheet, another has a contract, another has field reports, another has payment records, and another has regulatory requirements. Coordination fails when these fragments do not become a shared, timely, verifiable state.

2.2 What the audit is looking for

The audit looks for the difference between:

Local state: What each actor knows, controls, records, funds, or believes privately.
Shared state: What all relevant actors can rely on as a common source of truth.
Actionable state: What the system can safely use to trigger the next step.

The audit is not only a process map. A process map shows activities. A coordination state audit shows the state dependencies underneath those activities: who needs what truth from whom, when they need it, why they do or do not trust it, and what it costs to make the truth usable.

2.3 Core audit objects

The application models the audit through a small set of objects.

Object	Meaning
Actor	A person, organization, beneficiary group, verifier, funder, regulator, oracle, data source, or other participant in the system.
Private information	Information the actor controls that others may need to coordinate.
Financial state	Budgets, funds, disbursement schedules, payment records, commitments, or other resource state the actor controls.
Connection	A directed handoff from one actor to another. This can be a report, approval, payment, verification, data flow, claim, decision, or request.
Bandwidth	How dependable the connection is as a state-transfer channel: high, medium, low, or broken.
Manual oracle	A human-dependent verification, judgment, reconciliation, or reporting step that substitutes for a machine-readable source of truth.
Friction point	A classified problem on a connection.
Red flag	A connection serious enough to diagnose and redesign.
Diagnosis	An explanation of the incentive pattern, feedback loops, and coordination costs behind the friction.
Solution stack	A set of IXO or Qi capabilities that could replace weak coordination with shared, verifiable state.

2.4 The four audit phases

The audit proceeds through four phases.

Phase	Question	Output
System Topography	Who participates, and what state do they hold?	Actor map, private state, financial state, and handoffs.
Friction Topology	Where does coordination break?	Failure classification, weak handoffs, manual work, and red flags.
Incentive Diagnosis	Why does it keep breaking?	Game lens, causal loops, cost notes, and current vs target equilibrium.
Solutions	What state infrastructure could improve it?	Coordination State Canvas and recommended IXO or Qi capability stack.

2.5 Failure patterns

The app classifies friction into four failure types.

Failure type	Meaning	Common symptom
Information Bottleneck	One actor waits on another to confirm a truth.	A single gatekeeper, report, approval, or data owner slows the whole system.
Temporal Misalignment	Resources or feedback arrive too late or too early.	Funding, evidence, verification, or decisions arrive after they are most useful.
Trust Deficit	Actors duplicate checks because assertions are not portable or trusted.	Re-verification, repeated audits, parallel records, or selective disclosure.
Cost Overhead	Manual processes or intermediaries make coordination uneconomic.	Staff time, reconciliation, meetings, document chasing, or high transaction cost.

These categories are practical. They do not need to be perfect on the first pass. Their purpose is to focus the discussion and determine which capability patterns are most relevant.

2.6 Incentive lenses

After red flags are identified, the audit asks why the system remains stuck. The app uses four game-theory lenses.

Lens	Basic pattern	Audit question
Prisoner's Dilemma	Defection is locally tempting even though cooperation is better for all.	Can defection become costly or cooperation automatically rewarded?
Stag Hunt	Cooperation is best, but committing first is risky.	Can shared verifiable state reduce unilateral commitment risk?
Game of Chicken	Both lose if nobody yields, but yielding has local cost.	Can neutral verification remove the status cost of yielding?
Assurance Game	Cooperation is stable once enough actors visibly commit.	Can credible signals show the threshold is being reached?

The point is not to create a formal economic model. The point is to name the logic that keeps actors in the current equilibrium and then identify what kind of shared state, commitment, verification, or incentive would make a better equilibrium practical.

2.7 Capability bridge

The final phase translates diagnosed failures into possible IXO and Qi capabilities.

Capability	Layer	Replaces or improves
Verified Actors & Assets	IXO	Unclear identity, authority, asset control, and actor records.
Shared Operating Spaces	IXO	Fragmented projects, teams, consortia, rooms, claims, decisions, artifacts, agent context, and resources.
Workflow Rules	IXO	Policies, contracts, approval rules, and SOPs that live outside executable systems.
Evidence Claims	IXO	Manual reporting cycles, duplicate evidence checks, and untracked assertions.
Independent Evaluation	IXO	Private verification decisions that other actors cannot inspect or rely on.
Governed AI Agents	Qi	Manual research, evidence triage, document processing, and untracked AI use.
Digital Measurement	IXO	Slow manual measurement, inconsistent reporting, and delayed real-world signals.
Commitment Incentives	IXO	Weak commitments and no practical consequence for blocking or defecting.
Verified Settlement	IXO	Verified work that does not reliably trigger payment or resource release.
Outcome Assets	IXO	Verified outcomes that remain invisible, non-transferable, or hard to value.
Pre-Financing & Capital Pools	IXO	Upfront capital barriers and funding disconnected from verified progress.
Shared Data Rooms	IXO	Data silos across files, chats, partner systems, and evidence stores.
Intent-to-Outcome Workflows	Qi	Loose task management disconnected from claims, approvals, and outcomes.

The result is not a final implementation design. It is a defensible bridge from observed coordination failure to candidate state infrastructure.

3. Roles and Preparation

3.1 Recommended participants

For a serious audit, include people who can describe the real system, not just the formal process.

Recommended roles:

Audit facilitator: Runs the session and keeps the map precise.
System owner: Defines the purpose and boundary of the audit.
Operator or delivery lead: Knows what happens day to day.
Data or evidence owner: Knows where records come from and how reliable they are.
Finance or funding owner: Knows payment, budget, disbursement, and incentive constraints.
Verification or compliance owner: Knows audit, certification, regulatory, or evidence rules.
AI operator: Runs AI analysis, captures assumptions, and keeps outputs under review.

One person can play more than one role, but avoid running the audit with only strategy-level participants. Most coordination failures live in operational detail.

3.2 Inputs to collect before the session

Bring enough context to map the system accurately.

Programme or project description.
Current process map, if one exists.
Reporting templates, claim forms, spreadsheets, or dashboards.
Funding or payment rules.
Verification or compliance requirements.
Known delays, disputes, bottlenecks, duplicated checks, or manual work.
Examples of recent handoffs that worked and failed.
Evidence sources such as field records, registry records, signed reports, sensor data, payment logs, or partner system exports.

Do not paste sensitive personal data or confidential commercial records into the audit unless your governance policy allows it. Use labels and summaries when possible.

3.3 Define the audit boundary

Before mapping, agree on:

The outcome the system is trying to coordinate around.
The start and end points of the audit.
The actors that are in scope.
The decisions, claims, payments, or verifications that matter.
The time period being examined.
Whether the goal is diagnosis only, solution exploration, or implementation planning.

A good audit boundary is specific enough to map in one session. "Health programme coordination" is too broad. "Quarterly vaccination delivery reporting and fund release between field NGO, auditor, ministry, and international funder" is usable.

4. Getting Started in the App

4.1 Main screen

The app has three working areas:

Top bar: Audit name, sync status, example/load/import/export/reset/save controls, and sign-in.
Phase rail: The four audit phases.
Workspace: The current phase view.
Inspector: The editable panel for the selected actor, connection, or audit status.

On smaller screens, the inspector opens as a bottom drawer.

4.2 Starting an audit

You can start in three ways:

Load example: Use the sample NGO vaccination programme to understand the workflow.
Reset: Start an empty audit.
Import JSON: Load an exported audit state file.

Rename the audit in the top bar before starting serious work.

4.3 Saving and loading

The app supports local and signed-in workflows.

If you are not signed in, you can still work locally and export JSON.
If you sign in, you can save audits to a workspace and load saved audits later.
The Save button creates a saved version when server persistence is available.
Export JSON is the safest portable backup, especially before major edits or workshops.

In a local development environment, the app may fall back to browser-local storage when the Cloudflare API is unavailable.

4.4 Authentication

The account drawer supports:

Email code sign-in.
Passkey sign-in and passkey creation when server functions are available.
Workspace creation and workspace list review.

In development, email sign-in may show a development code directly in the UI.

5. Conducting the Audit

Phase 1: System Topography

Goal: Map who participates and what state they hold.

Add each actor.
Select each actor and set its type.
Add information the actor controls.
Add financial state the actor controls.
Connect actors to show directed handoffs.
Label each connection.
Set each connection's bandwidth.
Mark whether the connection depends on manual work.
Use auto-layout when the map gets hard to read.

Actor types:

Service Provider
Funder
Verifier
Beneficiary
Regulator
Oracle / Data Source
Other

Connection examples:

Service report from provider to funder.
Verification request from funder to auditor.
Data access from provider to verifier.
Eligibility confirmation from regulator to provider.
Payment disbursement from funder to provider.
Beneficiary feedback from community to service provider.

Bandwidth	Use when
High trust	The handoff is fast, dependable, and accepted by the receiver.
Medium	The handoff works but needs occasional clarification or follow-up.
Low friction	The handoff is weak, delayed, incomplete, or often disputed.
Broken	The handoff is manual, blocked, unreliable, or not trusted enough to trigger action.

Manual oracle guidance: Mark a connection as manual work when a human must inspect, reconcile, interpret, certify, or re-enter information before the next actor can act.

Phase 2: Friction Topology

Goal: Identify where coordination breaks.

Review each connection from the topology.
Select a connection to open it in the inspector.
Confirm the connection label, bandwidth, and manual work setting.
Choose a failure type.
Add friction notes.
Mark critical red flags.
Use the summary filters to compare all connections, red flags, manual work, and dominant failure pattern.

Weak note: Reporting is slow.

Better note: The funder waits up to 90 days for the provider's quarterly report before approving the next disbursement. Field data exists earlier, but it is not trusted until manually compiled and reviewed.

Phase 3: Incentive Diagnosis

Goal: Explain why red-flagged connections remain stuck.

Select a red-flagged connection.
Choose the game lens that best describes the coordination trap.
Capture the reinforcing loop.
Capture the balancing loop.
Add a coordination cost note.
Repeat for each red flag.
Compare the dominant lens across the system.

Example reinforcing loop: Delayed reporting → low funder trust → more manual verification → longer delays → lower trust.

Example balancing loop: Limited staff capacity → selective reporting → fewer verified claims → delayed disbursement → limited staff capacity.

Phase 4: Solutions

Goal: Translate the diagnosis into a capability bridge.

Review the Coordination State Canvas.
For each red-flagged connection, review suggested capabilities.
Select capabilities that directly address the failure and incentive diagnosis.
Prefer a focused stack over a large list.
Check whether the sequence makes sense.
Export the audit JSON or save a version.

6. Using AI During the Audit

6.1 What AI does in this app

When you select a connection and choose Run analysis, the agent analyzes the selected connection using the current audit state.

The structured AI pipeline produces:

Friction analysis
Incentive diagnosis
Capability recommendation
Evidence anchoring

6.2 When to run AI

Use AI after you have entered enough context for the selected connection.

6.3 Recommended AI-assisted workflow

Human maps the connection.
Human adds initial friction notes.
Human marks likely failure type and red flag status.
AI runs analysis.
Human reviews the AI result.
Human edits the audit state where the result is wrong, incomplete, or too generic.
Human adds evidence gaps and validation questions to the next work plan.
AI is rerun only after meaningful context has changed.

6.4 How to review AI output

Review question	What to check
Is the context correct?	Actor names, connection direction, manual dependency, and failure type.
Is the severity justified?	Does the impact match the evidence and operational consequence?
Are root causes real?	Are they grounded in the audit notes, or did the AI infer too much?
Is the incentive lens useful?	Does it explain why the current behavior is locally rational?
Are recommendations implementable?	Do the capabilities match the failure and the sequence make sense?

6.5 Evidence anchoring

For each red flag, identify:

What source proves the handoff happened.
What source proves the handoff was delayed, disputed, or costly.
Who can independently verify the state update.
What metric could establish a before/after baseline.
What evidence is missing.
What decision should not be automated until evidence improves.

6.6 Safe use of AI

Do not enter sensitive personal, health, financial, or confidential data unless the audit environment is approved for that use.
Prefer summaries, labels, and aggregate facts over raw records.
Treat AI output as a draft analysis.
Require human approval for high-impact decisions.
Keep a record of assumptions and evidence gaps.
Validate recommendations with the affected actors.
Do not automate settlement, certification, eligibility, or penalties until the evidence and governance design are reliable.

7. External AI Prompts

Replace bracketed text with the real audit context.

Boundary prompt: We are conducting a coordination state audit for [system]...
Friction prompt: Analyze this handoff for coordination friction...
Incentive diagnosis prompt: For this red-flagged coordination failure...
Capability bridge prompt: Given this diagnosed coordination failure...
Evidence plan prompt: Turn this audit finding into an evidence plan...

8. Facilitation Patterns

8.1 Short workshop format

Time	Activity
0-10 min	Define boundary, outcome, and participants.
10-30 min	Map actors, private state, financial state, and handoffs.
30-50 min	Classify friction and mark red flags.
50-70 min	Diagnose top 2 or 3 red flags.
70-85 min	Run AI analysis and review recommendations.
85-90 min	Agree evidence gaps, owner, and next action.

8.2 Deep audit format

Step	Output
Discovery interviews	Actor list, state inventory, evidence sources, known failures.
Topography workshop	Complete actor and connection map.
Friction review	Red-flag register and failure classification.
Incentive diagnosis	Game lenses, loops, cost notes, and target equilibrium.
AI-assisted analysis	Structured analysis for each red flag.
Evidence validation	Metrics, sources, confidence, and gaps.
Capability design	Focused IXO/Qi stack and implementation sequence.
Governance review	Decision rights, risk controls, accountability, and human approval points.
Implementation backlog	Work packages, owners, dependencies, and success metrics.

9. Interpreting the Output

9.1 Coordination State Canvas

The Coordination State Canvas is the primary summary artifact.

9.2 Red-flag register

The red-flagged connections are your redesign candidates.

9.3 Capability sequence

Define actors, assets, authorities, and roles.
Define workflow rules and claims.
Anchor evidence and evaluation.
Add automation, AI, or digital measurement.
Connect accepted state to settlement, funding, reporting, or outcome assets.

10. Common Mistakes

Mapping departments instead of actual state holders.
Treating every communication channel as a connection without naming the state that moves.
Marking too many red flags and losing focus.
Describing symptoms without identifying who waits on what truth.
Treating trust problems as attitude problems instead of verification design problems.
Jumping to solution modules before diagnosing incentives.
Accepting AI recommendations without evidence review.
Designing automation before defining human accountability.
Ignoring financial state and payment timing.
Exporting no backup before a major workshop or edit session.

11. Completion Criteria

The boundary and outcome are clear.
Key actors are mapped.
Important private information and financial state are captured.
Major handoffs are directional and labelled.
Weak, broken, and manual connections are reviewed.
Red flags are selected intentionally.
Each red flag has a failure type, notes, and incentive diagnosis.
AI analysis has been reviewed and corrected by humans.
Evidence gaps and validation questions are documented.
A focused solution stack is selected.
The team has agreed what to validate or implement next.

12. Recommended Next Actions After an Audit

After the first audit, choose one of three paths.

Diagnosis only

Export the audit.
Share the Coordination State Canvas.
Use the red-flag register to align stakeholders.

Evidence validation

Assign owners to evidence gaps.
Collect baseline metrics.
Re-run AI analysis after adding measured evidence.
Update severity and confidence.

Implementation planning

Convert selected capabilities into work packages.
Define governance and decision rights.
Define human approval points.
Identify integration and data-source requirements.
Pilot on one red-flagged connection before expanding.

The audit is successful when it changes the coordination conversation from “people are not cooperating” to “this specific state is not shared, trusted, timely, or actionable, and here is the capability path to fix it.”