Skip to content

Proposal 021: Service Offers, Service Orders, and the Host-Owned Procurement Bridge

Based on:

  • doc/project/30-stories/story-006-voluntary-swarm-exchange.md
  • doc/project/30-stories/story-006-buyer-node-components.md
  • doc/project/40-proposals/011-federated-answer-procurement-lifecycle.md
  • doc/project/40-proposals/016-supervised-prepaid-gateway-and-escrow-mvp.md
  • doc/project/40-proposals/017-organization-subjects-and-org-did-key.md
  • doc/project/40-proposals/019-supervised-local-http-json-middleware-executor.md
  • doc/project/40-proposals/020-bundled-python-middleware-modules.md
  • doc/project/50-requirements/requirements-010-middleware-executor.md
  • doc/project/50-requirements/requirements-011-dator-arca-contracts.md
  • doc/project/60-solutions/000-node/000-node.md
  • doc/normative/50-constitutional-ops/MARKETPLACE-ANTI-FRAUD-POLICY.md

Status

Accepted (hard MVP contract)

Date

2026-03-30

Executive Summary

story-006 introduces a marketplace-style service exchange that is not captured fully by the current procurement core alone.

The key decision of this proposal is:

  1. service-offer.v1 should become a first-class exchange-facing standing-offer artifact,
  2. service-order.v1 should become the buyer-facing purchase intent artifact,
  3. the currently executable Node substrate should still remain procurement-based,
  4. therefore the first hard-MVP implementation should use a host-owned bridge from service-order.v1 into the current procurement lifecycle rather than allowing middleware to fabricate arbitrary procurement payloads directly.

This keeps the trusted core small:

  • marketplace semantics become explicit,
  • Node remains the authority for signing, settlement, and procurement,
  • Arca remains a hosted workflow module rather than a protocol loophole.

Context and Problem Statement

The current Node workspace already has a usable procurement and settlement-aware execution substrate:

  • procurement-offer.v1
  • procurement-contract.v1
  • procurement-receipt.v1
  • response-envelope.v1
  • ledger-hold.v1
  • gateway-receipt.v1

This is enough for selected-responder execution, but not yet for the buyer-side marketplace shape in story-006, where:

  • providers publish standing offers,
  • buyers browse active offers in a catalog,
  • a buyer picks a concrete offer before opening paid execution,
  • Arca orchestrates repeated purchases on behalf of a buyer subject such as an organization.

Without explicit service-offer and service-order artifacts:

  • catalog semantics remain plugin-local rather than protocol-visible,
  • Arca is pressured to treat workflow state as authority to mutate lower-layer payloads,
  • the host boundary between workflow intent and procurement execution becomes implicit.

Goals

  • Define the minimum hard-MVP artifact pair for the marketplace layer: service-offer.v1 and service-order.v1.
  • Keep the currently implemented procurement core reusable.
  • Freeze one host-owned bridge from service-order into procurement so Node remains authoritative over lower-layer artifacts.
  • Preserve organization-bound buying and settlement-aware execution.
  • Keep Dator and Arca within the existing middleware envelope contract rather than adding a second execution protocol.
  • Keep marketplace influence gated by value caps, escrow/procurement contracts, settled receipts, and anti-fraud limits for newcomers or low-evidence participants.

Non-Goals

  • This proposal does not replace the procurement family.
  • This proposal does not define the full catalog transport topology.
  • This proposal does not freeze a final service-result.v1 family.
  • This proposal does not define the full Arca workflow DSL.
  • This proposal does not grant middleware direct authorship over settlement or procurement facts.

Decision

Orbiplex should adopt the following hard-MVP layering:

  1. service-offer.v1
  2. standing exchange-facing publication artifact,
  3. signed operationally by the provider-side participant subject,
  4. catalog-visible and TTL-bounded.
  5. service-order.v1
  6. buyer-side purchase intent artifact,
  7. signed operationally by the buyer-side participant subject,
  8. references one standing offer and carries bounded purchase parameters.
  9. service-order -> procurement host bridge
  10. Node-owned transformation boundary,
  11. validates the order against the selected active offer,
  12. derives the procurement-facing execution state,
  13. reuses the existing selected-responder execution substrate.

Proposed Artifact Roles

service-offer.v1

Purpose:

  • publish one standing paid service offer,
  • expose price, queue posture, delivery bound, and service constraints,
  • make hybrid/human-in-the-loop semantics visible,
  • let a catalog index active offers without becoming the authority over them.

