005 — Project → Execution Bridge (v1.0)
WST • PRIVATE • AUDITABLE • HUMAN-FIRST
Purpose
Connect project artifacts to the execution pipeline so that:
a project can produce intents
intents can be accepted and aligned
alignment can trigger transfer.executed
execution can drive settlement + fulfillment
Projects describe work.
The bridge converts description into actionable, auditable movement.
Core Doctrine
A project is not economic activity until it emits a valid intent that can be executed.
Bridge Overview
Project (UI)
→ Project Declaration
→ Intent (UTS)
→ Alignment / Acceptance
→ Execution Queue
→ transfer.executed
→ settlement.recorded
→ fulfillment
- Project as a Source of Intent
Every project must be able to generate one or more execution-ready intents.
Minimum requirement
A project must define at least one Execution Unit:
{
"project_id": "P-...",
"unit_id": "UNIT-001",
"title": "Install 1 water pump",
"value_class": "service",
"quantity": 1,
"requires": ["labor", "equipment"],
"offers": ["completed installation"]
}
- Project → Intent Mapping
When a unit is declared ready:
Emit:
intent.created
Example payload:
{
"intent_id": "INT-...",
"project_id": "P-...",
"unit_id": "UNIT-001",
"from_member": "WST-M-000002",
"to_scope": "open | specific_member",
"value_class": "service",
"quantity": 1,
"description": "Install water pump"
}
- Intent Acceptance
When another party agrees:
intent.accepted
This creates a matched agreement.
- Execution Queue
Accepted intents enter a queue:
/portal/_data/execution/queue.ndjson
Each item:
{
"intent_id": "INT-...",
"status": "READY",
"validated": true,
"ready_for_execution": true
}
Execution Trigger
Execution occurs when:
intent is accepted
required inputs are satisfied
authority check passes
- Execution Event
Bridge triggers:
transfer.executed
Example:
{
"cid": "UTS-...",
"event": "transfer.executed",
"refs": {
"intent_id": "INT-...",
"project_id": "P-..."
},
"meta": {
"from_member": "WST-M-000002",
"to_member": "WST-M-00000X",
"value_class": "service",
"quantity": 1
}
}
- Settlement Hook
If financial or external payment exists:
attach payment rail
wait for verification
Then:
settlement.recorded
- Fulfillment Recording
Once work is done:
{
"event": "fulfillment.confirmed",
"refs": {
"project_id": "P-...",
"intent_id": "INT-..."
},
"meta": {
"status": "completed",
"proof": "optional"
}
}
- UI Integration Rules
Projects page must:
show:
units
intent status
execution status
allow:
“Declare Unit”
“Create Intent”
“View Execution”
- City Page Integration
City page should show:
From project layer:
active units
active intents
From execution layer:
completed work
active economic activity
- Authority Requirements
Creating intent:
Member or Operator
Accepting intent:
Counterparty
Executing:
authorized seat (Trustee or valid authority)
Settlement:
system or verified actor
- Failure Conditions
If intent fails:
no execution
project remains active
If execution fails:
no transfer event
intent remains unresolved
If settlement fails:
execution stands
settlement retries
- Anti-Drift Rules
No project bypassing intent
No execution without intent.accepted
No settlement without execution
No direct ownership edits
No UI-only “completion”
- Minimal Working Example
Your current setup:
Project:
Jonesboro Water + Power Pilot
Add:
Unit
{
"unit_id": "UNIT-001",
"title": "Survey local water + power needs",
"value_class": "service",
"quantity": 1
}
Create intent
→ intent.created
Accept
→ intent.accepted
Execute
→ transfer.executed
Now your system is alive economically
- System Files Involved
Projects:
/portal/_data/projects/private/{member}/
Execution Queue:
/portal/_data/execution/queue.ndjson
UTS:
/portal/_data/uts/events.ndjson
- Final Principle
A project becomes real when it produces an intent that can be executed and recorded as truth.
🔥 What you just unlocked
Now:
Projects are not dead records
They become economic engines
Cities become active nodes
Treasury can connect later cleanly