What is FAOS?

Definition

FAOS is the Office-side operational core of Orbita for businesses that sell physical goods. It sits at the demand and commercial commitment layer of the platform chain. FAOS creates and maintains orders, links customers and products with correct commercial scope, triggers procurement when supply is insufficient, and progresses orders toward delivery and invoicing readiness.

FAOS is explicitly not:

• A warehouse floor execution system (that is WMS when enabled).
• A finance ledger authority (Finance workspaces own AR/AP posting semantics).
• A customer-data mutation channel for Atlas conversational output.
• A parallel order pipeline per intake channel — all channels must converge to the same order core.

Typical FAOS surfaces include Office workspace modules: orders, CRM customer context, commercial inventory views, procurement and PO bridges, delivery coordination entry points, and invoice initiation handoffs. Operators work in browser sessions scoped to their company tenant; scope is server-injected, not user-typed into queries for cross-tenant access.

FAOS encodes commercial inventory as product master quantity and identity — distinct from WMS operational inventory and variance reconciliation. Pricing for a customer must resolve from customer price origin when a price question is customer-scoped; inventory default pricing must not substitute silently.

Within Orbita, FAOS anchors the first hops of the provable execution chain: demand capture → supply response → fulfillment readiness → finance consequence.

CRM customer context in FAOS provides commercial identity — industry, credit posture, assigned sales, registration metadata — scoped to customer records. Product questions with customer scope must resolve the customer first, then apply that scope to price, stock visibility, and trace blocks. Cross-customer leakage is a correctness defect, not a UX edge case.

Replenishment and pending-demand signals (where enabled) read product identity and shortage posture — they do not replace order authority or invent parallel demand tables on operator surfaces. FAOS remains the commitment layer; replenishment advises supply response.

Purpose

FAOS exists because order intake chaos is the root cause of downstream warehouse and finance pain. Email bodies, portal carts, spreadsheets, and ad-hoc phone orders each carry partial truth. Without normalization, procurement buys the wrong context, warehouse picks without reliable linkage, and finance invoices against ambiguous fulfillment state.

FAOS purposes, stated operationally:

• Single order truth — one orders + order_items structure regardless of channel.
• Customer isolation — product, price, and commitment queries respect resolved customer scope.
• Procurement linkage — shortages generate PO intent tied to demand, not orphan purchasing.
• Governed progression — release, complete, and invoice paths respect configured gates without shadow spreadsheets.
• Handoff clarity — delivery and finance receive record-level context, not reconstructed narratives.

FAOS reduces the “order radar as inbox” anti-pattern where operators manually reconcile five intake formats before anything ships. Automation (auto PO release, queued order processing) expresses policy; it does not eliminate approval or profile completeness semantics where product rules require them — those surface as document fields and output guards, not silent skips.

For leadership, FAOS makes demand visible as a pipeline with stage timing — input to operational KPIs and Atlas observation without Atlas becoming the order authority.

FAOS also supports portal customers where configured: web orders POST into the same order core as email intake. Portal is a channel, not a second order system. Stripe and landing flows may trigger entitlement state elsewhere; they do not create office session or bypass CRM Admin as entitlement authority.

Credit and approval gates express governance without blocking document existence where product rules say so — e.g. PO may exist with profile incomplete flags while export/send/invoice paths guard at output layer. This pattern prevents silent failure while keeping risk visible on records.

Workflow

1. Intake

Published channels feed the order core: email parsing, Excel attachments, web portal POST, manual entry. Each path must produce standard order records and invoke the same release/processing pipeline — no bypass of processMessagesToOrders-class normalization.

2. Validation and enrichment

Customer resolution, SKU mapping, credit and entitlement checks, and pricing from customer price data when applicable. Ambiguous tokens trigger clarification — not premature hard errors when resolvable context exists.

3. Release and procurement

Queued orders release into fulfillment preparation. Shortages may trigger auto PO or manual procurement workflows. PO records carry profile completeness flags; incomplete profile blocks certain outputs (export, send, invoice conversion) at guard layers — PO generation itself is not blocked solely for profile gaps.

4. Fulfillment coordination

