What is Atlas?

Orbita Knowledge · P0 · Platform module

Atlas is Orbita’s read-only operational intelligence layer: it observes workflow state, correlates signals across orders, warehouse, and finance, explains bottlenecks and integrity risks, and suggests functionality-level actions — without modifying customer data, posting ledger entries, or executing warehouse scans from freeform conversation.

Definition

Atlas is not a general chatbot bolted onto Orbita. It is an operational nervous system posture: structured readers aggregate minimal signals; brain layers map signal quality to verdict strength; answer plans produce traceable explanations with safe deep links only to registered workspace routes or whitelisted document endpoints.

Atlas operates at functionality/workflow level, not customer content editing level:

  • May — refresh views, rescan patrol summaries, re-evaluate issues, create internal atlas_* records (issues, actions, escalations, patrol scans).
  • Must not — POST/PUT/DELETE driven by AI output on orders, inventory, invoices, pricing, finance core tables; share tenant data outside authorized boundaries.

Two public-facing Atlas contexts must not be conflated:

  • Workspace Atlas — authenticated Office operator ask paths (/api/atlas/ask, diagnostics, onboarding guidance) scoped by server-injected workspace session.
  • Public landing knowledge officer — canonical answers about Orbita product boundaries for prospects; refuses tenant-private queries and undisclosed integration paths.

