alaivOS Business — Platform Scope & Vision¶
Version: 1.1 · Date: March 2026 · Owner: Citerius Holdings LLC
Audience: All agents, engineers, PM, founders
Document type: Living vision — updated as platform evolves
This document describes what alaivOS Business is, what it is building toward, and why the architecture is designed the way it is. It is the answer to "what are we building?" Read this before the technical specs. It does not contain locked implementation decisions — those live in the canonical KB docs. It contains the reasoning that makes those decisions coherent.
The Core Idea¶
Every business — regardless of sector — operates across the same four fundamental dimensions. It moves money, manages time and resources, communicates, and stores knowledge. A logistics company and a construction firm are not structurally different businesses. They are the same business wearing different clothes.
alaivOS Business is a single operating system for all of them.
One backbone. One data model. One AI agent framework. What changes between a logistics deployment and a construction deployment is vocabulary, domain knowledge, and which capabilities are pre-installed. None of that requires a separate codebase. None of it requires a separate product. It requires configuration.
The analogy is iOS: iOS does not become a different operating system when you install a logistics app vs. a construction app. The OS provides the runtime — sensors, storage, networking, permissions. Apps provide the context. alaivOS Business works identically: the backbone is the OS, branches are first-party applications, and marketplace capsules are the third-party ecosystem.
The Four Universal Dimensions¶
Every entity, event, and transaction in any business maps to one of four dimensions. These are the schema of the universal data model — the organizing principle the AI uses to answer any business question across any sector.
| Dimension | What it contains | Logistics view | Construction view | Healthcare view |
|---|---|---|---|---|
| Capital | Invoices, payments, payroll, budgets, tax, P&L | Fuel costs, carrier payments, customs duties | Contractor payments, phase budgets, retention | Billing, insurance claims, procurement |
| Time | Schedules, deadlines, appointments, SLAs, milestones | Pickup/delivery windows, transit ETAs, driver shifts | Project phases, permit deadlines, inspection slots | Appointment slots, treatment schedules, compliance dates |
| Flow | Communications, approvals, alerts, escalations | Driver check-ins, client notifications, dispatch orders | Site progress reports, RFI threads, subcontractor updates | Patient comms, referral routing, prescription approvals |
| Vault | Documents, contracts, certificates, policies, SOPs | Manifests, customs docs, carrier agreements | Blueprints, permits, inspection reports, BIM models | Medical records, consent forms, COFEPRIS certificates |
When the AI is asked "what's our cash exposure if the delayed shipments on the Veracruz lane slip another week?" — it reads Time (delay data) + Capital (outstanding receivables + carrier payables) simultaneously. No sector-specific code required. The four dimensions contain everything every business needs to know.
Working labels. The four dimension names — Capital, Time, Flow, Vault — are working labels. They become the public API contract in capsule manifests when the developer program opens, and cannot be changed after that. They must be locked before the developer program launches. (See OQ-1 in
BIZ-PLATFORM-MASTER-REF.md.)
What a Branch Is¶
A branch is not a separate product. It is a configuration profile applied on top of the backbone at onboarding. One question — the Industry Tag — is the seed that configures the entire initial state: which Odoo modules are foregrounded, what vocabulary the AI uses, what domain knowledge it carries, and which capsules are recommended.
Three layers define a branch:
Layer 1 — Persona Skin. The seven backbone AI Personas receive domain-specific names, vocabulary, RAG corpora, and confidence thresholds. The reasoning engine, privacy layer, and approval gates are inherited unchanged.
Layer 2 — Odoo Surface. The same Odoo module set is installed for every client. What changes is which modules are foregrounded in the dashboard — Fleet + Inventory for logistics, Project + Timesheets for construction, CRM for a generic SME. A client who later expands into a second sector does not need a new instance — they activate an additional surface.
Layer 3 — Capsule Defaults. At onboarding, the system recommends the curated capsule bundle for that branch. One-tap install. The client's instance is fully configured for their sector without any manual setup.
What a Capsule Is¶
A capsule is the atomic unit of extension. It adds depth within one or more of the four dimensions without touching the backbone. A capsule contains: a Persona delta (system prompt extension, RAG additions, new tools), an Odoo extension (custom fields, views, automated actions), workflow additions (n8n), and anonymization rule additions.
Capsules cannot modify backbone behavior — only extend it. This protects platform stability and makes third-party capsules safe to install.
The capsule marketplace is the ecosystem play. Citerius builds the first-party capsules for each branch. Third-party developers build the long tail. Revenue split: 80% developer / 20% Citerius. First 50 developers: 90/10 for 12 months — intentionally developer-generous to build early ecosystem momentum.
The Deployment Model¶
Two deployment modes exist. Both use the same backbone. The choice is a product contract, not a technical preference.
Mode A — Private Instance. Citerius provisions a dedicated VPS per client. The client's data is fully isolated. No external parties transact. Citerius is an infrastructure provider. Stack: Odoo + n8n + Google ADK + Nextcloud. This is the right model for SMEs who want a private back-office OS — a law firm, a retail chain, a healthcare clinic.
Mode B — Platform SaaS. Citerius owns and operates the platform. Multiple external parties are tenants. Citerius is the marketplace operator, AML policy holder, and escrow liability holder. Stack: Firebase + Cloud Functions + Flutter. This is the right model for any sector where multiple unaffiliated parties need to transact on the same platform under a trusted neutral operator — logistics, construction, agriculture.
The rule: whenever a sector requires multiple parties with simultaneous legal claims on the same event (a cargo handoff disputed by carrier, driver, and client simultaneously; a construction phase disputed by GC, subcontractor, inspector, and municipality), the Firestore append-only ledger and the blockchain anchor trail are the only technically honest answer. Mode B exists for those sectors.
The Competitive Moat¶
The moat is not the features. Any individual feature — KYC, cargo photo verification, Carta Porte generation — can be replicated. The moat is the combination:
Trust infrastructure as a platform. Every transaction on the platform is cryptographically auditable. The cargo handoff is biometrically confirmed, photo-verified against CV models, CFDI-documented, and blockchain-anchored. The construction phase completion is BIM-compared via autonomous drone, deviation-scored, and on-chain. A competitor building this for one sector takes years. Citerius builds it once and deploys it across all sectors.
Network effects per branch. In Mode B, every carrier and every shipper on Tractus makes the platform more valuable for the next carrier and shipper. Trust Scores are meaningful because they accumulate over real transactions. The marketplace discovery auction works better with more verified providers. This is a marketplace network effect on top of a SaaS subscription model.
Switching cost depth. A client on the platform has their Trust Score history, their audit trail, their compliance records, their BIM models, their contract history — all in one place. Switching means losing all of that. The longer they stay, the deeper the moat.
Cross-sector AI. A client who operates both logistics and construction on the same platform gets AI that can reason across both operations simultaneously — cash exposure across all business lines, staff utilization across projects and routes, seasonal patterns across the whole entity. No siloed system can do this.
Branch Roadmap¶
Live / Architecture Complete¶
| Branch | Brand | Mode | Market |
|---|---|---|---|
| Logistics — Longhaul | Tractus | B | MX-US cross-border freight. Carriers, shippers, customs brokers. Partner-led sub-branch. |
| Logistics — Lastmile | Tractus | B | Urban last-mile delivery, MX metropolitan areas. ampm is reference implementation. 217K+ deliveries/day scale validated. |
| Construction | Construx | B | MX construction. GCs, subcontractors, project owners, inspectors. |
Planned — Mode A (Private Instance)¶
These branches follow the standard Mode A pattern: Odoo + n8n + Google ADK + Nextcloud, per-client VPS, one Industry Tag configures everything.
| Branch | Target Client | Key First-Party Capsules |
|---|---|---|
| Generic SME | Any 1–50 employee business | CRM automation, invoice reconciliation, document vault |
| Retail / Distribution | MX retail chains, distributors | POS reconciliation, supplier reorder automation, DIOT tax report generator, returns & warranty handler |
| Legal Firm | Law firms | Matter & deadline tracker, client billing by hour, court filing calendar, contract clause library, conflict-of-interest screener |
| Healthcare Admin | Clinics, private practices | Patient appointment flow, IMSS/insurance billing, prescription renewal tracker, COFEPRIS compliance guard |
Planned — Mode B (Platform SaaS)¶
These branches require Mode B because multiple unaffiliated parties transact on the same events.
| Branch | Target Market | Core Platform Function |
|---|---|---|
| Healthcare Marketplace | MX/LATAM | Appointment booking marketplace — patient posts request, verified providers bid or accept. Insurance pre-authorization as regulatory-clearance equivalent. Medical record vault as bim-data-vault equivalent. |
| Agricultural / Harvest Logistics | MX/LATAM agro | Harvest hauling marketplace — producer posts harvest, hauler bids. Produce quality inspection as evidence-audit equivalent. Cold chain documentation as regulatory-clearance equivalent. |
| Legal Marketplace | MX/LATAM | Matter marketplace — client posts legal matter, qualified attorneys bid. Court filing documentation as regulatory-clearance equivalent. Conflict screening as entity-verification equivalent. |
The Capsule Cross-Sell Opportunity¶
Every capsule built for one branch is available to every other branch via the marketplace. The Field Worker Safety capsule (built for Tractus drivers) is immediately useful for Construx site workers, agricultural field teams, and healthcare home visit nurses. The Entity Reputation capsule (Trust Score) works identically for carriers, subcontractors, attorneys, and providers. The Marketplace Discovery capsule works for any two-sided market.
This creates a passive revenue stream from capsule licensing that did not exist in any single-branch model. It also means the first branches (Tractus, Construx) are building the platform's capsule inventory for every branch that follows.
The Drone Inspection System (Construx)¶
The autonomous drone inspection is worth calling out separately because it represents the most significant product innovation in the Construx branch — and the model it establishes will likely extend to other branches.
The problem it solves: construction phase completion currently requires the subcontractor being inspected to control the inspection camera. This is the primary manipulation vector. The drone removes it entirely — the platform controls the camera, not the party being evaluated.
The DJI Avata 360 generates 360° video of a completed phase. The system automatically generates the flight path from the BIM model (no human planning required). The drone flies the programmatic route. The video is reconstructed into a 3D point cloud via photogrammetry. That point cloud is compared against the BIM reference model element-by-element. Deviations are detected, categorized by severity, and presented to the Risk Agent with keyframe evidence attached.
The subcontractor does not control any part of this process. The GC/Owner does not need to be physically present. The inspection record is append-only, blockchain-anchored, and court-admissible.
This is not a feature that can be bolted onto an existing construction management platform. It requires the full stack: BIM vault, spatial comparison engine, drone mission software, video ingestion pipeline, CV model, append-only audit trail, and blockchain anchoring. It only makes sense as a platform capability, not a standalone tool.
The Blockchain Layer¶
Every material event in every Mode B marketplace transaction is anchored to the Polygon blockchain asynchronously. The anchor trail is not the primary operational record — Firestore is. The blockchain is the neutrality layer: neither party nor Citerius can modify an anchored record.
In practice, most disputes resolve when Risk Ops retrieves the anchor trail for a contractId — the contested facts are already proven by the chain of immutable hashes. The dispute resolution flow rarely needs to proceed past step 3.
The total gas cost per completed transaction (all anchored events) is approximately $0.011 USD. At 1,000 transactions per month: $11. Immaterial at any realistic revenue level.
The Platform Intelligence Layer¶
The most powerful long-term capability is what becomes possible when multiple clients operate on the same platform with consent to anonymized aggregation.
Within a single client instance, the AI can already reason across all four dimensions simultaneously — "what's our cash exposure if these three delayed shipments slip another week?" reads Time + Capital in one query, without any sector-specific code.
Dual data layer (operational + analytics): Firestore is the operational ledger — legal source of truth, append-only, tamper-evident. PostgreSQL/DuckDB is the analytics layer — KPI computation, LLM briefing payloads, anomaly detection. Firestore feeds the columnar store via nightly batch. This distinction is architectural, not optional: Firestore cannot efficiently aggregate 217K daily documents into a weekly ratio; DuckDB can in under a second.
The revenue manipulation monitor sits on the analytics layer and is independent of the server-timestamp hard cutoff. It watches the ingresos_devengados / envíos_entregados ratio week-over-week. A spike above 8% without corresponding volume growth flags a potential manipulation event — through any remaining path the timestamp cutoff doesn't cover. The monitor writes to an append-only revenue_anomalies collection and blocks period close until a human clears it.
The morning briefing is the daily intelligence surface: analyst-agent generates a 300-word WhatsApp message at 6:30 AM MX time covering yesterday's delivery performance, revenue recognized vs. plan, COD float position, SLA performance vs. MELI/Amazon contracts, and any anomaly that requires a decision today. This template is canonical for all lastmile deployments — not operator-specific.
Phase 2 — first-attempt failure prediction: XGBoost on tabular features (stops per route, COD ratio, historical colonia completion rates, courier experience, weather proxy, recipient WhatsApp response). Accuracy trajectory: 70–80% at launch → 88–95% at month 18. Dispatch Optimizer reads failure probability per stop; stops above 0.7 threshold trigger automatic recipient pre-contact. Industry benchmark: 12–18% reduction in failed delivery rate from this single intervention.
At platform scale, with anonymized opt-in aggregation, the intelligence compounds:
- Average days-to-pay benchmarks by sector — how does your AR compare to other MX logistics operators?
- Common approval bottlenecks by company size — where do similarly-sized firms lose the most time?
- Seasonal cash flow patterns — AI proactively flags upcoming pressure periods
- Capsule adoption patterns — which capsule combinations correlate with fastest time-to-value?
This is the "network intelligence" moat. A single-client system can only learn from that client. A platform learns from every client (with consent) and makes each individual client smarter for it.
The Last-Mile Opportunity¶
Last-mile delivery is the most operationally complex logistics sub-sector and the least well-served by existing software. It is also the fastest-growing segment in MX/LATAM driven by e-commerce growth (MELI, Amazon) and new entrants (Temu, Shein entering MX market).
The Tractus logistics.lastmile sub-branch addresses this directly. It shares the entire capsule stack with longhaul but operates under fundamentally different financial logic:
Revenue model: A last-mile operator like ampm does not have shipments sitting in escrow — they deliver under long-term contracts with MELI and Amazon at negotiated per-delivery rates. Revenue is recognized when the delivery is confirmed (ePOD). Clients are invoiced monthly. The platform enforces an accounting hard cutoff using the Firestore server timestamp on the ePOD event — making manual backdating architecturally impossible.
COD as treasury: At 217,000 daily deliveries averaging MXN 200 COD, a mid-size last-mile operator carries MXN 43M+ in daily float. This is not a payment feature — it is treasury management. The cod-treasury capsule reconciles every driver's shift, auto-matches SPEI/CoDi deposits to shipments, surfaces the real-time float position by hub, and triggers an overnight investment recommendation. The CFO gets a WhatsApp alert with tomorrow's expected float before the market opens.
Order ingestion: Contracted lastmile clients don't post requests to a marketplace — they push orders via webhook (MELI, Amazon). The carrier-integration capsule handles inbound webhook authentication, payload normalization, and dispatch trigger for each platform. This is the day-1 critical path, not Phase 2.
Phase 2 — opening the marketplace: Once a lastmile operator has built out their verified driver network and established Trust Scores, spare capacity becomes an asset. The marketplace-discovery capsule activates in Phase 2, enabling the operator to open that capacity to third-party shippers — the Temu and Shein wave entering MX is the target market. The Trust Score infrastructure built during Phase 1 makes the marketplace credible from day one.
ampm as the Proving Ground¶
ampm (Guadalajara, MX) validated the lastmile architecture through a real-world implementation analysis. The platform gaps it revealed — ePOD revenue recognition, COD treasury, external order ingestion, density routing — became locked architectural decisions. The platform builds for ampm's scale from day one, which means it is immediately viable for any operator from 10K to 500K daily deliveries without re-architecture.
The investor narrative this creates: Tractus is not a logistics app. It is a trust and settlement infrastructure for logistics operators. Longhaul gives you cross-border corridor integrity. Lastmile gives you urban delivery financial controls at scale. Both on the same platform, same capsule stack, same AI agent framework.
What We Are Not Building¶
A separate product for each sector. The entire architecture exists to avoid this. If a new sector requires a code fork, the architecture has failed.
An ERP replacement. Odoo is the persistence engine, not the product. alaivOS Business is the intelligence layer and the trust infrastructure. The AI does not replace Odoo — it makes Odoo usable without an implementation consultant and a six-month project.
A logistics app that happens to have other features. Tractus is the first branch, not the product. The platform is the product. Every branch that follows validates the architecture and amortizes the backbone cost.
A competitor to the construction software market. Procore, Buildertrend, and their peers are project management tools. Construx is a trust and payment settlement layer — the infrastructure that sits under project management, not alongside it.
The Vision in One Sentence¶
One operating system for every business — backed by trust infrastructure that makes every transaction auditable, every payment honest, and every sector smarter for being on the same platform.