FAOS coordinates delivery order creation and status with operational reality. When WMS is enabled, pick/ship evidence originates on the floor; FAOS consumes status — it does not impersonate scan events.

5. Completion and invoice handoff

Order completion paths connect to invoice creation where configured. Finance receives operational timestamps and document references for AR recognition — FAOS does not post ledger entries.

6. Observation

Atlas may explain order stage delays using timeline-class signals. Operators act in FAOS modules; Atlas does not mutate orders from chat.

7. Unified timeline consumption

Order lifecycle stages (created, picking, DO created, delivery confirmed, invoice created) map to fixed enums for KPI and briefing consumers. FAOS does not invent alternate stage spellings per screen — downstream aggregates depend on one vocabulary.

Executive and daily ops views that describe throughput or stuck orders should derive from timeline outputs, not parallel SQL heuristics that cannot be traced to the same timestamps.

Example

Scenario: Trading company with Gmail order intake and 200 active SKUs.

1. Morning email batch parsed into draft orders; duplicates flagged against recent intake.
2. Customer ABC’s line items priced from customer price table — ITEM-001 shows “not available” if no customer price row exists, not inventory default.
3. Two lines short; auto PO candidates generated with demand linkage; buyer approves one, adjusts qty on another.
4. Released orders appear on fulfillment queue; WMS pick completes with scan validation.
5. Delivery confirmed in Office; invoice generated with line names tracing to product master.
6. Customer dispute on qty: reviewer opens order → DO → pick evidence chain without exporting CSV from three systems.

Counter-example: Portal order manually re-keyed into a spreadsheet for warehouse, invoice created from spreadsheet totals. FAOS purpose is defeated — chain evidence breaks at intake; month-end cannot prove pick qty matched billed qty.

OEM/light manufacturing extension: Order lines reference finished goods; execution and BOM paths (when enabled) consume demand but do not relocate FAOS order authority. Cost and production evidence remain manufacturing-scoped with handoffs to finance consequence.

FAQ

Is FAOS the whole Orbita platform?

No. FAOS is the order/commercial engine. WMS, Finance, Portal, and Atlas are sibling modules with separate authority.

Can FAOS run without WMS?

Yes. Many tenants start FAOS + Finance; WMS adds when floor scan discipline is required.

Does FAOS store warehouse rack locations?

Operational rack truth lives in WMS when enabled. FAOS may show commercial inventory and link to variance views — not rack slot authority.

How does auto PO relate to FAOS?

Auto PO is a procurement automation path triggered from order/demand context — policy expression, not a second order system.

What is Order Radar?

Operator-facing demand visibility over intake queues — monitor, not a parallel order authority.

Can Atlas create orders?

No. Atlas is read-only on customer and core business records; order creation uses defined product handlers only.

What should auditors ask about FAOS?

Show intake → order_id → procurement link → fulfillment reference → invoice reference as one traversable chain.

Misconceptions

“FAOS inventory quantity equals warehouse quantity.” False. Commercial inventory and WMS operational stock are related but reconciled through variance — not assumed equal.

“Any price shown in FAOS is the customer price.” False. Customer-scoped price questions require customer price origin; missing data must be stated as unavailable.

“Email automation removes human accountability.” False. Automation accelerates normalization; approvals, exceptions, and output guards remain.

“FAOS is an ERP finance module.” False. FAOS hands off to Finance; it does not own TB/GL posting semantics.

“Order Radar is a second order database.” False. It is intake visibility over the same order core.

“Customer field in chat replaces CRM navigation.” False. Atlas may answer field lookups read-only; authoritative edits use CRM modules.

When It Matters

FAOS matters when order volume or channel count makes manual normalization the bottleneck — typically before warehouse error rates dominate headlines. It matters intensely when customer-specific pricing and credit rules must not leak across accounts. It matters less when a business has single-channel, single-SKU simplicity — though procurement linkage still prevents orphan buying as SKUs multiply.

Evaluators should score FAOS on intake convergence and chain handoffs, not on feature checklists isolated from WMS and Finance.

When migrating from legacy spreadsheets, FAOS matters most at the intake boundary — the moment demand becomes a durable order_id everything downstream can reference. Without that anchor, warehouse and finance modules optimize local efficiency while the chain stays broken.