Architecture

The Oferon platform

Intent-to-outcome commerce across vertical storefronts. One shared spine — intent routing, commercial rails, observability, and trust — supports each surface. Vertical diversity via VEC and config, not duplicated engines.

Intent to outcome evidence

Intent → Offers → Connected Plan → Atomic Sessions → Oferon Core (canonical) → Outcome Evidence

Oferon coordinates connected needs and owns the canonical inventory, booking and ledger. Stayix.net is Oferon's accommodation storefront on the same backend — not a separate platform. Mixed vertical plans compose from atomic sessions — not a forced unified checkout across unrelated engines.

  1. Intent

    Structured demand captured on the Intent Board — clarity before routing.

  2. Offers

    Universal marketplace components surface explainable offers matched to intent.

  3. Connected Plan

    Multi-vertical needs compose into atomic sessions — not one-size-fits-all checkout.

  4. Atomic sessions

    Each session routes to the correct transaction engine posture per vertical.

  5. Provider / vertical ownership

    Oferon canonical spine owns inventory, availability, booking, ledger and proof; verticals publish through it.

  6. Outcome evidence

    Proof events and policy snapshots back trust — no decorative verification claims.

Platform architecture layers

  • Intent Board

    Structured demand, clarity rails, and governed routing posture.

    Explore
  • Universal Marketplace Components

    Offer cards, filters, ranking explanations, and action badges — honest demo shells.

    Explore
  • Connected Plans

    Weekend Stay and future plans orchestrate atomic sessions across verticals.

    Explore
  • Vertical Storefronts

    First-six vertical rollout under /verticals — readiness shells, not live liquidity.

    Explore
  • Provider Studio

    Add once. Publish across Oferon and the relevant vertical storefront.

    Explore
  • Trust / Proof / Readiness

    Proof spine, fair routing, sponsored disclosure, and launch gates.

    Explore
  • Accommodation storefront

    Stayix is the Oferon accommodation storefront on the Oferon canonical spine; PMS/channel managers connect only as adapters.

    Explore

Technical stack

Runtime layers

Frontend surfaces are BFF-only. Runtime modules activate behind explicit gates.

L1

Frontend surfaces

Next.js public pages and BFF routes. No direct SDK or provider calls from the browser.

Live
L2

BFF / commerce-core-api

Tenant-scoped API boundary. Hub, intent board, and internal smoke gates behind explicit flags.

Live
L3

VEC / domain contract

Vertical experience contract drives required fields, engines, and guard posture per storefront.

Dormant module
L4

Transaction engines

Pack 03 engines — RFQ, booking, lead, order, subscription. Runtime gated per vertical.

Runtime gated
L5

Payment / trust proof

Stripe webhook verification, ledger, proof_event, buyer protection, redress spine.

Dormant module
L6

Observability / readiness

p95, liquidity gate, A5 SLA, margin posture, FinOps snapshots — activation decisions.

Dormant module

FAZ 1 registry

Activation candidates

Six verticals in the current activation wave. None is public-live today.

Runtime gated

Stayix

Stays and hospitality booking intent on the Oferon canonical spine — Proof-of-One target.

Readiness
Readiness pending
Depends on
Booking engine refs + readiness gate
Runtime gated

Oferon Dine

Dining intent and reservation flows under governed commerce rails.

Readiness
Readiness pending
Depends on
Booking engine refs + readiness gate
Runtime gated

Oferon Estate

Property discovery and lead-ready listings with explainable fit signals.

Readiness
Readiness pending
Depends on
Listing/lead profile + regulatory gate
Runtime gated

Oferon Motors

Vehicle offers and comparisons with transparent ranking context.

Readiness
Readiness pending
Depends on
Listing/lead profile + readiness gate
Runtime gated

Oferon Mobility

Transfers and mobility options that connect into wider Connected Plans.

Readiness
Readiness pending
Depends on
Atomic session refs + readiness gate
Runtime gated

Oferon Beauty

Beauty and personal-care appointment intent with provider matching.

Readiness
Readiness pending
Depends on
Service engine refs + readiness gate

Public first-six rollout order lives under /verticals — Stayix.net through Oferon Beauty.

Hospitality vertical

Stayix — hospitality in active build

Stayix is the hospitality vertical in active build. One Core / one ledger / one operation; hospitality as vertical config. Booking runtime remains gated. No public booking confirmation is enabled yet.

Chain

Governed hospitality chain

Intent → stay criteria → availability check → booking request → proof/readiness. Availability and provider activation require readiness gates.

01

Intent

Live

Buyer stay criteria captured through structured demand rails — not opaque catalog browsing.

02

Stay criteria

Runtime gated

Lodging criteria snapshot at the contract boundary. PII scrubbed before downstream routing.

03

Availability check

Runtime gated

Readiness-gated availability posture. No public inventory counts or rate display on this surface.

04

Booking request

Planned

Booking request spine exists internally. Public write path and confirmation remain disabled.

05

Proof & readiness

Runtime gated

Proof events, redress spine, and SLA posture before any public hospitality activation.

Posture

Activation posture

Proof, redress, and SLA spine before public activation. Provider/network activation pending.

Public shellRuntime gatedGated Stayix shell on /hostay plus embedded sections on platform, readiness, and dashboard.
Booking runtimeRuntime gatedNo public booking confirmation. Booking runtime remains gated.
Provider / networkPlannedProvider and network activation pending readiness gates — not public-live.
Internal read-only gateReadyInternal build line has a read-only repository gate — not marketed as public-live.
Payment / fulfillmentRuntime gatedPayment and fulfillment runtime disabled on public surfaces.

Registry

21 canonical verticals — phased activation

FAZ 2 and FAZ 3 expand the registry without new engines.

FAZ 1

Activation candidates

Readiness-gated. None is public-live today.

StayixOferon DineOferon EstateOferon MotorsOferon MobilityOferon Beauty

FAZ 2

Expansion verticals

Registry-defined; activation follows FAZ 1 proof-of-one.

TradeServicesHealthEducationEventsB2B Supply

FAZ 3

Long-tail registry

No new engines — diversity via VEC/config only.

Remaining canonical verticals (21 total in registry)
Runtime gated

Vertical activation requires readiness go and explicit owner authorization. Stayix (stays) is an active internal build line — not public-live.