Bodi + Estym8 Integration: How They Can Work Together

Product context: Estym8 is built from scratch as an AI-first construction preconstruction platform—not a legacy takeoff stack with AI bolted on. AI runs across the product: bid-package ingestion and classification, multi-model takeoff and vision, plan intelligence, cross-file synthesis, Estee, estimate-to-submittal draft review, and optimization recommendations. Canonical framing: AI-first positioning.

Last updated: May 2026.

Summary: Bodi (project brain for ICT/Low Voltage → BOD) and Estym8 (AI-powered multi-trade plan-set takeoff + plan intelligence + estimate-to-submittal documentation, MEP-strongest today) are both AI-first, construction-adjacent products. They share domain overlap (electrical / low voltage), complementary data shapes (Estym8 outputs structured intelligence; Bodi consumes sources and claims to build deliverables). This doc analyzes Bodi and proposes concrete integration options.

Portfolio context: Bodi is the secondary accompanying product in the same company as Estym8—not a duplicate takeoff SKU. Estym8 remains the primary GTM focus for whole drawing sets and bid-folder preconstruction; Bodi addresses ICT / low-voltage BOD workflows and deepens the story on pursuits that need both multi-trade plan intelligence and traceable LV scope. Near-term integration is intentionally one-way friendly (Estym8 → Bodi as source/claims); full bundling and pricing are roadmap decisions.

Investor entry point: Investor overview — how v1/v2, revenue framing, and Bodi fit together.

Write paths & two-way sync (engineering): Bodi ↔ Estym8 write boundary — system-of-record rules before deeper integration.

Estimate-to-submittal vs BOD: Estym8’s submittal packages (catalog → register / compliance matrix / merged PDF / draft spec AI) are GC bid-documentation and product-compliance artifacts tied to estimate line items. Bodi’s BOD is the ICT/LV basis-of-design narrative built from sources → claims. They solve different deliverables on the same pursuit; one-way export of plan intelligence (concerns, RFIs, scope summaries) from Estym8 into Bodi still makes sense—do not conflate submittal PDF merges with Bodi claim graphs.

---

1. What each product does

Overlap: Electrical and low-voltage scope often live in the same job. Estym8’s “plan intelligence” (concerns, RFIs, recommendations) is exactly the kind of structured fact Bodi models as claims and uses to build BOD sections (requirements, constraints, scope in/out).

---

2. Integration ideas (high level)

1. Estym8 → Bodi as Source
   Push an Estym8 estimate (or its summary + concerns + RFIs) into Bodi as one Source. Bodi then runs (or will run) extraction to turn that content into Claims, which feed the BOD.

2. Estym8 → Bodi as Claims directly
   Map Estym8 outputs to Bodi’s claim types and POST claims into Bodi, with a single “Estym8 plan analysis” source for traceability. No extraction step.

3. Shared project identity
   Link the same job across both tools (e.g. by project number or client + name) so “sync from Estym8” or “add Estym8 to this Bodi project” is one click or API call.

4. BOD pre-filled from plan intelligence
   For jobs that have both MEP and ICT/LV, the BOD’s “Scope (Electrical/LV)” or “Constraints from plan review” can be seeded from Estym8’s concerns and RFIs.

5. Bodi → Estym8 (optional)
   Bodi’s client standards or drawing notes could be sent to Estym8 as context (e.g. for Estee or for future “client standard–aware” takeoff). Lower priority.

---

3. Data mapping: Estym8 → Bodi

3.1 Estym8 payloads you can use

• Estimate detail (e.g. GET /api/estimates/[estimateId]):
  rawOutput (or a dedicated “export for Bodi” payload) contains:

  • concernsList: { severity, issue, location, recommendation, proposedBuffer, riskNote }[]
  • rfiSuggestions: { title, question, background, referenceSheets?, recommendedPriority? }[]
  • summary: e.g. { totalMaterialCost?, recommendations?: string[], ... }
  • thingsToBeAwareOf: codes, weather, location notes

• Project (e.g. GET /api/projects/[projectId]):
  planMetadata holds plan-level rfiSuggestions and optionally thingsToBeAwareOf; latest estimate’s concerns can be derived from the latest completed estimate’s rawOutput.concernsList.

3.2 Bodi’s ingestion points

• Sources:
  POST /api/projects/[id]/sources
  Body (JSON): kind, external_id, title, content (string).
  Source kinds today: email | meeting_transcript | drawing_notes | client_standard | schedule.
  For Estym8 you can add a new kind (e.g. estym8_estimate) or reuse drawing_notes and put structured text/JSON in content.

• Claims:
  POST /api/projects/[id]/claims
  Body: { claims: [ { type, discipline?, summary, snippet, source_ids } ] }.
  Claim types: requirement | constraint | assumption | decision | standard_ref | scope_in | scope_out.
  Disciplines: security | av | low_voltage | isp | wifi.
  Estym8 doesn’t have “discipline” in the same way; map electrical → low_voltage (or extend Bodi later).

