Codex Nexergy Energy on Reaktor
This is the target architecture for Nexergy Energy on Reaktor. Nexergy Energy is the platform itself: a real trader-aggregator startup and operating business. It assumes Reaktor itself is feature complete enough for Nexergy: graph workflows, service transports, auth, multitenancy, actors, bus, work, storage adapters, media, notifications, telemetry, deployment, workbench inspection, and graph visitors are available. This document is not a Reaktor backlog. It is the product and module architecture for Nexergy Energy.
The product features remain: public lead capture, buyer onboarding, RFQs, quotes, purchase orders, OMS, WMS, LMS/TMS, payments, settlements, supplier management, sustainability reporting, internal operations, analytics, and audit trails. The implementation model is Reaktor-native: reusable full-stack modules plus graph wiring.
The rule stays strict: do not create reaktor-biomass or reaktor-nexergy. Biomass is Nexergy Energy product configuration: material taxonomy, quality specs, cluster geography, supplier anonymity, margin policy, sustainability formulas, and operating playbooks. Reaktor gets generic modules because that is how the engine stays coherent; Nexergy Energy remains the actual platform being built.
Think of Reaktor as the Unreal-style engine under Nexergy Energy. The Reaktor modules are durable engine systems. Nexergy Energy wires those systems into one trader-aggregator platform.
1. High-Level Platform Design
Nexergy Energy should be understood as one operating platform with multiple surfaces over one set of authoritative facts. The surfaces are product graphs. The subsystems are service-backed operating domains. The reusable Reaktor modules are the engine substrate underneath them.
External users and channels
Guest site | Buyer portal | WhatsApp/API | Internal ops | Supplier ops | Warehouse | Logistics | Finance/Admin
|
Nexergy Energy platform graphs
PublicGraph | BuyerGraph | OpsGraph | SupplierOpsGraph | WarehouseGraph | LogisticsGraph | FinanceGraph | AdminGraph
|
Operating subsystems
Demand/CRM -> Party/KYC -> Catalog/PIM -> RFQ/Quote/Pricing -> Contract/OMS/PO
Procurement -> Inventory/WMS/QC -> Fulfillment -> Logistics/LMS/TMS -> POD/Claims
Finance/AR/AP/Tax -> Payments/Settlement -> Credit/Working Capital -> Sustainability/Traceability
Documents/Evidence -> Audit/Compliance/Policy -> Integrations -> Notifications -> Reporting
|
Reaktor engine substrate
graph/workflows | service/server | commerce | inventory | logistics | ledger | auth/tenant | db/media/bus/work
|
Runtime and data authority
Postgres/Hyperdrive | D1/Durable Objects | R2 | queues/pubsub | analytics/search | Cloudflare/JVM targets
The subsystem map is:
| Subsystem | What it owns for Nexergy Energy | Primary Reaktor substrate |
|---|---|---|
| Channel and experience surfaces | Public site, buyer portal, ops console, supplier intake, warehouse desk, logistics desk, finance/admin surfaces. | reaktor-graph, reaktor-service, reaktor-auth |
| Demand and CRM | Lead capture, contact routing, qualification, buyer onboarding, RFQ conversion, campaign/source attribution. | reaktor-commerce, reaktor-notifications, reaktor-ledger |
| Identity, tenant, party, and KYC | Buyer orgs, plants, suppliers, carriers, financiers, contacts, GST/KYC, tenant scopes, roles, redaction boundaries. | reaktor-auth, reaktor-multitenancy, reaktor-commerce |
| Catalog, PIM, and material specs | Biomass material taxonomy, grades, units, GCV/ash/moisture attributes, packaging, substitutions, buyer-visible projections. | reaktor-commerce, reaktor-db |
| Market intelligence and pricing | Price books, quote inputs, freight estimates, margin guardrails, benchmark rates, source availability, approval thresholds. | reaktor-commerce, reaktor-ledger, analytics projections |
| RFQ and quote desk | Requirement normalization, quote versions, quote approval, expiry, negotiation, buyer acceptance or rejection. | reaktor-commerce, reaktor-graph, reaktor-work |
| Contracts and standing orders | Rate contracts, call-offs, reserved capacity, SLAs, amendments, penalties, buyer commitments, supplier commitments. | reaktor-commerce, reaktor-ledger |
| OMS and purchase orders | Orders, splits, holds, substitutions, cancellations, buyer POs, supplier POs, promise state, claim triggers. | reaktor-commerce, reaktor-graph, reaktor-ledger |
| Procurement and supplier management | Supplier contracts, source plans, capacity, internal supplier POs, backup sourcing, supplier scorecards, settlement readiness. | reaktor-commerce, reaktor-inventory, reaktor-ledger |
| Inventory, WMS, and warehouse control | Stock lots, reservations, receiving, QC hold, putaway, pick/load, transfers, cycle counts, adjustments, replenishment. | reaktor-inventory, reaktor-media, reaktor-ledger |
| Quality and traceability | QC evidence, lab values, certificates, acceptance/rejection, retest, origin records, traceability bundle. | reaktor-commerce, reaktor-inventory, reaktor-media, reaktor-ledger |
| Fulfillment and allocation | Availability-to-promise, order allocation, source-to-stock decision, fulfillment readiness, shipment handoff. | reaktor-commerce, reaktor-inventory, reaktor-logistics |
| Logistics, LMS, and TMS | Pickup/drop schedules, lanes, carriers, vehicles, drivers, tracking events, weighbridge slips, POD, freight exceptions. | reaktor-logistics, reaktor-notifications, reaktor-ledger |
| Finance, tax, and accounting spine | Buyer receivables, supplier payables, invoices, credit notes, debit notes, GST/TDS artifacts, margin, reconciliation facts. | reaktor-commerce, reaktor-ledger, accounting adapters |
| Payments and settlement | Payment proof, payment gateway or bank adapter events, supplier settlement release, early payment, reconciliation, payout evidence. | reaktor-ledger, reaktor-commerce, reaktor-bus |
| Credit and working capital | Buyer credit limits, payment terms, credit breach approvals, supplier early payment, invoice discounting integration, risk holds. | App package first, reaktor-commerce, reaktor-ledger |
| Claims, returns, and issue resolution | Quality complaint, shortage, rejection, replacement load, credit note, supplier claim, support escalation, evidence review. | reaktor-commerce, reaktor-logistics, reaktor-ledger |
| Documents, media, and evidence | Contracts, buyer POs, supplier POs, invoices, QC certificates, weighbridge slips, POD photos, evidence bundles. | reaktor-media, reaktor-ledger, R2 |
| Sustainability and ESG | Coal displacement, biomass usage facts, carbon estimates, certificates, ESG exports, buyer sustainability reports. | App package, reaktor-ledger, analytics projections |
| Audit, compliance, policy, and redaction | Immutable command journal, approval trails, supplier anonymity, document access, retention, legal hold, replay, evidence export. | reaktor-ledger, reaktor-auth, graph visitors |
| Workflow and SLA automation | RFQ timers, approval routing, retries, reminders, shipment delay handling, settlement gates, recurring exports. | reaktor-graph, reaktor-work, reaktor-bus |
| Notifications and communications | Email, SMS, WhatsApp, app notifications, ops alerts, buyer status updates, supplier/internal reminders. | reaktor-notifications, reaktor-bus, reaktor-work |
| Reporting, analytics, and intelligence | RFQ conversion, quote win/loss, stock turns, delivery SLA, margin leakage, supplier performance, demand forecast. | reaktor-db, reaktor-ledger, analytics/search |
| Integrations and adapters | ERP, accounting, payment, bank, WhatsApp, GPS, weighbridge, carrier, tax, credit bureau, financier, BI exports. | reaktor-service, reaktor-bus, reaktor-secrets |
| Admin, configuration, and workbench | Tenant setup, roles, product config, approval policy, redaction policy, graph snapshots, deploy inspection, agent review. | reaktor-graph, reaktor-cloud, reaktor-secrets, workbench |
| Runtime and data authority | Authoritative relational state, edge read models, single-writer hot aggregates, documents, events, search, analytics. | Postgres/Hyperdrive, D1, Durable Objects, R2, queues/pubsub |
The key design constraint is that these are Nexergy Energy subsystems, not one module per subsystem. Reaktor gets only the reusable primitives that make the subsystems composable: commerce, inventory, logistics, ledger, graph workflows, service contracts, auth/tenancy, media, bus, work, and storage.
2. Market Scan
The competition confirms that biomass ecommerce is not a simple storefront. Buyers want supply assurance, quality evidence, pricing confidence, delivery control, invoices, sustainability records, and fewer coordination loops. Suppliers want demand, production planning, logistics, payments, and ledger visibility. The strongest competitors already sell pieces of this operating system.
| Source | What they signal | Reaktor implication |
|---|---|---|
| Buyofuel | Marketplace positioning, broad biofuel catalog, buyer RFQ, seller listings, trade updates, tracking, sustainability reporting, and an inventory app. | Nexergy needs RFQ, catalog, tracking, inventory, and sustainability parity, but not the open seller marketplace model. |
| Buyofuel buyers | Buyers can browse inventory, raise RFQs, receive counter offers, track purchase-order dispatches, download documents, and get CO2 reports. | Buyer portal must be procurement-grade: RFQ, quote, PO, order tracking, documents, and sustainability exports are table stakes. |
| Buyofuel inventory | Raw material inflow, finished product outflow, low-stock alerts, analytics, and manufacturing integration. | reaktor-inventory must cover WMS plus production-adjacent stock planning, not only ecommerce stock counts. |
| BiofuelCircle marketplace | Three-sided marketplace with verified suppliers, quote comparison, delivery planning, inventory/invoice views, transport, trade finance, and supplier ledgers. | Nexergy should internalize these capabilities but expose them as Nexergy-controlled projections, not direct buyer-supplier matching. |
| BiofuelCircle supply chain as a service | Direct procurement from farmers, local transport, customized storage, reverse supply chain, biomass banks, and farm-to-fuel execution. | The source-to-stock and source-to-delivery paths are as important as the buyer-facing order path. |
| BiofuelCircle Envira | Quality-assured briquettes with GCV, ash, moisture, testing, origin, and traceability. | Quality, traceability, and certificate primitives must be generic, then configured for biomass specs. |
| Moglix Business | Enterprise procurement, vendor management, VMI, category management, strategic cost management, supply-chain finance, P2P automation, contract optimization, custom storefronts. | Nexergy needs an enterprise procurement operating spine: contracts, price books, VMI, P2P integration, cost analytics, and supplier risk. |
| Credlix and Oxyzo | PO finance, invoice discounting, vendor finance, purchase finance, buyer creditworthiness, and working-capital products. | Credit and financing must be modeled now as service contracts and ledger facts, even if underwriting is integrated later. |
| Udaan | Mobile-first B2B buying with quick KYC, competitive prices, credit, fast delivery, returns, repeat orders, and delivery tracking. | Buyer UX must hide operational complexity behind fast repeat procurement, delivery status, credit, and simple issue resolution. |
| Shopify Admin API and commercetools APIs | Mature commerce platforms expose products, inventory, orders, shipping/fulfillment, payments, webhooks, staged/published product projections, and inventory entries as clean resource domains. | Reaktor modules should expose clean resource contracts and projections, not screens that directly own business state. |
The strategic difference for Nexergy Energy: competitors lean toward marketplace, managed marketplace, or procurement platform. Nexergy Energy's PRD is sharper: Nexergy is the counterparty. Buyers buy from Nexergy. Suppliers sell to Nexergy. Supplier identity is hidden. Nexergy wins by controlling supply, quality, delivery, finance, and accountability.
3. Commerce Operating Model
Every serious ecommerce platform is a set of operating loops, not a website.
| Loop | Typical ecommerce meaning | Nexergy meaning |
|---|---|---|
| Demand capture | Search, storefront, campaign, lead, cart, RFQ | Public site, WhatsApp/contact, lead, buyer onboarding, plant requirement, RFQ |
| Catalog and PIM | Product, SKU, attributes, variants, media, search, merchandising | Biomass material taxonomy, specs, grade, GCV/ash/moisture bands, packaging, substitution policy |
| Pricing and promise | Price book, discount, tax, availability-to-promise, SLA | Quote, margin guardrail, freight estimate, inventory/source check, delivery promise |
| Order orchestration | Order state machine, split, cancel, substitute, reserve, invoice | Nexergy quote acceptance, buyer PO, order confirmation, source/reserve, invoice, SLA |
| Procurement | Vendor, supplier PO, inbound, receiving | Supplier contract, procurement plan, supplier PO, pickup readiness, inbound stock, settlement |
| WMS | Receive, QC, putaway, pick, pack, load, count, adjust | Cluster/hub stock, biomass QC hold, weighbridge, stock lot, reservation, dispatch readiness |
| LMS/TMS | Shipment, carrier, route, tracking, POD, freight reconciliation | Trucking, pickup/drop schedule, GPS/manual events, POD, weighbridge slip, freight charge, exception |
| Finance | Payment, receivable, payable, refund, credit | Buyer AR, supplier AP, margin, GST/TDS, credit limit, payment proof, settlement release |
| Returns and claims | Return, replacement, refund, RTO, warranty | Quality complaint, short delivery, rejection, replacement load, credit note, supplier claim |
| Trust and compliance | Audit, fraud, policy, data retention | Supplier anonymity, approval policy, immutable audit, evidence bundles, sustainability certificates |
| Intelligence | Analytics, recommendation, forecasting, experimentation | RFQ conversion, price trends, stock turns, supplier score, demand forecast, margin leakage |
Nexergy Energy should not split these capabilities into isolated product silos. It should expose them as coherent platform surfaces backed by graph-wired recipes over reusable Reaktor modules.
4. Product Invariants
The PRD defines Nexergy Energy as a hybrid trader-aggregator. The Reaktor graph must preserve that operating model.
| Invariant | Reaktor meaning |
|---|---|
| Nexergy is the counterparty | Buyer-facing orders, invoices, support, and guarantees are issued by Nexergy. Supplier contracts and supplier POs are internal procurement records. |
| External users are buyers and guests | Buyer portal and public landing are external. Supplier tools are internal or tightly permissioned intake surfaces, never public seller storefronts. |
| Supplier anonymity is mandatory | Buyer-facing service responses expose cluster, quality, availability, traceability, and Nexergy assurance, not supplier identity. |
| Inventory and supply assurance are the moat | Stock control, source planning, reservations, backup suppliers, quality evidence, and delivery SLAs are first-class. |
| Ops console is the wedge | Internal ops coordinates RFQ, quote, procurement, inventory, fulfillment, finance, support, and audit before full self-serve scale. |
| Credit is part of commerce | Buyer credit, supplier early payment, settlement timing, invoice discounting, and credit breach approvals are modeled from day one. |
The old prototype's producer portal becomes NexergySupplierOpsGraph: internal procurement or controlled supplier intake. It is not a buyer-visible seller marketplace.
5. Module Targeting
Minimize modules by extracting only generic, high-leverage primitives. OMS, WMS, LMS, procurement desk, supplier portal, buyer portal, and finance console are Nexergy Energy platform surfaces built from these modules, not framework modules themselves.
| Module | Role | Why it is a module |
|---|---|---|
reaktor-commerce | Party, account, catalog/PIM, channel, RFQ, quote, price book, contract, order, PO, invoice, claim, approval, commerce projections. | Generic trade vocabulary; Nexergy Energy uses it for trader-aggregator procurement and sales. |
reaktor-inventory | Availability, stock lot, reservation, inventory movement, warehouse, zone/bin, WMS task, QC hold, cycle count, replenishment. | Quantity truth needs strong authority and audit rules; Nexergy Energy uses it for cluster stock and supply assurance. |
reaktor-logistics | Shipment, lane, route, carrier, vehicle, driver, tracking event, POD, freight charge, delivery exception. | Movement execution needs its own authority; Nexergy Energy uses it for biomass pickup, delivery, and proof. |
reaktor-ledger | Immutable command journal, domain event stream, audit trail, inventory ledger, finance ledger, hash chain, evidence export, replay. | Audit and ledger are cross-cutting primitives; mutable rows are not enough for finance, inventory, or compliance. |
Existing or assumed-complete Reaktor modules carry the rest:
| Existing Reaktor surface | Used for |
|---|---|
reaktor-graph | Platform graph, workflow graph, policy graph, state machines, graph visitors, snapshots, workbench rendering. |
reaktor-service | Typed service contracts, operation identity, clients, route mounting, service nodes. |
reaktor-server | Idempotency, retries, circuit breakers, rate limits, outbox, service interceptors, resilience. |
reaktor-bus | Domain events, async commands, fan-out, DLQ, idempotent consumers, integrations. |
reaktor-work | Scheduled work, long-running jobs, recurring exports, retries, reminders, SLA timers. |
reaktor-auth and reaktor-multitenancy | Buyer orgs, supplier scopes, internal roles, service principals, agent permissions. |
reaktor-db | Data descriptors, relational authority, projections, sync policy, analytics stores. |
reaktor-media | Contracts, buyer POs, supplier POs, invoices, QC certificates, weighbridge slips, POD photos, evidence bundles. |
reaktor-notifications | Email, SMS, WhatsApp, app push, workflow notifications, ops alerts. |
reaktor-cloud and reaktor-secrets | Cloudflare/JVM deployment, bindings, secrets, materialized infrastructure. |
Do not extract reaktor-finance yet. Start with finance contracts inside reaktor-commerce and immutable facts in reaktor-ledger. Extract reaktor-credit or reaktor-finance only if lending, underwriting, NBFC workflows, or multi-product financial services become a first-class platform business.
6. The Reaktor Commerce Substrate
reaktor-commerce should be small but expressive. It owns the business vocabulary of buying and selling. It does not own storage topology, UI, or domain-specific taxonomy.
| Primitive | Notes |
|---|---|
Party | Buyer, supplier, carrier, financier, internal entity, trading participant. |
Account | Commercial account with credit terms, tax profile, billing profile, allowed channels, and contacts. |
Location | Plant, warehouse, supplier yard, carrier hub, billing address, delivery address. |
CatalogItem | Generic sellable item or service. Biomass briquette is app config, not a framework type. |
Spec | Attribute schema for quality and eligibility: GCV, ash, moisture, size, grade, packaging, shelf life, compliance. |
Channel | Buyer portal, ops console, mobile app, API, WhatsApp, internal procurement desk. |
PriceBook | Base price, validity, tax, freight component, margin policy, customer terms, price source. |
RFQ | Negotiated demand with specs, quantity, delivery schedule, plant, payment terms, and SLA. |
Quote | Versioned offer with price, validity, sourcing plan, promise, and approval state. |
Contract | Long-term supply, rate contract, standing order, reserved capacity, penalty/SLA, amendment trail. |
Order | OMS aggregate with state, lines, splits, substitutions, cancellations, promises, holds, and external refs. |
PurchaseOrder | Buyer PO and supplier PO are two projections, with different visibility and policy. |
Invoice | Tax invoice, proforma, credit note, debit note, settlement invoice, payment schedule. |
Claim | Quality claim, shortage, rejection, replacement, credit, escalation. |
Approval | Margin override, credit breach, settlement release, QC rejection, contract change, inventory adjustment. |
Projection | Buyer, supplier, finance, warehouse, logistics, and admin projections over the same trade facts. |
The module should expose DTOs, Service contracts, graph nodes, policy hooks, projection helpers, and visitors. It should not contain Nexergy words such as biomass, briquette, husk, GCV target, or Brahmapur.
7. Inventory and WMS
reaktor-inventory owns physical and logical quantity truth.
| Primitive | Notes |
|---|---|
StockLot | Quantity of a catalog item at a location with owner, status, quality state, traceability, and cost basis. |
Availability | Sellable, reserved, committed, inbound, blocked, QC hold, damaged, expired, transferred. |
Reservation | Temporary or firm claim on stock for quote, order, contract, transfer, or production job. |
InventoryMovement | Append-only movement from one state/location/owner to another, backed by reaktor-ledger. |
Warehouse | Hub, yard, store, dark store, factory, supplier yard, or partner location. |
WmsTask | Receive, inspect, putaway, pick, pack, load, transfer, count, adjust, quarantine. |
QualityHold | Pending QC, accepted, rejected, retest, rework, customer-specific hold. |
CycleCount | Count plan, variance, approval, correction movement, reason code. |
ReplenishmentPlan | Reorder point, safety stock, forecast, source plan, and replenishment recommendation. |
Nexergy Energy maps clusters and hubs into Warehouse and Location. Moisture, ash, fines, GCV, NCV, feedstock, packaging, grade, and certificate requirements are Spec and StockLot attributes. The module stays generic, but the platform behavior is Nexergy-specific.
8. Logistics and LMS/TMS
reaktor-logistics owns movement execution.
| Primitive | Notes |
|---|---|
Shipment | Delivery unit with lines, origin, destination, promised date, current state, and proof requirements. |
ShipmentPlan | Route, vehicle type, capacity, loading window, delivery window, cost estimate, SLA. |
Carrier | Internal fleet, transporter, 3PL, courier, rail, ocean, or app-specific partner. |
Vehicle and Driver | Vehicle metadata, compliance docs, capacity, assignment, and driver contact policy. |
TrackingEvent | GPS, carrier API, mobile app, WhatsApp, manual update, gate scan, weighbridge event. |
ProofOfDelivery | Signature, photo, receiver identity, GPS pin, weighbridge slip, discrepancy note. |
FreightCharge | Estimate, actual, surcharge, detention, demurrage, penalty, pass-through policy. |
LogisticsException | Delay, breakdown, shortage, rejected load, route diversion, failed delivery. |
For Nexergy Energy this becomes plant delivery orchestration: pickup planning, truck assignment, weighbridge evidence, route tracking, POD, freight reconciliation, and delivery exceptions.
9. Ledger and Audit
reaktor-ledger is the keystone module. It is not just audit logging. It is the immutable fact system for operations, finance, inventory, replay, dispute resolution, and agent-safe changes.
| Ledger stream | Example entries |
|---|---|
| Command journal | Quote.Approve invoked by actor, request hash, auth context, idempotency key, result hash. |
| Domain event stream | RFQSubmitted, QuoteAccepted, OrderConfirmed, StockReserved, ShipmentDelivered, InvoiceGenerated. |
| Inventory ledger | Inbound to QC hold, QC hold to available, available to reserved, reserved to shipped, adjustment. |
| Finance ledger | Buyer receivable, supplier payable, payment received, credit note, settlement released, margin booked. |
| Compliance audit | Supplier identity redacted, document downloaded, price override approved, credit breach approved. |
Minimum primitives:
LedgerStream: named append-only stream per tenant, aggregate, or bounded context.LedgerEntry: event type, schema version, actor, tenant, command id, causation id, correlation id, trace id, timestamp, payload hash, previous hash.LedgerProjection: read model built from one or more streams.EvidenceBundle: exportable package for dispute, tax, compliance, audit, or investor review.RetentionPolicy: retention, legal hold, redaction, access policy, deletion exceptions.ReplayCursor: deterministic replay and projection rebuild checkpoints.
Graph visitors should enforce ledger coverage: any mutating finance, inventory, approval, settlement, credit, supplier visibility, or QC operation must append the required ledger facts.
10. Nexergy Energy Platform Graphs
Nexergy Energy is one platform composed from product graphs over the reusable modules.
| Graph | Audience | Responsibility |
|---|---|---|
NexergyPublicGraph | Guest | Marketing, material proof, lead capture, RFQ CTA, sustainability positioning, WhatsApp/contact routing. |
NexergyBuyerGraph | Buyer org users | Plants, team roles, RFQs, quotes, orders, invoices, deliveries, documents, issues, sustainability reports, repeat orders. |
NexergyOpsGraph | Nexergy operations | RFQ inbox, quote desk, procurement desk, order desk, inventory view, fulfillment desk, exceptions, approvals, audit. |
NexergySupplierOpsGraph | Internal procurement or permissioned supplier intake | Supplier contracts, capacity, inbound lots, QC docs, pickup readiness, settlement artifacts. Not buyer-facing. |
NexergyWarehouseGraph | Hub/warehouse team | Receipts, QC hold, stock lots, putaway, reservations, pick/load, transfers, cycle counts, adjustments. |
NexergyLogisticsGraph | Logistics desk or transport partner | Dispatch planning, vehicle assignment, route status, tracking events, POD, freight exceptions. |
NexergyFinanceGraph | Finance/admin | Buyer credit, invoices, receivables, payments, supplier payables, settlements, GST/TDS artifacts, margin. |
NexergyAdminGraph | Admin/compliance | Tenant policy, RBAC, approval rules, redaction rules, audit, reports, integrations, retention. |
These graphs are filtered projections over one source of truth. A buyer sees a Nexergy quote and a delivery promise. Ops sees the sourcing plan. Finance sees AR/AP and margin. Supplier ops sees procurement and settlement. The graph enforces which projection is legal. This is Nexergy Energy's operating system.
11. Service Map
Use stable operation identities. Routes can move; operation names should stay durable graph facts.
| Service | Module | Responsibilities | Example operations |
|---|---|---|---|
LeadService | reaktor-commerce plus app config | Public lead capture, consent, qualification, lead to buyer/RFQ conversion. | Lead.Capture, Lead.Qualify, Lead.ConvertToRFQ |
PartyService | reaktor-commerce | Buyer orgs, plants, suppliers, carriers, financiers, contacts, GST/KYC, address book. | Party.CreateBuyer, Party.Verify, Party.AddLocation |
CatalogService | reaktor-commerce | Product/material taxonomy, specs, grades, substitutions, buyer-visible catalog projections. | Catalog.DefineItem, Catalog.PublishProjection, Catalog.Search |
MarketIntelService | reaktor-commerce plus analytics | Price trends, source availability, demand signals, benchmark rates, competitor parity. | MarketIntel.PriceTrend, MarketIntel.SourceAvailability |
RfqService | reaktor-commerce | RFQ intake, requirement normalization, SLA timers, assignment, procurement-plan draft. | RFQ.Submit, RFQ.Normalize, RFQ.Assign, RFQ.Close |
PricingService | reaktor-commerce | Price books, margin guardrails, freight estimate, taxes, quote approval thresholds. | Price.Calculate, Price.ApproveOverride, Price.Lock |
QuoteService | reaktor-commerce | Nexergy quote, quote versions, expiry, acceptance, rejection, conversion to order. | Quote.Create, Quote.Approve, Quote.Accept, Quote.Expire |
ContractService | reaktor-commerce | Rate contracts, standing orders, supply commitments, amendments, SLA penalties. | Contract.Create, Contract.Amend, Contract.ScheduleCalloff |
OrderService | reaktor-commerce | OMS aggregate, splits, cancellation, substitution, holds, promise, invoice trigger. | Order.Create, Order.Confirm, Order.Split, Order.Cancel |
PurchaseOrderService | reaktor-commerce | Buyer PO and supplier PO projections, amendments, document linkage. | BuyerPO.Attach, SupplierPO.Issue, PO.Amend |
ProcurementService | reaktor-commerce | Supplier contracts, source planning, capacity, backup source protocol, procurement price history. | Procurement.Plan, SupplierCapacity.Reserve, SupplierPO.Request |
InventoryService | reaktor-inventory | ATP, stock lots, reservations, committed/inbound stock, holds, adjustments, transfers. | Stock.Receive, Stock.Reserve, Stock.Release, Stock.Adjust |
WarehouseService | reaktor-inventory | WMS tasks, QC hold, putaway, pick, load, cycle count, variance. | Warehouse.Putaway, Warehouse.Pick, Warehouse.CycleCount |
QualityService | reaktor-commerce plus reaktor-inventory | Specs, QC evidence, certificates, rejection, replacement, supplier score. | QC.RecordResult, QC.ApproveLot, QC.RejectLot |
FulfillmentService | reaktor-commerce plus reaktor-logistics | Allocation, fulfillment order, readiness, shipment creation, dispatch handoff. | Fulfillment.Allocate, Fulfillment.MarkReady, Fulfillment.CreateShipment |
LogisticsService | reaktor-logistics | LMS/TMS: lane, vehicle, carrier, route, tracking, POD, freight, delay exception. | Shipment.Dispatch, Shipment.Track, Shipment.UploadPOD, Shipment.Close |
FinanceService | reaktor-commerce plus reaktor-ledger | AR/AP, invoice, payment proof, reconciliation, credit, settlement, margin, GST/TDS. | Invoice.Generate, Payment.Record, Settlement.Release |
CreditService | app package first, later optional reaktor-credit | Buyer credit limit, payment terms, supplier early payment, invoice discounting, risk holds. | Credit.CheckLimit, Credit.ApproveBreach, Finance.OfferEarlyPayment |
SustainabilityService | app package plus reaktor-ledger | Biomass usage, coal displacement, carbon estimate, certificate, ESG export. | Sustainability.Calculate, Certificate.Issue, Report.Export |
DocumentService | reaktor-media | PO, invoice, QC certificate, contract, weighbridge slip, POD, evidence export. | Document.Upload, Document.Sign, Document.GetRedacted |
AuditService | reaktor-ledger | Command journal, audit facts, actor attribution, evidence bundles, replay pointers. | Audit.Append, Audit.Query, Audit.ExportEvidence |
ReportingService | reaktor-db plus analytics | KPI, margin, inventory turns, SLA, RFQ conversion, supplier scorecards, delivery performance. | Report.Query, Metric.Snapshot, Dashboard.Project |
12. Workflow Recipes
Workflows stay in reaktor-graph. OMS, WMS, LMS, procurement, and finance are graph recipes over services and actors.
| Workflow | State owner | Critical path |
|---|---|---|
| Lead to RFQ | Lead and RFQ | capture lead -> qualify -> create buyer/org -> submit RFQ -> assign ops owner |
| RFQ to quote | RFQ and Quote | normalize need -> check catalog/spec -> estimate freight -> check ATP/source -> price -> approve -> send quote |
| Quote to order | Quote and Order | buyer accepts -> attach buyer PO -> credit check -> confirm order -> reserve stock or source supply |
| Source to stock | Procurement and StockLot | plan supply -> issue supplier PO -> schedule pickup -> receive inbound -> QC -> stock lot -> supplier payable |
| Availability to promise | Inventory and Quote | check stock -> reserve -> if short, source -> if risk, human approval -> publish promise |
| Order to delivery | Order and Shipment | allocate -> create fulfillment -> pick/load -> dispatch -> track -> POD -> close shipment |
| Delivery to cash | Invoice and Payment | generate invoice -> send -> collect -> reconcile -> release supplier settlement -> close margin |
| Issue to resolution | Claim | complaint -> evidence review -> replacement/credit/rejection -> supplier claim if needed -> ledger close |
| Supplier early payment | Settlement and Credit | supplier payable -> eligibility -> discount/fee -> approval -> payout -> ledger |
| Sustainability certificate | SustainabilityReport | delivered biomass facts -> formula -> certificate -> buyer ESG export -> evidence bundle |
Every workflow declares command, aggregate, auth, idempotency key, timeout, retry policy, ledger requirements, failure states, and projection rules. A Reaktor visitor should reject workflows that mutate money, stock, quality, or supplier visibility without ledger and approval coverage.
13. Ecommerce Back Office Recipes
These are not modules. They are compositions.
| Back office system | Built from |
|---|---|
| OMS | reaktor-commerce orders, quotes, contracts, POs, claims, approvals; reaktor-graph workflows; reaktor-ledger events. |
| WMS | reaktor-inventory stock lots, reservations, movements, WMS tasks, QC holds, cycle counts; reaktor-media documents. |
| LMS/TMS | reaktor-logistics shipment, route, carrier, tracking, POD, freight, exceptions; reaktor-notifications updates. |
| PIM/catalog | reaktor-commerce catalog item, spec, attributes, search projection, staged/published projections. |
| Procurement desk | reaktor-commerce procurement, supplier contract, supplier PO, capacity, price history; reaktor-ledger and reaktor-inventory. |
| Finance desk | reaktor-commerce invoice/payment/settlement; reaktor-ledger finance streams; reaktor-auth approvals. |
| Support/claims | reaktor-commerce claim, document evidence, shipment data, QC evidence, credit note/replacement workflow. |
| Intelligence desk | reaktor-db, reaktor-ledger projections, market intelligence service, forecasting, scorecards. |
This gives the Flipkart/Myntra-style operating surface without baking Flipkart/Myntra-specific systems into Reaktor.
14. Data Authority and Runtime Topology
Reaktor should make data authority a deployment decision behind typed services.
| Data/runtime | Role in Nexergy |
|---|---|
| Postgres / Hyperdrive / JVM Postgres | Authoritative relational state for parties, catalog, RFQs, quotes, orders, POs, contracts, permissions, finance. |
| D1 | Edge MVP tables, public lead capture, edge read models, dedup/outbox where appropriate, lightweight ops state. |
| Durable Objects | Single-writer hot aggregates: order coordinator, reservation coordinator, shipment tracker, idempotency authority, rate limiter, live ops session. |
| R2 | Documents: POs, invoices, contracts, QC certificates, weighbridge slips, POD photos, exports, evidence bundles. |
Pub/Sub / Cloudflare Queues through reaktor-bus | Domain events, async commands, retries, DLQ, reporting fan-out, notifications, integrations. |
| Analytics store | RFQ conversion, quote win/loss, stock turns, margin leakage, supplier performance, delivery SLA, sustainability metrics. |
| Search index | Catalog search, spec search, buyer order search, ops work queues, supplier/internal search. |
| Reaktor snapshots | Workbench, docs, graph diffs, agent context, deployment review, audit context. |
15. Security, Tenancy, and Redaction
Supplier anonymity is a business model rule. It must be enforced in service DTOs, projections, graph visitors, and tests.
Required policies:
- Every protected route and operation declares an
AuthRequirement. - Every request carries tenant, principal, role, organization, and channel.
- Buyer users see buyer org data, plant data, Nexergy quotes/orders, delivery status, invoices, redacted quality evidence, and sustainability reports.
- Buyer-facing DTOs never include supplier id, supplier legal name, supplier price, supplier contact, raw procurement terms, or supplier settlement state.
- Internal users see supplier data only through explicit roles and approval scopes.
- Finance, credit, settlement, QC rejection, supplier contract, price override, and inventory adjustment require immutable ledger entries and approvals.
- Agent access is read/propose by default. Graph mutation, deploy, finance, credit, and auth admin remain explicitly gated.
- Export and document download events are ledgered with actor, purpose, tenant, and target.
16. Build Sequence
Because Reaktor is assumed complete, the build sequence is product-first.
Phase 0: Freeze the vocabulary
- Convert the prototype sample data into typed fixtures.
- Remove buyer-facing producer portal language.
- Define canonical aggregates: party, catalog item, spec, RFQ, quote, contract, order, buyer PO, supplier PO, stock lot, reservation, shipment, invoice, payment, settlement, claim, ledger entry.
- Define buyer, internal, supplier-ops, warehouse, logistics, finance, and admin projections.
Phase 1: Ledger and contracts first
- Implement
reaktor-ledgeras the first new primitive. - Define service contracts for lead, party, catalog, RFQ, quote, contract, order, PO, procurement, inventory, warehouse, logistics, finance, documents, audit, sustainability, and reporting.
- Add graph visitors for ledger coverage, redaction coverage, idempotency coverage, approval coverage, and data-authority coverage.
Phase 2: Ops-first MVP
- Build
NexergyOpsGraph,NexergyBuyerGraph, andNexergyPublicGraph. - Back lead, RFQ, quote, order, stock lot, document, and audit flows with real persistence.
- Keep supplier operations internal.
- Make buyer portal a projection over the same records.
Phase 3: Commerce, inventory, and logistics extraction
- Extract
reaktor-commerceonce RFQ/quote/order/PO/invoice/contracts stabilize. - Extract
reaktor-inventoryonce stock lot/reservation/movement/WMS tasks need independent authority. - Extract
reaktor-logisticsonce shipment/tracking/POD/freight is reusable outside Nexergy.
Phase 4: B2B depth
- Add standing orders, rate contracts, buyer credit limits, supplier early payment, market-intelligence dashboards, supplier scorecards, price trend reports, and VMI/replenishment planning.
- Add WhatsApp, payment, accounting, GPS, and ERP adapters behind ports.
- Add repeat order, delivery schedule edits, claim resolution, and evidence exports.
Phase 5: Scale and automation
- Add automated pricing, demand forecasting, source optimization, stock rebalancing, credit/risk suggestions, and sustainability analytics.
- Add mobile buyer, warehouse, and logistics flows.
- Add agent-assisted ops in the workbench with read/propose permissions and strict approval gates.
17. Non-Goals
- No
reaktor-biomass,reaktor-nexergy, or biomass-specific framework module. - No public supplier marketplace unless the PRD changes.
- No direct buyer-supplier messaging.
- No separate workflow engine duplicating
reaktor-graph. - No OMS/WMS/LMS modules as monoliths; they are recipes over generic modules.
- No finance, credit, inventory, quality, or audit mutation without ledger-backed idempotency and actor attribution.
- No hard dependency on one deployment topology; Cloudflare-first and JVM/Postgres must both be possible behind the same service contracts.
18. Final Shape
Nexergy Energy is the production platform. Reaktor is the engine underneath it, and the same engine discipline keeps Nexergy focused while the underlying primitives stay reusable.
reaktor-graph
workflows, policies, visitors, platform graphs, snapshots, workbench inspection
reaktor-service + reaktor-server + reaktor-bus + reaktor-work
typed operations, resilience, idempotency, outbox, events, scheduled work
reaktor-commerce
party, catalog, channel, RFQ, quote, contract, order, PO, invoice, claim, approval, projection
reaktor-inventory
availability, stock lot, reservation, WMS task, QC hold, movement, replenishment
reaktor-logistics
shipment, route, carrier, vehicle, tracking, POD, freight, delivery exception
reaktor-ledger
command journal, audit, domain events, inventory ledger, finance ledger, replay, evidence export
platform graph: Nexergy Energy
biomass specs, clusters, supplier anonymity, margin rules, sustainability formulas, buyer and ops experience
That is the intended split: Nexergy Energy gets a focused, production-grade platform, while Reaktor stays a small set of expressive engine modules instead of accumulating vertical product modules.
Sources Scanned
- Buyofuel home, buyers, sellers, inventory management, and sustainability reporting
- BiofuelCircle home, marketplace, procurement service, supply chain as a service, sales service, value added services, and Envira
- Moglix Business, Moglix retail marketplace, Credlix, Oxyzo, and Udaan
- Shopify Admin API, commercetools products API, and commercetools inventory API
Related docs
- Nexergy on Reaktor (Claude) - Use when designing the production Nexergy Energy system on Reaktor, scoping the ledger/catalog/fulfillment modules, designing embedded-finance/credit on the ledger, or turning the Nexergy prototype into a production system.
- Service Layer - Use before adding service APIs, splitting reaktor-service out of reaktor-graph, wiring handlers to Spring/Workers, or making modules graph-projectable without hard graph dependencies.
- Data Layer - Use before choosing a store, designing offline-first sync, or deciding authority vs cache vs projection for a datum; the centerpiece is the tier 1↔2/3 server-authoritative sync engine.
- Work - Use before changing background scheduling, worker contracts, WorkRequest/WorkConstraints, BestBuds workers, edge/web scheduling, work telemetry, or graph projection for work.
- UI & Design System - Use before touching reaktor-ui tokens/components/theming, designing the tactile runtime (interaction/physics/field/skins/host-tree/reconciler), or planning adaptive layouts and AI/server-driven UI.
- React x Compose - Use before touching the React/Compose bridge.