FleetOS BIBLE - Gap Analysis & Mapping

Date: 2026-01-09 Phase: INGEST + MAP Complete Status: Awaiting PLAN approval

---

📋 Summary

Overall Assessment: ~75% aligned with BIBLE architecture Critical Gaps: 2 (database schema + RFQ routing) Minor Gaps: 3 (contacts, event logging, notification fallback)

---

✅ What FULLY Matches BIBLE Spec

1. Daily Access Flow ✅

Location: CleanLanding.tsx + AuthService.sendDailyAccessLink()

What exists:

• User goes to fleetos.com

• Clicks "Login" button → shows daily access form

• Enters work email

• Receives org-level magic link

• No login, no accounts, no remembering old links

Evidence:

// CleanLanding.tsx Line 40
const handleDailyAccessSubmit = async (e: React.FormEvent) => {
  const result = await AuthService.sendDailyAccessLink(dailyAccessEmail);
  // Sends org-scoped magic link
};

// AuthService.ts Line 179
async sendDailyAccessLink(email: string) {
  const domain = extractDomain(email);
  const { data: company } = await supabase
    .from('companies')
    .select('company_id, company_name')
    .eq('domain', domain)
    .single();

  // Generate org-scoped token with companyId
  const token = MagicLinkService.encodeToken({
    email,
    companyId: company.company_id,
    accessType: 'org_daily_access',
  });
}

BIBLE Compliance: ✅ Perfect match

---

2. Magic Links = Capabilities ✅

Location: services/shared/MagicLinkService.ts

What exists:

• Time-bound (exp timestamp)

• Scope-bound (companyId, rfqId)

• Org-bound (companyId in payload)

• NOT user accounts

Evidence:

export interface MagicLinkPayload {
  email?: string;
  companyId?: string;     // ✅ Org-scoped
  rfqId?: string;         // ✅ RFQ-scoped
  exp?: number;           // ✅ Time-bound
  targetPath?: string;    // ✅ Capability-scoped
}

BIBLE Compliance: ✅ Perfect match

---

3. Org-First Concept ✅

Location: lib/domainExtraction.ts + AuthService.ts

What exists:

• extractDomain(email) → company domain

• getOrCreateCompany() → creates/finds org by domain

• Companies identified by DNS-unique domain

Evidence:

// Extract domain: "[e-mail]" → "t420.io"
const domain = extractDomain(email);

// Get or create company by domain
const { companyId } = await getOrCreateCompany(
  supabase,
  email,
  companyName,
  'supplier'
);

BIBLE Compliance: ✅ Perfect match

---

4. Emergency Access (Partial) ⚠️

Location: AuthService.sendDailyAccessLink()

What exists:

• Any org member can enter email

• Gets fresh org-level magic link

• No dependency on previous logins

Missing:

• "Last active org access point" fallback

• Org default channel

BIBLE Compliance: ⚠️ 80% - Core concept works, needs fallback logic

---

⚠️ What PARTIALLY Matches

5. RFQ Owned by Org (Database Issue) ❌

Location: database/core/schema.sql + database/fleetos/complete-setup.sql

Current Schema:

CREATE TABLE service_requests (
  request_id UUID PRIMARY KEY,
  fleet_user_id UUID,      -- ❌ Individual user, not org
  supplier_id UUID,         -- ❌ Individual user, not org
  ...
);

BIBLE Requires:

CREATE TABLE service_requests (
  request_id UUID PRIMARY KEY,
  fleet_company_id UUID,    -- ✅ Fleet Org
  supplier_company_id UUID, -- ✅ Supplier Org
  submitted_by_user_id UUID, -- ✅ Which team member acted (optional)
  ...
);

Impact: 🔴 CRITICAL

• RFQs currently owned by individual users

• Team members can't see each other's work

• Violates "Org-first" principle

Fix Required: Add company columns to service_requests table

---

6. RFQ Routing (Code Issue) ❌

Location: QueryService.createServiceRequest()

Current Code:

static async createServiceRequest(requestData: any) {
  const { data, error } = await supabase
    .from('service_requests')
    .insert({
      supplier_id: requestData.supplier_id,  // ❌ User ID
      fleet_id: requestData.fleet_user_id,   // ❌ User ID
      ...
    });
}

BIBLE Requires:

static async createServiceRequest(requestData: any) {
  // 1. Resolve Fleet Org (sender domain)
  const fleetCompanyId = resolveFleetOrg(requestData);

  // 2. Resolve Supplier Org (target)
  const supplierCompanyId = resolveSupplierOrg(requestData);

  // 3. Create TODO owned by Supplier Org
  await supabase.from('service_requests').insert({
    fleet_company_id: fleetCompanyId,      // ✅ Org
    supplier_company_id: supplierCompanyId, // ✅ Org
    submitted_by_user_id: requestData.submittedBy, // Optional
    status: 'new',
    ...
  });

  // 4. Log event
  await logEvent('rfq_created', { ... });
}

Impact: 🔴 CRITICAL

• RFQs not org-scoped

• Routing logic user-based

Fix Required: Update createServiceRequest() to resolve and use company IDs

---

7. Notification Routing (Missing Fallback) ⚠️

Location: services/NotificationService.ts

Current:

• Sends to specific email/phone