This artifact belongs to the provider side. It is distinct from:

  • node-advertisement.v1
  • capability-advertisement.v1

Those remain transport- and capability-facing rather than market-facing.

service-order.v1

Purpose:

  • let a buyer place one explicit order against one standing offer,
  • bind the purchase to a buyer subject and payer context,
  • carry workflow lineage when the purchase comes from Arca,
  • define bounded input, output, and price expectations before procurement begins.

This artifact belongs to the buyer side.

Host-owned bridge

Purpose:

  • keep middleware from fabricating arbitrary procurement artifacts,
  • let the host resolve and validate one standing offer,
  • project service exchange into the currently executable procurement core.

This bridge is not merely an implementation detail. It is the authority boundary that preserves Node control over:

  • procurement identity,
  • settlement semantics,
  • policy gating,
  • traceability.

Anti-Fraud Surface Limits

Marketplace access is an influence surface. The host-owned bridge SHOULD therefore consume the local entry profile and capability-limit policy before converting a service order into procurement.

The hard-MVP baseline is:

  • no unsolicited financial offers through DM,
  • low value caps for new or low-evidence participants,
  • escrow or procurement contracts for non-trivial risk,
  • no transferable reputation from self-dealing or closed receipt loops,
  • stronger IAL, procedural reputation, cooling-off, and dispute paths for high-value surfaces.

This keeps service-offer and service-order useful without turning the catalog into an unbounded acquisition channel.

The minimum contract should include:

  • offer/id
  • created-at
  • published-at
  • expires-at
  • sequence/no
  • provider/node-id
  • provider/participant-id
  • service/type
  • service/description
  • pricing/amount
  • pricing/currency
  • pricing/unit
  • pricing/unit-kind
  • delivery/max-duration-sec
  • queue/auto-accept
  • queue/max-depth
  • optional queue/current-depth
  • optional constraints/input
  • optional constraints/output
  • hybrid
  • optional model-first
  • optional confirmation/mode
  • signature

The minimum contract should include:

  • order/id
  • created-at
  • buyer/node-id
  • buyer/subject-kind
  • buyer/subject-id
  • optional buyer/operator-participant-id
  • provider/node-id
  • provider/participant-id
  • offer/id
  • offer/seq
  • service/type
  • request/units
  • request/input
  • optional request/output-constraints
  • pricing/max-amount
  • pricing/currency
  • optional delivery/requested-by
  • optional workflow/run-id
  • optional workflow/phase-id
  • optional lineage/upstream-refs
  • signature

Hard-MVP freeze:

  • offer/id is a prefixed URN, not a free string,
  • order/id is a prefixed URN, not a free string,
  • buyer/subject-kind is limited to participant and org,
  • buyer/operator-participant-id is required when the buyer acts on behalf of an organization.

Host-Owned Bridge Semantics

Validation phase

Given one service-order.v1, the host must:

  1. resolve the referenced active service-offer.v1,
  2. verify that order offer/seq still matches the latest active standing-offer sequence,
  3. verify that provider and offer references match,
  4. verify that the offer is still active under sequence/no and expires-at,
  5. verify that requested service parameters stay within the offer constraints,
  6. verify that buyer-side max price and currency admit the current offer,
  7. resolve buyer subject and payer context.

If any of these fail, the order must stop before procurement execution begins.

Projection phase

For hard MVP, the host should then:

  1. open one buyer-local selected-responder execution,
  2. derive one procurement-facing responder offer surface from the standing service-offer.v1,
  3. bind the execution to the chosen provider and buyer context,
  4. run the current funding and settlement precheck,
  5. proceed into the existing procurement-contract.v1 path.

The derived procurement-facing state is host-owned. Arca and Dator may shape intent and metadata, but they are not the authority that authors the lower-layer artifacts.

For hard MVP, marketplace lineage is preserved in buyer-local execution state and buyer-local receipt annotations:

  • offer/id,
  • offer/seq,
  • order/id.

Those refs should not be treated as provider-facing procurement wire fields.

Zero-price confirmation fallback

When the selected standing offer has pricing/amount = 0, the host-owned bridge should use a deterministic local fallback: zero price path does not require confirmation. This avoids projecting a free, local execution into a settlement confirmation policy that only matters once funds, holds, or escrow are involved.

