DUADP OSSA Feature Roadmap¶
C A PA B I L I T Y P R O P O S A L · T E C H N I C A L R O A D M A P
Future Feature Roadmap Four production-grade capabilities I can build into the DUADP & OSSA stack — each with its design, integration points, new API surface, and delivery effort.
01 Reputation & Outcome Attestation — living, outcome-driven trust 02 Semantic / Intent Discovery — find capabilities by meaning 03 Conformance & Certification — prove a node/export actually works 04 Economic / Metering Layer — pricing, quotas, settlement DUADP — Discovery OSSA — Definition CRDT Federation
W3C DID / Ed25519 NIST-aligned
Targets Date Status @bluefly/duadp · @bluefly/openstandardagents 10 June 2026 Proposed · Draft v1 — Contents
1 Executive Summary overview
2 The Stack Today — and the Four Open Gaps context
3 Feature 01 — Reputation & Outcome Attestation flagship
4 Feature 02 — Semantic / Intent Discovery feature
5 Feature 03 — Conformance & Certification feature
6 Feature 04 — Economic / Metering Layer feature
7 Sequencing & Shared Rails delivery
8 Effort / Risk / Value Matrix delivery
9 Standards Alignment & Glossary reference
1 Executive Summary
The DUADP × OSSA stack already lets you define an agent (OSSA), discover it across a registry- less federation (DUADP), and execute it via MCP/A2A. This roadmap proposes four capabilities that extend it from a working protocol into a self-governing, searchable, verifiable, and monetizable agent network.
# Feature Closes the gap of… Primary repo Effort
01 Reputation & Outcome Trust is static; nothing measures real-world DUADP + Medium
Attestation outcomes OSSA
02 Semantic / Intent Discovery Search is keyword-only; agents must know exact DUADP Medium
terms
03 Conformance & Certification No way to prove a node or export actually works DUADP + Medium
OSSA
04 Economic / Metering Layer No pricing, quotas, or settlement for paid agents DUADP + Large
OSSA
THE THREAD THAT TIES THEM TOGETHER
Feature 01 introduces a signed-receipt pipeline. Feature 04 reuses it for billing; Feature 02 ranks by it;
Feature 03 feeds the same trust system. Build 01 first and it lays the rail the other three ride on. Each,
however, ships and delivers value independently.
DUADP × OSSA · Future Feature Roadmap 2 / 15
Package names, file paths, and endpoints below are proposed, derived from the existing reference implementations described in the two architecture documents. They are illustrative of the integration shape, not a claim about code that already ships.
DUADP × OSSA · Future Feature Roadmap 3 / 15
2 The Stack Today — and the Four Open Gaps
Everything in the stack flows in one direction: define → discover → execute. That pipeline works, but it leaves four capabilities on the table — each of which this roadmap fills.
DEFINE DISCOVER EXECUTE
┌──────────┐ ┌────────────┐ ┌────────────┐
│ OSSA │ ─────► │ DUADP │ ────► │ runtime │
│ manifest │ │ federation │ │ MCP·A2A │
└──────────┘ └────────────┘ └─────┬──────┘
▲ ▲ ▲ │
│ 01 reputation in │ │ 02 semantic │ 01 outcome
│ manifest │ │ match query │ receipts
│ │ │ ▼
│ 03 conformance ───┘ └── 04 price / ┌─────────────────────┐
│ cert feeds quota / meter │ FOUR NEW │
└───── trust tiers ────────────────────── │ CAPABILITIES │
└─────────────────────┘
# Open gap in the stack today What the feature adds
01 Trust is authority-granted at publish time and never A measure → feedback loop: signed outcome receipts → updated by reality. living reputation.
02 Discovery is keyword + facet; you must already know the Intent-based, embedding-ranked matching over the right words. federation.
03 "Anyone can be a node / any export should deploy" — but A test harness + signed certificates that feed trust tiers. it's unverified.
04 Agents cost money, but there is no price, quota, or Pricing in the manifest, metered usage, quotas, optional settlement. settlement.
WHY THESE FOUR (AND IN THIS ORDER)
They map one-to-one onto the four things a maturing protocol needs after it works: trust (01),
findability (02), verifiability (03), and economics (04). All four build on primitives the repos already
contain — DIDs, signatures, the gossip/CRDT layer, the trust-tier system, and existing tables.
DUADP × OSSA · Future Feature Roadmap 4 / 15
Reputation & Outcome Attestation Living, outcome-driven trust — the flagship that all others build on
01 DUADP + OSSA Effort: Medium Risk: Low–Med Max reuse
THE GAP
DUADP trust is static and authority-granted — the tiers (Official → Verified → Community → Unverified) say who vouched for an agent, not whether it actually works, whether it has silently degraded, or whether it was great last month and broken today. Execution outcomes evaporate; nothing feeds them back.
WHAT IT IS
A cross-cutting feedback layer in five parts: (1) the OSSA runtime emits a signed outcome receipt after each run; (2) a DUADP reputation engine aggregates receipts into a 5-dimensional vector; (3) reputation propagates as a CRDT over the existing gossip layer — no central scoreboard; (4) Sybil resistance weights each receipt by the caller's own reputation; (5) live reputation feeds search ranking, the confidence gate, and evidence-based trust-tier movement.
Caller (w/ DID) ──run──► OSSA Agent Runner ──┐
▲ │ on completion
└────── result ─────── ▼
build + SIGN OUTCOME RECEIPT
{ gaid, caller_did, status,
latency, tokens, cost,
correctness, escrow_hash }
│ POST /api/v1/receipts
▼
┌──────────────── DUADP NODE ─────────────────┐
│ verify sig · anti-abuse · persist │
│ reputation-engine.recompute(gaid) │
│ gossip CRDT delta ──► peers │
└───────────────┬──────────────────────────────┘
▼ feeds
search ranking · confidence gate · trust tier · drift alerts
THE 5-DIMENSIONAL REPUTATION VECTOR
Dimension Derived from Answers
Reliability success / total receipts Does it complete the task?
Latency p50 / p95 latency Is it fast enough?
Cost-efficiency token_usage per success What does a good outcome cost?
Dispute rate challenged receipts How often is output contested?
Freshness / drift recency + distribution stability Is it still behaving as before?
DUADP × OSSA · Future Feature Roadmap 5 / 15
Scores are time-decayed (recent behavior dominates), caller-weighted (EigenTrust-style, so fake reporters carry ~0 weight), and confidence-banded (5 receipts → wide band; 50,000 → tight).
HOW IT INTEGRATES
Repo File Role
DUADP reputation-engine.ts NEW Aggregate · decay · score
DUADP receipt-verifier.ts · sybil-guard.ts · drift- Verify · weight · detect anomalies detector.ts NEW
DUADP confidence-gate.ts · trust.ts · federation.ts Consume live reputation; gossip CRDT delta
DUADP reuses attestations · feedback · token_usage Storage already present — no new schema for receipts
OSSA runtime/outcome-receipt.ts NEW + agent- Build + sign + emit receipt on completion runner.ts
NEW API & MANIFEST SURFACE
POST /api/v1/receipts # submit signed outcome receipt GET /api/v1/reputation/:gaid # vector + confidence band GET /api/v1/reputation/:gaid/history # time series + drift flags POST /api/v1/reputation/:gaid/dispute # stake-backed challenge
# OSSA manifest (opt-in) spec: reputation: publish: true endpoint: https://node.acme.ai/api/v1/receipts dispute: { policy: stake, window: 72h }
WHY IT'S THE FLAGSHIP
Three of five storage needs and the entire propagation mechanism already exist — net-new is four focused modules + two endpoints. And it introduces the signed-receipt rail that Features 02 and 04 reuse.
DUADP × OSSA · Future Feature Roadmap 6 / 15
Semantic / Intent Discovery Find capabilities by meaning, not by guessing keywords
02 DUADP (OSSA taxonomy) Effort: Medium Risk: Medium Big DX win
THE GAP
Discovery today is keyword + facet ( GET /search?q=fraud ). A consuming agent must already know the exact term a publisher used. Ask for "stop card-not-present chargebacks" and you miss an agent tagged "fraud-detection." Meanwhile OSSA manifests already carry rich capabilities and taxonomy metadata that goes underused as an ontology.
WHAT IT IS
An intent-based retrieval layer. At publish time each resource's description, capabilities, and taxonomy are embedded into a vector and indexed per node. A new match endpoint takes a natural-language need, embeds it, and returns ranked candidates via hybrid retrieval — vector similarity + keyword/facet filters + taxonomy expansion — then fans out across the federation and merges by score. When Feature 01 is present, results are re-ranked by relevance × track record.
Agent: "detect fraud in card-not-present transactions"
│ POST /api/v1/match
▼
embed(intent) ──► local ANN index (vector + facets + taxonomy)
│ │ local hits
▼ federatedFetch() ▼
fan out to healthy peers ──► merge by score ──► dedup by GAID
│
▼ optional re-rank: similarity × reputation (Feature 01)
▼
ranked DuadpNode contracts (best capability for the need)
HOW IT INTEGRATES
Repo File Role
DUADP embedding-index.ts NEW Vector index (sqlite-vec / HNSW); pluggable embedder
DUADP semantic-search.ts NEW Hybrid retrieval + taxonomy expansion + re-rank
DUADP publishResourceWithChecks() Embed-on-publish hook (stage after persistence)
DUADP federation.ts · resolver-mcp Fan out match queries; expose duadp_match MCP tool
DUADP db.ts + embeddings table (vector blob · model id · dim)
OSSA manifest taxonomy / capabilities Serve as the controlled vocabulary / ontology
DUADP × OSSA · Future Feature Roadmap 7 / 15
NEW API SURFACE
POST /api/v1/match { "intent": "detect fraud in card-not-present payments", "constraints": { "max_latency_ms": 2000, "trust_min": "verified" }, "federated": true } → ranked: [ { gaid, score, similarity, reputation?, _source_node } ]
GET /api/v1/search?q=...&semantic=true # hybrid mode on existing search # MCP: duadp_match(intent, constraints) # added to resolver-mcp tools
DESIGN NOTES FOR THE TECHNICAL REVIEWER
Embedder is pluggable (local model or hosted) and the embeddings row stores model_id + dim so vectors stay comparable across re-indexing. Cross-node consistency is handled by exchanging the query text on fan-out (each node embeds with its own model) or a shared embedding profile advertised in /.well-known — chosen per deployment.
DUADP × OSSA · Future Feature Roadmap 8 / 15
Conformance & Certification Prove a node speaks DUADP — and that an OSSA export actually deploys
03 DUADP + OSSA Effort: Medium Risk: Medium Feeds trust tiers
THE GAP
The whole premise is "DUADP is the API — any vendor can implement it" and "one OSSA manifest exports to 23 platforms." But nothing verifies that a given node actually conforms to the spec, or that an export actually builds and runs. Trust tiers are asserted, never tested.
WHAT IT IS
Two test harnesses plus a certificate format. (a) Node conformance: a runnable suite probes any node against the normative spec — endpoint presence, schema compliance, the 6-stage gate behavior, well-known documents, correct error codes — and emits a scored report. (b) Export verification: takes an OSSA export (docker / k8s / langchain), builds it in a sandbox and runs smoke tests (does it start, respond, and honor the manifest). Passing runs yield a signed conformance certificate (DID + Ed25519) that feeds the trust tier and expires, forcing periodic re-certification.
spec/ (normative) OSSA export package
│ │
▼ probe ▼ sandbox build + smoke test
┌──────────────┐ ┌──────────────────┐
│ node suite │ │ export verifier │
│ endpoints·gate│ │ build·start·call │
│ ·schemas·errs │ │ ·validate manifest│
└──────┬────────┘ └─────────┬────────┘
└──────────► scored report ◄──────┘
│ sign (certifier DID)
▼
CONFORMANCE CERTIFICATE
{ subject, spec_version, result, expires, x-sig }
│ submitted / published
▼
trust.ts: pass → eligible to promote tier
expired/fail → demote · /.well-known badge
DUADP × OSSA · Future Feature Roadmap 9 / 15
HOW IT INTEGRATES
Repo File Role
DUADP conformance/ suite NEW Spec-driven probes against any node URL
DUADP cert-verifier.ts NEW Verify + ingest certs; wire into trust.ts
DUADP /.well-known/duadp-conformance.json Machine-verifiable conformance badge
DUADP reuses signature-verifier.ts · audit_log Cert signing/verification + audit trail
OSSA cli: ossa certify NEW Build export in sandbox + run smoke tests
OSSA reuses ValidationService · adapters · runtime Validation + the deploy targets being certified
NEW API & CLI SURFACE
GET /.well-known/duadp-conformance.json # node's own badge POST /api/v1/certificates # submit a signed cert GET /api/v1/certificates/:gaid # certs held for a subject
duadp conformance https://node.acme.ai # probe a remote node → report ossa certify ./agent.ossa.yaml --platform docker # build+run+sign
PAIRS NATURALLY WITH FEATURE 01
Certification answers "can it work" (verified once); reputation answers "does it work" (measured continuously). Together they make both ends of trust — capability and behavior — evidence-based.
DUADP × OSSA · Future Feature Roadmap 10 / 15
Economic / Metering Layer Pricing, quotas, and settlement — turn discovery into a marketplace
04 DUADP + OSSA Effort: Large Risk: Med–High Reuses receipt rail
THE GAP
A token_usage table exists, but the network has no economic primitives: an agent cannot advertise a price, enforce a quota, meter consumption, or settle payment. That blocks every commercial use case — paid agents, rate plans, cost-aware routing.
WHAT IT IS
An economics layer built on the Feature-01 receipt rail. Pricing is declared in the manifest. A metered usage receipt is just an outcome receipt with billable units. Entitlements/quotas are enforced pre-execution at the transport layer (capability tokens per caller DID). Settlement is pluggable — prepaid credit ledger, invoice aggregation, or optional micropayment rail — with the protocol defining only the receipt + settlement reference, never a specific currency. Cost becomes a first-class discovery filter (ties into Feature 02 ranking and the Feature 01 cost-efficiency dimension).
discover ──► GET /pricing/:gaid (per-call | per-token | subscription)
│
▼ pre-execution
entitlement check (caller DID quota / credit) ── fail ─► 402 Payment Req.
│ ok
▼ execute (runtime)
metered USAGE RECEIPT { units, cost, caller_did, x-sig } ◄─ reuses 01 rail
│
▼
metering ledger ──► settlement (credit ledger | invoice | micropayment)
│
▼ audit (NIST-aligned billing log, reuses audit_log + token_usage)
HOW IT INTEGRATES
Repo File Role
DUADP metering.ts · entitlement.ts NEW Ledger + quota; pre-exec capability tokens
DUADP reuses receipt pipeline (Feature 01) Usage receipt = outcome receipt + units
DUADP reuses token_usage · audit_log Consumption source + billing audit
OSSA manifest spec.pricing NEW Declare price model + units
OSSA runtime + adapters Emit usage per call; inject metering middleware in exports
DUADP × OSSA · Future Feature Roadmap 11 / 15
NEW API & MANIFEST SURFACE
GET /api/v1/pricing/:gaid # advertised price model POST /api/v1/usage # metered usage receipt (signed) GET /api/v1/usage/:caller # consumption + running balance POST /api/v1/entitlements # grant / check a caller quota
# OSSA manifest spec: pricing: model: per_call # per_call | per_token | subscription amount: 0.01 currency: USD settlement: { rail: credit-ledger } # credit-ledger | invoice | micropay
WHY IT'S LAST (AND LARGEST)
It is the only feature with financial-correctness and (depending on rail) regulatory considerations, so it carries the most risk. Crucially it reuses the receipt rail from Feature 01 — so most of its plumbing is already paid for once 01 ships.
DUADP × OSSA · Future Feature Roadmap 12 / 15
7 Sequencing & Shared Rails
The four features share a small set of primitives. Building them in dependency order means each later feature inherits plumbing rather than rebuilding it.
┌──────────────────────────────────────────────┐
│ SHARED RAILS (mostly already in the repos) │
│ W3C DID · Ed25519 sigs · trust-tier system · │
│ gossip + CRDT federation · audit log │
└───────────────────────┬──────────────────────┘
│
┌─────────────────┴──────────────────┐
▼ ▼
┌────────────────────┐ ┌────────────────────┐
│ 01 REPUTATION │ │ 03 CONFORMANCE │
│ (signed receipt │ │ (signed certs feed │
│ rail) │ │ trust tiers) │
└─────────┬──────────┘ └─────────┬──────────┘
│ rail reused │ trust feeds
┌───────┴────────┐ │
▼ ▼ ▼
┌────────────┐ ┌────────────────┐ all rank/gate logic
│ 02 SEMANTIC │ │ 04 METERING │ consumes the same
│ (ranks by │ │ (bills on the │ trust + reputation
│ reputation)│ │ receipt rail) │ signals
└────────────┘ └────────────────┘
Suggested order: 01 → ( 02 ‖ 03 ) → 04
Feature Hard dependency Benefits from Can ship alone?
01 Reputation none — Yes
02 Semantic none 01 (rank by track record) Yes
03 Conformance none feeds 01's trust signal Yes
04 Metering 01 receipt rail (strongly) 02 (cost-aware routing) Best after 01
DUADP × OSSA · Future Feature Roadmap 13 / 15
8 Effort / Risk / Value Matrix
A single view for prioritization. "Reuse" indicates how much rides on primitives already in the repos — higher reuse means lower delivery risk.
Feature Effort Risk Reuse Net-new core Client value
01 Reputation Med Low– High — attestations, 4 modules + 2 Self-correcting trust; Med feedback, token_usage, endpoints safe registry-less gossip/CRDT network
02 Semantic Med Med Med — federation fan-out, vector index + Agents find the right OSSA taxonomy match path capability by intent
03 Med Med Med — signatures, trust tiers, test suites + cert "Anyone can Conformance adapters, runtime format implement" becomes trustworthy
04 Metering Large Med– Med — receipt rail (01), ledger + Unlocks paid / High token_usage, audit entitlements + commercial agents settlement
01 02·03 04 0
RECOMMENDED FIRST PARALLELIZABLE, LAST — BIGGEST CENTRAL — HIGHEST REUSE INDEPENDENT SCOPE, RIDES 01 COORDINATORS INTRODUCED
RECOMMENDED STARTING POINT
Begin with Feature 01. It has the highest reuse, the lowest risk, immediate standalone value, and it builds the signed-receipt rail that makes Features 02 and 04 substantially cheaper. Features 02 and 03 can then proceed in parallel.
DUADP × OSSA · Future Feature Roadmap 14 / 15
9 Standards Alignment & Glossary
9.1 Standards alignment (across all four)
Requirement Delivered by
Identity & authentication (NIST IA-3) All receipts/certs signed by W3C DID, verified via DID resolution (01·03·04)
Integrity / anti-tamper (NIST SI-7) Escrow-hash binding, Ed25519 signatures, replay protection (01·04)
Authorization, least-privilege (AC-3/AC-6) Pre-execution entitlement + Cedar gate, deterministic before LLM (04)
Audit & accountability (NIST AU) Every score, cert, and charge traces to signed source events (all)
Continuous monitoring (NIST CA-7) Drift detection + periodic re-certification (01·03)
Decentralization Reputation/certs as CRDT over gossip — no central authority (all)
9.2 Glossary
Term Meaning
Outcome / usage receipt Signed record of one execution (status, latency, cost, caller DID); billable in 04
Reputation vector Per-GAID scores across reliability, latency, cost, dispute, freshness
Caller weighting EigenTrust-style scaling of a receipt by the reporter's own reputation
Hybrid retrieval Vector similarity + keyword/facet filters + taxonomy expansion
Conformance certificate Signed attestation that a node/export passed the spec/smoke tests
Entitlement Pre-execution capability token granting a caller a quota / credit
CRDT Conflict-free replicated data type — mergeable across peers, no coordinator
GAID Global Agent ID — a W3C DID giving each agent cryptographic identity
Roadmap generated 10 June 2026 · Targets @bluefly/duadp and @bluefly/openstandardagents · Status: Proposed (Draft v1). All four features build on primitives present in the existing reference implementations; no central registry, scoreboard, or coordinator is introduced. Package names, paths, and endpoints are proposed and illustrative.
DUADP × OSSA · Future Feature Roadmap 15 / 15