ArchitectureJorvis Data Sources Strategy

Jorvis Data Sources Strategy

Jorvis Data Sources Strategy

Version: 3.1 Updated: 2026-03-13 Status: Post-wave planning strategy after the shipped data-surface expansion Canonical implementation truth: docs/architecture/DATA_SOURCES_IMPLEMENTATION_STATUS.md

Purpose

This document is the planning companion to the implementation-status inventory.

Use it to answer:

  • what Jorvis should build next,
  • what should not be reopened automatically,
  • and which future slices need fresh Stage 0 justification instead of inherited March 12 momentum.

Do not use this document to claim current support. Current support truth lives in DATA_SOURCES_IMPLEMENTATION_STATUS.md.

Historical March 12 kickoff packets remain useful as evidence of the prior expansion wave, but they are no longer the live execution plan:

  • docs/agent_ops/OUTBOX/task_data_surface_parallel_lane_kickoff_packets_20260312.md

Current Planning Reality

The original six-lane data-surface wave is no longer future work.

It has already been consumed as follows:

  1. PostgreSQL first-class provider — shipped
  2. Google Docs / Drive read-only ingestion — shipped
  3. JSON + HTML first-class processors — shipped
  4. PPTX ingestion — shipped
  5. MySQL first-class provider — shipped
  6. Gemini Embedding 2 — merged as bounded research only, not adoption

That means the right planning question is no longer:

“Which of Lanes 1–6 should we launch first?”

The right planning question is now:

“What, if anything, deserves a fresh Stage 0 after the shipped expansion wave?”

Strategic Principle After The Shipped Wave

Do not reopen completed lanes just because their March 12 planning docs still exist.

The next move should be a fresh, bounded slice only if all of these are true:

  1. there is a concrete product or operator need now,
  2. the capability is not already shipped in bounded form,
  3. the work can be isolated without widening into unrelated platform churn,
  4. the lane does not silently override current architectural decisions:
    • OpenClaw deeper integration is deferred
    • Gemini Embedding 2 adoption is not approved

What Is Explicitly Not The Next Automatic Step

1. Reopening shipped data-surface lanes

Do not re-plan or “re-launch”:

  • PostgreSQL
  • Google Docs / Drive read-only
  • JSON / HTML processors
  • PPTX
  • MySQL

Those lanes are already shipped. Any future work there should be framed as hardening, enablement, or a new bounded follow-up, not as the original lane.

2. Treating Gemini as an adoption lane

Merged Gemini work proves bounded feasibility and eval scaffolding only.

Do not infer:

  • baseline switch,
  • routing change,
  • storage/schema change,
  • or production adoption

from the merged spike/harness.

The only acceptable next Gemini artifact remains:

  • docs/agent_ops/specs/task_gemini_embedding2_live_eval_stage0_spec.md

3. Treating OpenClaw v2026.3.12 as implicit integration GO

The bounded OpenClaw upgrade is not authorization for:

  • sessions_yield
  • pending-work integration
  • workspace-plugin trust rollout
  • memory/search widening
  • bridge/admin-copilot expansion

Those remain separately deferred by:

  • docs/architecture/adr/ADR-0029-openclaw-operator-trust-and-deferred-integration-boundaries.md

Remaining Strategic Options

These are the realistic post-wave options. None are automatically active.

Option A — Hardening shipped surfaces only when evidence justifies it

Examples:

  • upload-path enablement/hardening
  • auth/docs hardening for Google Docs / Drive
  • parser quality or regression follow-ups for JSON / HTML / PPTX
  • connector ergonomics or docs improvements for PostgreSQL / MySQL

Use this only when there is a concrete prod, tester, or operator signal.

Option B — New bounded connector/document slice with fresh Stage 0

Reasonable candidates if a real need appears:

  • Google Slides read-only ingestion
  • structured CSV parsing
  • SQL Server / Oracle / SQLite

These should not inherit automatic priority from the March 12 sequence.

Option C — Gemini live eval only

This is the only currently approved Gemini follow-up shape.

Goal:

  • gather live evidence,
  • verify the current official candidate model identifier,
  • measure quality / latency / cost,
  • decide whether the result is:
    • KEEP_RESEARCH_ONLY
    • EVAL_MORE
    • or RECOMMEND_SEPARATE_ADOPTION_DISCUSSION

This is an evidence lane, not an adoption lane.

Option D — No new data-surface lane right now

This is a valid strategic choice.

The shipped wave already materially changed Jorvis:

  • stronger SQL breadth,
  • broader enterprise document ingestion,
  • broader processor coverage,
  • and retained architectural boundedness.

If there is no strong new product pull, a clean pause is better than artificial connector sprawl.

Decision Rules

Choose a hardening lane when:

  • a shipped surface has a concrete prod, tester, or operator problem
  • the fix is bounded and does not create a new roadmap promise

Choose a new connector/document Stage 0 when:

  • there is a specific customer/demo/product need,
  • the current shipped set is genuinely insufficient,
  • and the slice can stay bounded

Choose Gemini live eval only when:

  • leadership wants evidence on whether Gemini Embedding 2 is worth revisiting,
  • but there is still no adoption approval

Choose “do nothing new” when:

  • there is no strong new product pull,
  • or the next available ideas would mostly create platform churn instead of leverage

Now

  • keep shipped data-surface lanes closed
  • keep OpenClaw deeper integration deferred
  • keep Gemini adoption unapproved

Next

Pick one of these only if there is a concrete driver:

  1. Gemini live-eval-only Stage 0
  2. one bounded hardening lane on a shipped surface
  3. one fresh connector/document Stage 0 with explicit product justification

Later

  • any future Gemini adoption discussion, but only after live eval evidence
  • any future OpenClaw deeper-integration planning, but only after policy-first prerequisites
  • any broader connector sprawl, but only if there is real demand and spare execution bandwidth

Bottom Line

The March 12 expansion strategy succeeded.

The right strategy now is not to keep replaying that wave. It is to:

  1. recognize that Lanes 1–5 are already shipped,
  2. keep Lane 6 explicitly research-only,
  3. require fresh Stage 0 and fresh GO for any new expansion lane,
  4. prioritize evidence and boundedness over connector sprawl.