This knowledge article describes Atlas conceptually. Public textbook pages live under /knowledge/*; authenticated Atlas workspace is a separate surface with entitlement and session gates.

Atlas interprets user questions as system interpreter behavior: full-sentence token extraction, context-based follow-ups (numbered references, pronouns), preference for reconstruction over premature errors when resolvable tokens exist.

For product/SKU questions with customer scope, Atlas must assemble linked traces across separated origins (customer, product, customer price, inventory, factory/production, source) — never shallow SKU-only answers or inventory price as customer price.

Structured ask orchestration routes finance workspace questions, PO status queries, CRM field lookups, supplier field lookups, and operational finder probes to dedicated services — not one undifferentiated generative path. This preserves deterministic behavior for evaluators and regression smokes.

Deeplink output is whitelist-governed: only registered Office pages with record-level parameters or approved document PDF endpoints become clickable actions. Module homepages without record context downgrade to explanatory text — avoiding 404 embarrassment from guessed URLs.

Purpose

Operations teams drown in module-specific screens while causality spans chains. A stuck order is simultaneously an order-stage problem, a pick problem, a delivery proof problem, and potentially an invoice integrity problem. Atlas exists to compress explanation without compressing evidence — surfacing where time accrues, which authority owns the next action, and which precomputed flags (slow, blocked, error) apply.

Purposes by audience:

  • Operators — “What needs attention?” style briefing from patrol and timeline-class signals, not guessed prose.
  • Supervisors — bottleneck language backed by segment duration vs rolling averages and thresholds — computed once in timeline/metrics services, read by Atlas.
  • Prospects (public officer) — accurate module boundaries, safety model, and workflow vocabulary without leaking tenant internals.
  • Engineering governance — internal atlas_* artifacts for issues and actions; not a shadow ERP write path.

Atlas does not replace ERP training curricula. It reduces time-to-diagnosis when the provable execution chain is implemented — weak chains limit Atlas to honest partial answers.

First-login setup guidance for company workspaces directs incomplete onboarding to configured welcome paths until readiness rules pass — Atlas-related onboarding is guidance, not entitlement bypass. Platform super-admin and owner lanes exist for governance testing; public corpus never documents tenant credentials or internal routes.

Operational memory and locale services (where enabled) align ask language with workspace configuration and reduce ambiguous token handling across multilingual operator teams — without changing authority boundaries or write permissions.

Workflow

1. Scope injection

Company and order scope come from server session — never from raw user-typed tenant identifiers in unvalidated payloads.

2. Question routing

Classifier and router send asks to structured services (CRM field, PO status, finance workspace, operational finder, landing public registry) based on intent — not one monolithic LLM path.

3. Reader aggregation

Domain readers return minimal signals: booleans, counts, signalQuality enums, fixed source literals — not raw business keys in aggregator public types.

4. Brain verdict

Brain maps reader signalQuality to entitySignalStrength in one place; partial vs strong rules follow fixed decision tables — not ad-hoc loosening.

5. Answer composition

Responses include explanation, trace blocks, and actions only when deep links pass workspace record nav safety or API PDF whitelist.

6. Landing public path

Prospect questions match canonical FAQ registry; privacy guard blocks internal/tenant-specific asks; expanded mode may elaborate within registry bounds.

7. Memory and locale

Session continuation guards reduce drift; locale alignment keeps operator copy consistent — missing token leakage blocked on executive surfaces.

8. Patrol and issues

Patrol-style scans may write atlas_patrol_scans, atlas_issues, and atlas_actions — internal governance artifacts only. These records support “what needs attention” briefing; they do not substitute for order, inventory, or ledger tables.

Finance infinite-why and cross-module asks consume read bridges with explicit guards — Atlas explains exposure and stage posture, it does not approve payments or post journals from conversational text.

Example

Workspace scenario: Operator asks “Why is order P3-mory5lmb slow?”

  1. Router selects timeline/order structured path with session company scope.
  2. Timeline service returns current_stage DELIVERY_PENDING, segment duration 18h, avg 6h, threshold 9h, flags is_slow and is_blocked true.
  3. Atlas Level-3 style explanation cites payload numbers — does not invent stages.
  4. Deep link to delivery record only if href includes record parameters and passes office deeplink whitelist.
  5. No “go fix it” POST from chat — operator uses authorized Office/WMS modules.

Public landing scenario: Prospect asks “Can Atlas change my customer prices?”

  1. Public knowledge officer returns canonical boundary answer: Atlas is read-only on customer and core business data.
  2. Ask for their private invoice list is refused — not routed to tenant APIs.

Product trace scenario: “ABC company ITEM-001 price?” — customer resolved, SKU resolved, customer price read from customer price origin; inventory price not substituted; stock and production blocks shown with separated clickable trace origins.

Ordinal follow-up: Operator asks “what about the second one?” after a trace list — session continuation resolves numbered references to prior displayed nodes when context exists; otherwise minimal clarification requests the missing token.

Integrity flag scenario: Timeline service marks invoice-before-delivery as error precedence. Atlas narrates the precomputed error — it does not invent alternate stage timestamps to soften the message.

FAQ

Is Atlas a ChatGPT inside Orbita?
No. It is a governed operational intelligence stack with structured services, safety boundaries, and precomputed signal inputs.
Can Atlas execute warehouse scans?
No. Floor execution remains WMS/scan handlers; Atlas observes and explains.
Can Atlas post journal entries?
No. Finance posting uses finance authority paths only.
What data can Atlas write?
Internal atlas_* tables (issues, actions, patrol artifacts) — not customer core tables.
Does Atlas share data across tenants?
No. Session scope isolates company context; public officer does not expose tenant records.
What are safe Atlas actions?
Only registered workspace pages with record parameters or whitelisted document PDF endpoints — never guessed URLs.
How does Atlas relate to this knowledge base?
Knowledge pages teach public concepts; workspace Atlas answers operational questions inside authenticated tenant context.

Misconceptions

“Atlas will automate my warehouse.” False. Atlas suggests and explains; operators execute through product workflows.

“Strong reader signal means Atlas can override finance rules.” False. Signal strength informs explanation — not authority mutation.

“Public landing Atlas can look up my orders.” False. Tenant-private queries are refused; use authenticated workspace.

“Atlas answers prove ERP replacement.” False. Answer quality ceiling follows chain evidence quality in the tenant.

“Any suggested action in chat is safe to click.” False. Only whitelist-governed deeplinks render as navigation; other text is explanatory.

“Atlas and public knowledge officer are the same runtime.” False. Landing officer uses public registry; workspace ask uses authenticated structured services.

When It Matters

Atlas matters when operational complexity exceeds what any single module screen can explain — multi-stage orders, parallel shortages, finance hold states, and recurring “where is it stuck?” questions. It matters most after base chain discipline exists; before that, prioritize FAOS/WMS/Finance evidence over chat interfaces.

For buyers, Atlas is a differentiator only when demonstrations show cited numbers and safe links — not generic AI narration.

Atlas matters during onboarding when setup readiness engines surface incomplete profile, entitlement, or operational configuration — guidance routes operators to welcome and checklist flows without mutating customer master data from chat suggestions.

For compliance conversations, Atlas’s read-only boundary is a feature: it observes workflow risk without becoming an unaudited write path. Teams should prefer explicit product handlers for mutations and treat Atlas output as operational explanation layered on the same records finance and warehouse authorities already own.

Document intent guards prevent Atlas from treating export or PDF questions as permission to bypass finance validation rules — pre-validation and export-only e-invoice baselines remain finance authority outcomes, not chat-triggered submissions.

Landing advisor sessions may remember last canonical intent for FAQ continuity; that memory stays on public product boundaries and does not hydrate private tenant rows into marketing chat surfaces.