• No org-level fallback

BIBLE Requires:

If contact hint exists (phone suffix / alias):
    → send RFQ-scoped magic link to that contact
ELSE:
    → send org-level magic link to:
        - last active org access point, OR
        - org default channel

Impact: 🟡 MEDIUM

• RFQs might get "stuck" if contact unavailable

• No org-level fallback

Fix Required: Add org-level notification fallback logic

---

❌ What's MISSING

8. EventLog ❌

Location: None

BIBLE Requires:

• Table: event_log or similar

• Records every access + action

• Tracks who clicked magic links

• Tracks who updated RFQs

Current State: ❌ Does not exist

Impact: 🟡 MEDIUM

• No audit trail

• Can't track "last active org access point"

Fix Required: Create event logging system

---

9. Contacts Are Emergent (Philosophy) ⚠️

Location: MinimalSignup.tsx + App.tsx signup flows

Current:

• Signup creates user record

• Assumes "users" exist

BIBLE Says:

"FleetOS v1 does NOT have contact lists. Contacts are emergent, not pre-created. A 'contact' exists only when:

• someone clicks a magic link

• or receives a targeted notification"

Gap:

• Signup flow creates user upfront

• Not fully "emergent"

Impact: 🟢 LOW

• Works functionally

• Philosophical mismatch

Fix Required: Minimal - possibly just documentation

---

10. "assigned" Status ⚠️

Location: Database schema

Current Status Enum:

CHECK (status IN ('pending', 'confirmed', 'in_progress', 'completed', 'cancelled'))

BIBLE Flow:

new → acknowledged → in_progress → completed / declined

Gap:

• Different status names

• Missing 'acknowledged', 'declined'

• Has 'confirmed', 'cancelled' instead

Impact: 🟡 MEDIUM

• Status lifecycle doesn't match BIBLE

Fix Required: Update status enum to match BIBLE

---

📊 Compliance Matrix

BIBLE Requirement	Status	Files Affected
Org-first identity	✅ 90%	companies table exists, code uses it
Magic links = capabilities	✅ 100%	MagicLinkService.ts
Never block work	⚠️ 60%	Missing org fallback
Daily access flow	✅ 100%	CleanLanding.tsx, AuthService.ts
RFQs owned by Org	❌ 0%	service_requests schema
RFQ routing to Org	❌ 0%	QueryService.createServiceRequest
Notification fallback	❌ 0%	NotificationService.ts
EventLog	❌ 0%	Missing
Contacts emergent	⚠️ 70%	Philosophy vs reality
Status lifecycle	⚠️ 60%	Different status names

---

🎯 Critical Path to BIBLE Compliance

Priority 1: CRITICAL (Blocks BIBLE compliance)

1. ❌ Add company columns to service_requests

   • fleet_company_id UUID

   • supplier_company_id UUID

   • submitted_by_user_id UUID (optional)

2. ❌ Update RFQ routing logic

   • Resolve Fleet Org from sender

   • Resolve Supplier Org from target

   • Create RFQ owned by orgs, not users

Priority 2: HIGH (Violates "never block work")

1. ⚠️ Add org-level notification fallback

   • If contact hint exists → send to contact

   • Else → send to org default channel

   • Or → send to last active org member

2. ⚠️ Update status lifecycle

   • Change to: new → acknowledged → in_progress → completed/declined

   • Update all status references in code

Priority 3: MEDIUM (Nice to have, improves compliance)

1. ❌ Create EventLog system

   • Log all magic link clicks

   • Log all RFQ actions

   • Track "last active" per org

---

🚫 Documents That CONTRADICT BIBLE

Based on user request: "remove all other documents or change that contradict this architecture"

To Archive/Update:

1. DOMAIN_IDENTITY_ARCHITECTURE.md - Partially contradicts

   • Says companies table exists ✅

   • Says user_profiles table needed ❌ (BIBLE: no contact lists)

   • Action: Update to align with BIBLE

2. COMPANY_ARCHITECTURE_COMPLETE.md - Partially contradicts

   • Says migration ready ❌ (companies table exists but RFQ columns don't)

   • Says user_profiles needed ❌ (BIBLE: contacts emergent)

   • Action: Archive or update

3. FLEETOS_TESTING_GUIDE.md - May contradict

   • Testing assumes user-based flows ❌

   • Need to review against BIBLE

   • Action: Review and update

---

✅ One Sentence Test

"A tired operator in an emergency can remember FleetOS, go to the site, and immediately see today's work without knowing who was invited or logged in"

Current State: ⚠️ 70% Pass

• ✅ Can go to site

• ✅ Can enter email

• ✅ Gets magic link

• ❌ BUT: Won't see team's work (RFQs user-scoped, not org-scoped)

After Fixes: ✅ 100% Pass

• ✅ Will see ALL company work (RFQs org-scoped)

• ✅ Any team member can access

• ✅ No dependency on previous logins

---

🎬 Next Step

Status: MAP phase complete Next: Create PLAN document with:

• Minimal SQL migration

• Code changes (files + line numbers)

• Rollback strategy

• Testing checklist

Awaiting: Founder review and sign-off before proceeding to PLAN

---

Created: 2026-01-09 Phase: INGEST + MAP Complete Next Phase: PLAN (awaiting approval)