015 — Capacity Registry (v1.0)
WST • PRIVATE • AUDITABLE • HUMAN-FIRST
Purpose
The Capacity Registry records and exposes what a member can do, offer, or provide, so the system can:
match capacity to project units
enable blind bidding (intent without bias)
recommend best-fit participants
support fair project awarding
Capacity is potential.
Intent activates it.
The system aligns it.
Core Doctrine
Capacity is declared by humans
Capacity exists independently of any specific project
Capacity may be offered into many projects
Bids are expressions of intent against capacity
Projects do not search blindly — the system recommends
Awarding is a governed act, not automatic
Bias is reduced through blind bid + structured scoring
🧠 Core Model
Capacity → Bid (Intent) → Matching → Recommendation → Award → Execution
What Capacity Is
Capacity represents:
skills
labor
equipment
materials
intellectual property
funding ability
It is not yet a contract.
It becomes active when paired with intent.
Canonical Capacity Record
{
"capacity_id": "CAP-20260417-0001",
"member_id": "WST-M-000123",
"seat_id": "SEAT-OPERATOR-000123-A",
"type": "service",
"category": "infrastructure",
"title": "Field Survey Technician",
"capabilities": [
"site survey",
"data collection",
"mapping"
],
"availability": {
"hours_per_week": 20,
"start_utc": "2026-04-20T00:00:00Z"
},
"preferences": {
"project_types": ["water", "energy"],
"regions": ["US-AR", "remote"]
},
"reputation": {
"score": 0,
"completed_units": 0
},
"status": "ACTIVE",
"created_utc": "2026-04-17T23:00:00Z"
}
Blind Bid Model (Critical)
A bid is intent against a project unit using declared capacity.
Key Idea:
The project does NOT initially see identity
The system evaluates based on:
capability
fit
availability
reputation (optional layer)
Bid (Intent) Structure
{
"bid_id": "BID-20260417-0001",
"unit_id": "UNIT-001",
"project_id": "P-20260416-9NE3A",
"capacity_id": "CAP-20260417-0001",
"proposed_effort": {
"hours": 8
},
"proposed_terms": {
"value_class": "service",
"compensation": "open | fixed | barter"
},
"status": "SUBMITTED",
"created_utc": "2026-04-17T23:10:00Z"
}
Blind Phase
During evaluation:
Project sees:
- capability summary
- match score
- proposed effort
- availability
Project does NOT see:
- member_id
- identity
- personal bias signals
This is huge.
You’ve just removed:
favoritism
local politics
bias
legacy hierarchy
Matching Engine
System evaluates bids against unit requirements.
Inputs:
unit requirements
capacity records
bids (intent)
optional reputation
Matching Factors
Capability Match
+ Availability Fit
+ Capacity Alignment
+ Prior Performance (optional)
+ Charter/Local Preference (optional weighted)
Match Output
{
"unit_id": "UNIT-001",
"recommendations": [
{
"bid_id": "BID-0001",
"match_score": 92,
"fit": "HIGH"
},
{
"bid_id": "BID-0002",
"match_score": 85,
"fit": "MEDIUM"
}
]
}
Reveal Phase
Once project selects:
identity is revealed
association is created
intent is accepted
This transitions:
bid → intent.accepted → execution pipeline
Award Model
Awarding is a governed action.
Who may award:
project OWNER
project LEAD (if allowed)
TRUSTEE_SPONSOR (optional override)
Award event:
project.unit.awarded
Result:
winning bid becomes active contract
others remain:
declined
archived
Flow Summary
Capacity Declared
→ Unit Published
→ Bids Submitted (Blind)
→ System Matches
→ Project Reviews Recommendations
→ Project Awards
→ Intent Accepted
→ Execution Queue
Authority Separation
Layer Responsibility
Member declares capacity
System evaluates & recommends
Project awards
Engine executes
No single layer controls everything.
Fairness Doctrine
No identity during initial evaluation
No automatic awarding
No hidden manipulation of ranking
All scoring logic must be explainable
All awards must be recorded
Optional Enhancements
Reputation Layer (Phase 2)
"reputation": {
"completed_units": 12,
"success_rate": 0.92,
"peer_score": 4.7
}
Used carefully to avoid centralization bias.
Priority Modes
Projects may choose:
open fair match (default)
local-first weighting
trusted-network weighting
manual override
Failure Rules
no bids → unit remains open
no match → system flags gap
no award → no execution
bid withdrawn → removed from pool
Anti-Drift Rules
No direct assignment bypassing bid system (unless explicit override)
No identity exposure during blind phase
No execution without awarded bid
No fake “assignment” UI without real contract
No capacity assumed without registry record
Example (Your System Live)
Jonesboro project:
Unit:
Survey water + power
Flow:
3 members submit bids
→ system scores:
92 / 85 / 78
→ project sees anonymous results
→ selects top bid
→ identity revealed
→ association created
→ intent accepted
→ execution begins
Now:
fair
efficient
scalable
auditable
What You Just Built
This is not just capacity tracking.
This is:
a distributed labor market
a project matching engine
a bias-resistant allocation system
a human-first smart contract layer
Final Principle
Capacity creates possibility.
Intent expresses willingness.
The system finds alignment.
The project chooses.
Execution makes it real.