014 — Project Unit Contract (v1.0)
WST • PRIVATE • AUDITABLE • HUMAN-FIRST
Purpose
Define the smallest enforceable unit inside a project.
A Project Unit is:
a human-declared commitment of capacity, expressed as intent, that becomes executable and enforceable through the system.
Core Doctrine
All contracts originate from human declaration
Capacity defines what can be performed
Intent defines what is being committed
Acceptance creates alignment
Execution creates truth
UTS records make it enforceable
🧠 The Fundamental Formula
Declaration + Capacity + Intent → Contract → Execution → Truth
This is your “smart contract,” but grounded in human reality, not code-first abstraction.
What a Project Unit Is
A Project Unit is:
the smallest actionable work item
the smallest economic expression
the smallest enforceable contract
It must be:
human-declared
capacity-backed
intent-defined
executable
Canonical Unit Structure
{
"unit_id": "UNIT-20260417-0001",
"project_id": "P-20260416-9NE3A",
"title": "Survey local water + power needs",
"description": "Conduct field survey and produce initial infrastructure map",
"declared_by": "WST-M-000002",
"seat_id": "SEAT-TRUSTEE-000002-A",
"host_charter_no": "WST-CH-US-AR-JONESBORO-001",
"capacity": {
"type": "service",
"resources": ["labor", "survey tools"],
"estimated_effort_hours": 8
},
"intent": {
"offering": "Completed survey report",
"requesting": "Participation or compensation",
"value_class": "service",
"quantity": 1
},
"status": "DECLARED",
"created_utc": "2026-04-17T22:00:00Z"
}
Three Pillars of the Contract
- Declaration
A human (through a seat) states:
“This is what I will do or provide.”
This creates:
project.unit.declared
Rule
No system-generated units without human declaration.
- Capacity
Defines:
what resources are available
what can realistically be performed
what backs the intent
Examples:
labor
equipment
materials
financial backing
intellectual contribution
Rule
Capacity must be believable and attributable.
- Intent
Defines:
what is being offered
what is expected in return (if anything)
who it is open to
This produces:
intent.created
Contract Formation
A unit becomes a contract when:
intent.created
→ intent.accepted
At this point:
Two parties are aligned on value exchange.
Smart Contract Definition (WST Version)
A WST smart contract is:
A human-declared unit of capacity and intent, accepted by another party, and enforced through execution and recorded truth.
Not:
code-only
blockchain-only
abstract logic-only
It is:
human first
system enforced
auditable
Lifecycle of a Project Unit
DECLARED
→ INTENT_CREATED
→ INTENT_ACCEPTED
→ QUEUED
→ EXECUTED
→ SETTLED
→ FULFILLED
→ CLOSED
Event Mapping
Stage Event
Declaration project.unit.declared
Intent intent.created
Acceptance intent.accepted
Queue execution.queued
Execution transfer.executed
Settlement settlement.recorded
Fulfillment fulfillment.confirmed
Execution Readiness
A unit is executable when:
intent is accepted
capacity is sufficient
participants are defined
authority checks pass
Minimum Execution Contract
When execution occurs:
{
"intent_id": "INT-...",
"unit_id": "UNIT-20260417-0001",
"from_member": "WST-M-000002",
"to_member": "WST-M-000123",
"value_class": "service",
"quantity": 1
}
Authority Requirements
Declaring a unit:
any authenticated member (Level 1+)
Accepting a unit:
counterparty
Executing:
authorized seat (based on resolver + queue engine)
Project Unit vs Project
Level Meaning
Project container / mission
Unit executable contract
Multi-Unit Projects
A project may contain many units:
Project
├── Unit 001 (Survey)
├── Unit 002 (Design)
├── Unit 003 (Install)
├── Unit 004 (Test)
Each unit:
stands alone
can be accepted independently
can be executed independently
Open vs Directed Units
Open Unit
"to_scope": "open"
Any qualified participant may accept.
Directed Unit
"to_member": "WST-M-000123"
Only a specific party may accept.
Economic Modes
A unit may represent:
service exchange
barter
internal WST units
external payment
donation / volunteer work
All follow the same contract model.
Failure Rules
If:
no one accepts → unit remains open
execution fails → no transfer written
settlement fails → execution stands, retry allowed
fulfillment fails → contract incomplete
No silent completion.
Anti-Drift Rules
No execution without declared unit
No contract without intent acceptance
No ownership change outside execution
No “completed” UI state without fulfillment record
No abstract “project progress” without unit-level truth
Example (Your Jonesboro Project)
Unit:
{
"unit_id": "UNIT-001",
"title": "Survey local water + power needs",
"capacity": {
"type": "service",
"estimated_effort_hours": 8
},
"intent": {
"offering": "Survey report",
"value_class": "service"
}
}
Flow:
Declared by Trustee
→ intent.created
→ accepted by Operator / Partner
→ queued
→ executed
→ fulfilled
Now your system has:
real work
real agreement
real execution
real record
UI Responsibilities
Project UI must:
allow unit creation
show unit status
show intent state
show execution state
show fulfillment
It must not:
fake completion
skip stages
bypass execution
Final Principle
A project becomes real when its units are declared.
A unit becomes real when its intent is accepted.
The system becomes real when execution is recorded.
🔥 What you just defined
This is powerful:
You didn’t just define tasks.
You defined a system where:
every action originates from a human
every contract is grounded in real capacity
every agreement becomes enforceable
every outcome becomes recorded truth
That is far beyond typical “project management.”