3.3 Suggested mapping: Estym8 → Bodi claims

Use one Source per Estym8 run (e.g. “Estym8 plan analysis – Project X – 2025-03-03”) with content = markdown or JSON of the full export. Then create claims that reference that source’s id in source_ids, so BOD has traceability (“Per Estym8 plan analysis…”).

---

4. Implementation options

Option A: Estym8 as a Source only (minimal Bodi change)

1. Estym8: Add an “Export for Bodi” (or “Export for project brain”) that produces a single markdown or JSON document: concerns, RFIs, summary recommendations, scope one-liner, thingsToBeAwareOf.
2. Bodi: User (or a script) uploads that file to a Bodi project via POST /api/projects/[id]/sources with kind: "drawing_notes" (or new estym8_estimate), title = e.g. “Estym8 plan analysis – [Project name]”, content = export text.
3. Bodi: When Bodi has LLM or rule-based extraction, that source is processed like any other; extracted claims get type/discipline and source_ids.

Pros: No Bodi schema change if you use drawing_notes; Estym8 stays the only place that knows about “Bodi format.”
Cons: Extraction step may duplicate structure you already have in Estym8.

Option B: Estym8 pushes Claims into Bodi (richer, traceable)

1. Estym8: New server action or API (e.g. “Sync to Bodi”) that:

   • Calls Bodi POST /api/projects/[id]/sources with one source (e.g. kind estym8_estimate, content = full export).
   • Maps concernsList, rfiSuggestions, summary.recommendations, scope to Bodi claim shapes.
   • Calls Bodi POST /api/projects/[id]/claims with claims[] and source_ids = [ that source’s id ].

2. Bodi: Add estym8_estimate to SourceKind and accept the new source type; no other change required. BOD view already groups by type and discipline.

3. Linking: User selects “Bodi project” (by id or name) in Estym8, or Estym8 stores a bodi_project_id per Estym8 project; “Sync to Bodi” uses that.

Pros: BOD is pre-filled with plan intelligence; one click from Estym8.
Cons: Requires Estym8 to call Bodi API (auth, CORS, base URL config).

Option C: Bodi pulls from Estym8 (Bodi-led)

1. Estym8: Expose a “Bodi-friendly” endpoint, e.g. GET /api/estimates/[id]/bodi-export (or project-level) that returns a single JSON: { source_content: string, suggested_claims: Array<{ type, discipline?, summary, snippet }> }. Estym8 does the mapping; Bodi only persists.
2. Bodi: “Import from Estym8” in UI: user pastes estimate ID (or project ID) and Estym8 API base URL + token; Bodi calls Estym8, creates one source from source_content, then POSTs suggested_claims with that source’s id.

Pros: Bodi owns the integration; Estym8 stays a “data provider.”
Cons: Estym8 must expose a public or partner API and auth (e.g. API key or OAuth).

---

5. Recommended path (short term)

• Quick win: Option A is implemented: add “Export for Bodi” (markdown or JSON) on project and/or estimate detail. Document the format and how to add it as a Bodi source. No Bodi code change if you use drawing_notes.
• Next: In Bodi, add SourceKind estym8_estimate and (optional) a small “Import from Estym8” flow that accepts either file upload or Estym8 project/estimate id + credentials and creates the source (and optionally claims) via Option B or C.

---

6. Auth and deployment

• Estym8 → Bodi: Bodi would need an API key or service-to-service auth for POST /api/projects/[id]/sources and POST /api/projects/[id]/claims (e.g. internal API key in env).
• Bodi → Estym8: Estym8 would need a partner or API key auth for GET /api/estimates/[id] (or a dedicated Bodi-export route).
• Same user, both products: Optional later: same login (e.g. OAuth or shared session) and a unified “Projects” view that shows Bodi projects and Estym8 projects, with “Link to Bodi” / “Import from Estym8” actions.

---

7. Bodi code references (for implementation)

• Source ingest: lib/project-brain/ingest.ts — ingestSource({ project_id, kind, external_id, title, content }).
• Claims persist: lib/project-brain/extract.ts — persistClaims(projectId, claims); claims have type, discipline, summary, snippet, source_ids.
• Source kinds: lib/schema-types.ts — SourceKind; validated in app/api/projects/[id]/sources/route.ts via VALID_KINDS.
• BOD view: lib/project-brain/bod-view.ts — builds BOD from claims grouped by type and discipline; no change needed if claims are present.

---

8. Summary table

Both products are AI-first and construction-adjacent; Estym8’s plan intelligence is a natural source of structured claims for Bodi’s BOD. Starting with an export format and one-way flow (Estym8 → Bodi) keeps scope small and delivers immediate value (BOD sections pre-filled from plan analysis). Two-way linking and Bodi → Estym8 context can follow once the first flow is in use.