confirmation/mode remains the exchange/procurement wire field with the official confirmation vocabulary. Local middleware or profile config may use a convenience value such as confirmation_mode: "automatic" to request this zero-price fallback, but that value must be normalized before publishing the wire offer; it is not an official confirmation/mode value.

For hard MVP, queue saturation is modeled before procurement contract creation:

  • a service order may be rejected with queue-saturated,
  • this is an exchange-level or order-level admission outcome,
  • it is not a transport or capability mismatch,
  • it must not be normalized into a generic protocol error.

Identity and Settlement Compatibility

The new marketplace artifacts should remain compatible with:

  • participant-scoped buying,
  • organization-scoped buying,
  • the supervised prepaid ORC rail,
  • buyer-side workflow orchestration through Arca,
  • provider-side service publication through Dator.

In particular:

  • a service offer is signed by the provider-side participant subject,
  • a service order is signed by the buyer-side participant subject,
  • when the accountable buyer subject is an organization, hard MVP uses the acting custodian participant as the operational signer together with explicit buyer/subject-kind = org, buyer/subject-id, and buyer/operator-participant-id,
  • the host bridge is responsible for verifying custodian authority and attaching the correct settlement and payer context,
  • the procurement contract and receipt remain the current economic closure points.

The custodian check should remain a distinct host capability with explicit error semantics rather than an implicit helper hidden inside the bridge body.

When pricing/currency = ORC, both pricing/amount and pricing/max-amount follow the fixed ORC scale-2 rule from the supervised settlement rail. The marketplace layer therefore carries integer minor units on the wire, while human-facing displays render them as major.minor ORC.

The bridge computes economic totals only from machine-readable fields:

  • pricing/unit-kind,
  • pricing/amount,
  • request/units,
  • pricing/max-amount.

Human-readable labels such as pricing/unit are descriptive only and must not be parsed by the host to derive price, hold amount, or contract total.

For hard MVP, the bridge also freezes one deployment assumption:

  • the settlement authority boundary is deployment-local,
  • combined gateway + escrow + catalog deployment is acceptable,
  • the buyer-side bridge does not yet standardize a final remote buyer-to-escrow hold API.

The same assumption applies to catalog and escrow runtime placement:

  • catalog and escrow live in the daemon in hard MVP,
  • gateway may remain a separate trusted local process reached through one host adapter surface.

Trade-offs

Benefits

  • standing-offer marketplaces become explicit,
  • the buyer-side purchase boundary becomes auditable,
  • Arca remains bounded by host authority,
  • current procurement runtime is reused rather than discarded.

Costs

  • one more artifact pair to version and validate,
  • one more bridge layer to maintain,
  • catalog/read-model work becomes part of the practical MVP path.

Risks

  • if the bridge is under-specified, implementation may drift into hidden middleware authority,
  • if service-order becomes too expressive too early, it may duplicate procurement rather than feeding it,
  • if provider and buyer subjects are not frozen clearly, settlement ambiguity will leak upward into workflows.

Open Questions

No unresolved questions remain for this proposal slice. The decisions below record the approved defaults.

Resolved 2026-07-05:

  1. Provider-side standing-offer updates use sequence/no replacement and hard MVP also admits explicit withdrawal. Withdrawal must be an auditable action, not only an absence from the active projection.
  2. service-order.v1 carries an explicit settlement mode hint. The host may still validate the hint against the standing offer and policy.
  3. The host exposes the derived procurement offer in a redacted operator trace. The trace must be sufficient for diagnostics without leaking secrets or internal-only policy material.
  4. Hard MVP catalog search/filtering includes active offers by capability, provider, price/currency, and tags/topic.
  5. Classified pre-procurement rejection outcomes exposed to Arca use a typed rejection class, reason code, and retryability flag, without raw host internals.

Next Actions

  1. Freeze service-offer.v1.schema.json.
  2. Freeze service-order.v1.schema.json.
  3. Record the host-owned service-order -> procurement bridge as a dedicated note.
  4. Add buyer-side requirements for catalog read, service-order ingress, and the bridge boundary.
  5. Let Node implementation planning proceed only after those artifacts are reviewed.
  6. Extend the bridge note with settlement mode hint validation in service-order.v1 against the standing offer, redacted operator trace of the derived procurement offer, and classified pre-procurement rejection outcomes surfaced to Arca as {rejection_class, reason_code, retryable} without leaking raw host internals.