FIN Central

FIN Central / Tenant Demarcation Plan

19 min read

FIN Central / Tenant Demarcation Plan

Date: 2026-05-15 Status: Draft v0.1 (active planning, execution begins this week) Related: docs/FIN_PLATFORM_DOC_INDEX.md, docs/engineering/FIN_INTRANET_HUMAN_AGENT_PROJECTION_ENGINEERING_SPEC_2026-05-13.md, docs/architecture/FIN_MCP_SURFACE_ARCHITECTURE_2026-05-15.md, docs/product/FIN_PRODUCT_TIER_ARCHITECTURE_2026-05-15.md

0. Purpose

Today, FIN’s code (fin-agentic + knowledge-forge) and infrastructure (one Neon project + one Cloudflare deployment) are being used to test the Nathel tenant deployment. There is no clear separation between FIN Central (the platform operator) and Nathel (the first tenant). Some FIN-Central concerns — external scrapers, canonical Taproot curation, anonymization policy management — currently sit inside the same Neon DB and Cloudflare deployment that holds Nathel’s operational data.

This plan establishes the demarcation now, before more tenant-specific patterns ossify in shared assets. It defines the target architecture, the migration order, and the operational discipline going forward.

The discipline this plan codifies is also the demonstrable proof of FIN’s multi-tenant federated intelligence model.

1. Principles

  1. Code is shared; infrastructure is split. The fin-agentic and knowledge-forge repos remain single sources of truth. The Neon projects, Cloudflare deployments, and vault repositories are split per role.
  2. Configuration determines role. A deployment is “FIN Central” or “tenant” based on a deployment-time flag, not separate code.
  3. FIN Central is the control plane. External data ingestion, canonical Taproot curation, anonymization policy, public Tier 0 MCP, federal-mode admin, and platform observability live in FIN Central.
  4. Tenants are data planes. Tenant deployments process tenant operational data, fuse it with the FIN Central Taproot mirror, and generate tenant projections. Tenants do NOT run scrapers or curate canonical Plane 3 knowledge.
  5. Taproot flows one direction. FIN Central Taproot → Tenant Taproot mirror. Tenant additions stay tenant-local until promoted through review.
  6. Observability is layered. FIN Central observes the federation; tenants observe themselves.
  7. No tenant data ever lives in FIN Central infrastructure. The only data flowing from tenant to FIN Central is anonymized aggregate (for Harvest Directory), opt-in per tenant, gated by policy.

2. Parties

2.1 FIN Company Structure

  • Rob Garcia — FIN founder, 60% majority owner, operator
  • Joshua Gatcke — FIN partner (minority); also VP at Nathel & Nathel
  • Jacob Gatcke — FIN partner (minority); also GM at Nathel & Nathel

FIN is a VOSB (Veteran-Owned Small Business) certified entity. This status carries through to federal contracting eligibility, set-aside opportunities, and brand positioning for the federal pipeline.

2.2 Nathel & Nathel Structure

  • Ira Nathel — Owner & President, Nathel & Nathel; “produce industry sponsor” for FIN; not a FIN partner. Step-father to Josh and Jake.
  • Joshua Gatcke — VP, Nathel & Nathel; also a FIN partner
  • Jacob Gatcke — GM, Nathel & Nathel; also a FIN partner
  • Alex Cohen — Internal Technician at Nathel & Nathel; Rob’s liaison for the FIN pilot install; not a FIN partner

2.3 FIN Central Intranet Access (Initial)

  • Rob Garcia — full access (founder/operator)
  • Joshua Gatcke — full access (partner)
  • Jacob Gatcke — full access (partner)
  • Alex Cohen — scoped access to integration/pilot subdir only (Nathel technical liaison; needs visibility into the FIN↔Nathel integration work, not FIN strategic/partner content)
  • Ira Nathel — read-only visibility into the Nathel relationship subdir (sponsor view); not granted strategic FIN content access

2.4 Nathel Tenant Access

  • Ira Nathel — read-only executive view (sponsor + owner)
  • Joshua Gatcke — tenant admin (primary operational user)
  • Jacob Gatcke — tenant admin (primary operational user)
  • Alex Cohen — tenant admin (technical integration owner)
  • Nathel office staff — role-scoped as onboarded (receiver, dispatcher, office, etc.)

2.5 Dual-Role Discipline

Josh and Jake hold two roles each: FIN partner AND Nathel operator. Alex holds one role with two contexts: Nathel tenant admin AND scoped FIN Central viewer. Distinct identities per role/context:

  • Different email aliases per role (e.g., josh@fin.app for FIN partner work; josh@nnproduce.net for Nathel tenant work)
  • UI clearly indicates the current surface (“FIN Central — Partner View” vs “Nathel — Operator View”)
  • Audit logs distinguish context switches
  • Cross-surface data isolation enforced at the route layer

2.6 Strategic Note on VOSB + Founder Service Profile

FIN’s VOSB certification combined with Rob’s active service profile is a material federal-pipeline advantage that exceeds generic veteran-owned-business positioning. See docs/reference/FIN_FOUNDER_BIO_2026-05-15.md for the full record.

Active Air Force Reservist (current):

  • Rank: O-grade officer, commissioned 2023
  • AFSC: 21A (Aircraft Maintenance Officer)
  • Assignment: Seymour Johnson AFB, NC; 916th ARW / 916 MXS; KC-46
  • Role: Traditional Reservist Director of Operations / Flight Commander

Prior Active Duty (2007-2019):

  • 8.5 years as Nuclear Weapons Specialist (2W2) — safety-critical, audit-intensive, two-person integrity discipline directly analogous to FSMA traceability and federal-grade audit posture
  • 4 years as USAF Recruiter in NYC region with rapid promotion to Flight Chief and NY State Recruiting Service Trainer — operational leadership at scale

Federal Pipeline Advantages:

  • FAR 19.14 set-aside eligibility (VOSB confirmed)
  • USDA Specialty Crop Block veteran-track consideration
  • SBIR / STTR veteran-track scoring boost
  • DoD-adjacent credibility — current-serving officer, KC-46 platform, mission-critical asset experience
  • VA-adjacent credibility — military service record
  • Audit-discipline credibility — nuclear weapons handling background parallels federal food-safety audit posture

SDVOSB Consideration:

Service-Disabled Veteran-Owned Small Business (FAR 19.15) requires VA service-connected disability rating. Eligibility currently unconfirmed. Recommendation: counsel + VA evaluation to confirm or rule out. If SDVOSB is available, set-aside lanes expand significantly beyond plain VOSB.

Counsel Review Items (before federal lane goes active):

  1. Confirm VOSB certification is correctly registered in SAM.gov for all relevant NAICS codes
  2. Evaluate SDVOSB eligibility (VA disability evaluation)
  3. Ensure VOSB status is explicitly claimed in every federal solicitation response (benefits are not automatic)
  4. Map veteran-set-aside lanes for the specific agencies in FIN’s federal pipeline (USDA, FDA, CDC, DoD AAFES, VA, ARPA-H)
  5. Confirm Rob’s continued reservist status does not create conflicts for any pursued contracts (it generally does not, but specific solicitations may have requirements worth confirming)

3. Target Architecture

3.1 Control Plane vs Data Plane

┌─────────────────────────────────────────────────────────────────┐
│                    FIN CENTRAL (Control Plane)                  │
│  ─────────────────────────────────────────────────────────────  │
│  Neon: fin-central-prod                                         │
│  Cloudflare: central.fin.app (or fin.app)                       │
│  GitHub: fin-central-intranet (vault)                           │
│                                                                  │
│  Responsibilities:                                              │
│  • External scrapers (Plane 3 KB sources: USDA, FDA, GS1, etc.) │
│  • Canonical Taproot curation (commodities, varieties, regions,│
│    season_windows, certifications)                             │
│  • Anonymization policy management                              │
│  • Public Tier 0 MCP (api.harvestdirectory.org)                │
│  • Harvest Directory generation                                 │
│  • Federal-mode admin tools                                     │
│  • Tenant lifecycle / provisioning / billing                    │
│  • Cross-tenant observability (aggregated, anonymized)          │
│  • FIN's own operational data (partner comms, decisions,       │
│    fundraising, federal pipeline)                              │
│  • FIN Central intranet (Rob + Josh + Jake + Alex)             │
└─────────────────────────────────────────────────────────────────┘
                                 ▲
              Taproot sync API  │  Aggregate signal upload (opt-in)
                                 │
                                 ▼
┌─────────────────────────────────────────────────────────────────┐
│                    NATHEL TENANT (Data Plane)                   │
│  ─────────────────────────────────────────────────────────────  │
│  Neon: nathel-prod (current Neon project, renamed)             │
│  Cloudflare: nathel.fin.app (current Cloudflare, refocused)    │
│  GitHub: nathel-intranet (tenant vault)                        │
│                                                                  │
│  Responsibilities:                                              │
│  • Nathel operational data (events, lots, arrivals, QC, comms) │
│  • Nathel knowledge rows (customers, vendors, lot history)      │
│  • Nathel operational_memory (email/Teams extracts)            │
│  • Nathel actors and memory                                     │
│  • Nathel Taproot mirror (synced from FIN Central)              │
│  • Nathel-specific organizational data + Taproot overlays      │
│  • Nathel fusion projections (entity profiles, event digests,  │
│    daily arrivals, vendor scorecards, customer profiles, etc.) │
│  • Nathel customer portal + vendor portal                      │
│  • Nathel operator/ops agent sessions                           │
│  • Nathel intranet (Josh + Jake + Alex + Nathel staff)         │
│                                                                  │
│  Explicitly NOT in tenant:                                     │
│  ✗ External scrapers                                            │
│  ✗ Canonical Plane 3 curation (consume FIN Central instead)    │
│  ✗ Anonymization policy management                              │
│  ✗ Public Tier 0 endpoints                                      │
│  ✗ Cross-tenant data of any kind                                │
└─────────────────────────────────────────────────────────────────┘

3.2 The Two Taproot Layers

A core demarcation pattern. The Taproot exists in two forms with strict flow direction:

Central Taproot (lives in fin-central-prod Neon):

  • Canonical Plane 3 entity rows (commodity, variety, region, season_window, certification, grower-public, etc.)
  • Authored content from FIN team + external curators
  • Scraped data from USDA / FDA / GS1 / university extension / public sources
  • Anonymization-cleared aggregates from opted-in tenants (eventually)
  • Curated reference content (handling SOPs, classification rules, defect taxonomies)

Tenant Taproot Mirror + Overlays (lives in nathel-prod Neon):

  • Read-only mirror of Central Taproot (subset relevant to the tenant)
  • Synced periodically (hourly polling for now; webhook push later)
  • PLUS tenant-specific overlays:
    • Tenant’s own vendor profiles (Nathel-specific)
    • Tenant’s own customer profiles (Nathel-specific)
    • Tenant’s own grower profiles (Nathel-specific)
    • Tenant’s variety preferences, handling SOPs, pricing notes
    • Tenant operational annotations on Central entities

When a Nathel operator or agent queries commodity_profile.watermelon, the response is composed: Central Taproot data (canonical) + Nathel’s overlay annotations + Nathel’s tenant operational data (current lots, recent arrivals).

The fusion happens in the tenant’s projection layer. The Central Taproot mirror is the read-side. Nathel’s overlays are write-side (tenant-owned). Both are queryable as one entity profile from the tenant’s MCP.

3.3 Repository Strategy

Current repos remain. New repos are added for vaults only:

RepoPurposeOwner
fin-agentic (existing)Platform code; deploys to both Central and tenantFIN
knowledge-forge (existing)Central Taproot service + external scrapersFIN
fin-central-intranet (NEW)FIN Central vault content (Obsidian-format markdown)FIN
nathel-intranet (NEW)Nathel tenant vault contentFIN initially, transferable to Nathel org later
fin-tenant-templates (NEW, low priority)Tenant onboarding boilerplate / config templatesFIN

The same fin-agentic code deploys to both Central and Nathel. The DEPLOYMENT_ROLE env variable selects role at runtime. No code fork.

3.4 Infrastructure Strategy

Neon:

  • Current Neon project → renamed nathel-prod (this is the existing staging branch used for Nathel testing)
  • NEW Neon project: fin-central-prod
  • Future: each new tenant gets a dedicated Neon project (acme-prod, etc.)

Cloudflare:

  • Current deployment → refocused as Nathel tenant deployment at nathel.fin.app
  • NEW deployment: FIN Central at central.fin.app (Workers + R2 + Durable Objects + KV)
  • Future public Tier 0: api.harvestdirectory.org on its own deployment with stricter WAF

Secrets (AWS Secrets Manager):

  • Current secrets → tag/rename with fin-central vs tenant-nathel
  • Per-deployment AWS_SM_PATH so each deployment reads its own subtree

Telnyx:

  • Numbers tagged per-tenant. Nathel numbers remain on Nathel deployment. FIN Central uses a separate FIN-org-owned number for partner comms (or no telephony for v1; web-only is fine for the FIN Central intranet).

4. Code Demarcation (Within the Single fin-agentic Repo)

4.1 DEPLOYMENT_ROLE Flag

Add DEPLOYMENT_ROLE to env config:

  • central → Central deployment
  • tenant → Tenant deployment
  • public → Public Tier 0 deployment (Wave 3+)

The flag is read at Worker boot and gates feature activation.

4.2 Features Gated To Central

In packages/mcp-server/src/:

  • ingestion/external-scrapers/* → only active when role === central
  • ingestion/taproot-canonical-writer/* → only active when role === central
  • anonymization/policy-management/* → only active when role === central
  • tier-0/public-mcp/* → only active when role === central AND a separate public deployment (Wave 3)
  • federal/admin/* → only active when role === central AND federal add-on enabled
  • tenant-lifecycle/* → only active when role === central
  • harvest-directory/* → only active when role === central

4.3 Features Gated To Tenant

  • ingestion/email-arrivals/* → only active when role === tenant
  • ingestion/pp-extractors/* → only active when role === tenant
  • agents/operator/* → only active when role === tenant
  • projections/tenant-fusion/* → only active when role === tenant
  • portals/customer/* → only active when role === tenant
  • portals/vendor/* → only active when role === tenant

4.4 Shared (Both Roles)

  • Event store (events table)
  • Knowledge table (different domain values active per role)
  • Actors table
  • Operational memory
  • MCP tool catalog (different surface per role)
  • Auth (different IdP scope per role)
  • Agentic harness session model

4.5 Taproot Sync Adapter (NEW)

A new module gates Taproot data flow:

Central side (packages/mcp-server/src/taproot-central/):

  • Authoring API for canonical entity rows
  • Anonymization application
  • Outbound sync endpoint: GET /taproot/sync/changes?since=X&tenant_id=Y (returns Taproot updates for the requesting tenant)
  • Webhook fan-out (Wave 4): push instead of poll

Tenant side (packages/mcp-server/src/taproot-mirror/):

  • Scheduled poll of FIN Central’s sync endpoint
  • Upsert into tenant’s knowledge.domain = taproot_mirror_* rows
  • Conflict resolution: Central wins for Central-owned fields; tenant overlay wins for tenant-owned fields
  • Emit signal.taproot_synced event with version + changed entity count

4.6 Observability Demarcation

Central observability (Plane 3 + cross-tenant aggregate):

  • Federation health (how many tenants active, channel health per tenant, KB freshness)
  • Public Tier 0 traffic and abuse signals
  • Scraper health (external sources reachable, last successful pull)
  • Taproot canonical health (entity counts, embedding coverage, stale rows)
  • Anonymization policy version status

Tenant observability (Plane 1 + Plane 2):

  • Tenant operational throughput (events/day, agent sessions, channel activity)
  • Tenant projection freshness
  • Tenant customer/vendor portal usage
  • Tenant agent quality (gradeboard per tenant)
  • Tenant onboarding progress

The two observability surfaces share NO data. FIN Central can see counts per tenant for billing and federation health, but never content.

5. Migration Plan

Five phases, executable as time allows. Phase 1 unblocks the demarcation; the rest can follow over 2-4 weeks.

Phase 1 — Provisioning (Day 1, 2-4 hours)

Outcome: FIN Central infrastructure exists and is empty.

  • Provision new Neon project: fin-central-prod. Apply current schema. Empty data.
  • Provision new Cloudflare Worker deployment: central.fin.app. Configure Hyperdrive pointing at fin-central-prod.
  • Create new GitHub repos: fin-central-intranet, nathel-intranet. Set up branch protection.
  • Tag current Neon project as nathel-prod (rename in Neon console).
  • Tag current Cloudflare deployment with tenant-nathel namespace.
  • Update AWS Secrets Manager: create /fin/central/* and /fin/tenant/nathel/* subtrees.

Phase 2 — Code Demarcation (Days 2-3, 4-8 hours)

Outcome: A single fin-agentic build deploys correctly to either role.

  • Introduce DEPLOYMENT_ROLE env config; default to tenant for safety.
  • Gate scraper workers, Taproot canonical writers, anonymization policy module, Tier 0 routes, tenant-lifecycle module behind role === central.
  • Gate email-arrivals, PP-extractors, operator agent skill bundles, customer/vendor portals behind role === tenant.
  • Deploy fin-agentic to central.fin.app with role: central. Verify scrapers run there; no operator-agent runs there.
  • Re-deploy fin-agentic to nathel.fin.app with role: tenant. Verify scrapers do NOT run; operator agent + ingestion run as expected.

Phase 3 — Data Demarcation (Days 4-7, 6-12 hours)

Outcome: FIN Central data and Nathel data live in separate Neon projects with no cross-contamination.

  • Inventory current nathel-prod Neon contents:
    • Which knowledge.domain values are Central-owned (canonical Taproot, anonymization policies, scraped sources)?
    • Which are tenant-owned (customers, vendors, lots, etc.)?
  • Export Central-owned rows from nathel-prod. Import into fin-central-prod. Validate.
  • Confirm tenant-owned rows remain in nathel-prod. Delete Central-owned rows from nathel-prod (after Central-side import confirmed).
  • Knowledge-forge service: deploy to FIN Central deployment only. Its current data (694 entities, 17,588 rows) flows into fin-central-prod, NOT into nathel-prod.
  • Tenant side: tenant Taproot mirror starts empty. Phase 4 fills it.

Phase 4 — Taproot Sync (Days 5-10, 8-16 hours)

Outcome: Central Taproot → Nathel Taproot mirror works end-to-end.

  • Implement GET /taproot/sync/changes?since=X on Central deployment. Versioned response with entity_changes[], next_cursor.
  • Implement scheduled poll on Nathel deployment. Cron trigger every 1 hour initially. Configurable per tenant.
  • Implement tenant-side upsert into knowledge.domain = taproot_mirror_* rows.
  • Verify Nathel’s commodity_profile.watermelon query returns Central canonical data + Nathel overlay.
  • Add signal.taproot_synced events with stats.

Phase 5 — Vault Bootstrap (Days 6-12, 4-8 hours)

Outcome: FIN Central intranet and Nathel intranet exist as separate vaults with their own content.

  • Initialize fin-central-intranet repo with the doc folder structure from the Doc Index.
  • Move (or copy) canonical FIN-team docs into fin-central-intranet: partner comms, decisions, fundraising, federal pipeline, strategic research, patent filings.
  • Initialize nathel-intranet repo with the doc folder structure. Nathel-specific content stays here (Nathel’s SOPs, Nathel’s customer/vendor profiles, Nathel’s operational runbooks).
  • Wire vault webhooks on both repos: Central → fin-central deployment, Nathel → nathel.fin.app deployment.
  • Stand up Quartz (or stripped Workspace doc reader) at intranet.fin.app (Cloudflare Access for Rob + Josh + Jake + Alex) and intranet.nathel.fin.app (Cloudflare Access for Nathel staff).

Migration Order Dependency

Phase 1 → 2 → 3 (Phase 3 needs both deployments ready) Phase 4 can start after Phase 3 (needs Central Taproot populated) Phase 5 can run in parallel with Phase 4

Total elapsed: ~1-2 weeks of part-time work. Or 3-4 focused days.

6. Access Scopes

6.1 FIN Central Intranet Access

PersonRoleScope
Rob GarciaFIN founder/operator (60% owner)Full access
Joshua GatckeFIN partnerFull access
Jacob GatckeFIN partnerFull access
Alex CohenNathel technical liaisonScoped to integration/pilot subdir only
Ira Nathel (ira@nnproduce.net)Nathel owner / produce industry sponsorRead-only access to Nathel-relationship subdir
Future FIN hiresTBDPer-role
Anthropic / partnersexternalScoped subdir or partner-specific projection
InvestorsexternalScoped subdir per investor
Federal liaisonsexternalScoped subdir per agency

6.2 Nathel Tenant Intranet Access

PersonRoleScope
Joshua GatckeVP, primary userTenant admin
Jacob GatckeGM, primary userTenant admin
Alex CohenTech liaisonTenant admin
Nathel office staffTBD per onboardingRole-scoped (receiver, dispatcher, office, etc.)
Ira NathelOwnerRead-only executive view
Nathel customersexternalCustomer portal only
Nathel vendorsexternalVendor portal only

Note: Josh and Jake have separate identities per surface (FIN partner vs Nathel operator). Alex has separate identities per context (scoped FIN Central viewer vs Nathel tenant admin). They authenticate independently and their access scopes do not cross-contaminate.

7. Data Flow Rules

Strict, enforced at the code level:

  1. External → Central: scrapers in fin-central pull from external sources, write to fin-central-prod Neon. Never write to tenant Neons.
  2. Central → Tenant: Taproot sync API. Tenants pull periodically. Central never pushes directly into tenant DBs.
  3. Tenant → Central: ONLY anonymized aggregate signals, opt-in per tenant, gated by policy. Used to enrich Harvest Directory. Never raw tenant operational data.
  4. Tenant → Tenant: Only via marketplace (Wave 4+) and only through blinded broker pattern. No direct tenant data sharing.
  5. Tenant → Public: Via Harvest Directory mirror only. Anonymization gate enforced at projection time.

8. Anonymization Boundary

The anonymization policy lives in fin-central-prod. The policy artifact is a versioned doc (docs/policies/anonymization/<version>.md). Application of the policy happens at projection time when:

  • A tenant publishes aggregate data into Harvest Directory (opt-in)
  • The public Tier 0 MCP serves any response derived from cross-tenant data
  • A federal-audience projection is generated

The anonymization application is itself a deterministic transform auditable through walk_provenance.

9. Observability Stack (Per Layer)

9.1 FIN Central Observability

Dashboards / projections served from fin-central-prod:

  • federation_health — per-tenant signal (uptime, event volume, channel health), no tenant content
  • taproot_canonical_health — entity counts, scraper status, embedding coverage
  • tier_0_public_traffic — call volume, abuse detection
  • tenant_provisioning_status — onboarding progress per tenant
  • anonymization_policy_status — current version, last review, pending reviews
  • federal_readiness — pipeline progress, evidence artifacts current

9.2 Tenant Observability (Nathel-Specific)

Dashboards / projections served from nathel-prod:

  • nathel_operational_health — events/day, agent activity, channel status
  • nathel_projection_freshness — last projection update times
  • nathel_customer_portal_usage — customers active, queries served
  • nathel_vendor_portal_usage — same for vendors
  • nathel_agent_gradeboard_per_role — agent quality per skill bundle
  • nathel_onboarding_progress — per-actor onboarding completion
  • nathel_taproot_sync_status — last sync, divergence, overlays count

10. Tenant Onboarding Path (Future-Proof)

When the second tenant comes online (post-Nathel-proof):

  1. Create new Neon project (<tenant>-prod)
  2. Create new Cloudflare deployment (<tenant>.fin.app)
  3. Create new GitHub vault repo (<tenant>-intranet)
  4. Register tenant with FIN Central’s tenant-lifecycle module
  5. Configure Taproot sync (cadence, entity-type filter)
  6. Deploy fin-agentic to the new tenant deployment with role: tenant
  7. Bootstrap onboarding (10-step PK v2 program)

The pattern is repeatable. Phase 1-5 of this plan IS the tenant onboarding runbook, abstracted.

11. Open Questions

IDQuestionDefault
D-1Should fin-central-prod and nathel-prod use Neon branching from one project, or be distinct Neon projects?Distinct projects — strongest isolation, simpler RBAC.
D-2When does Nathel’s nathel-intranet repo transfer to Nathel’s GitHub org?After Phase 5; Rob retains co-admin.
D-3Should the Taproot sync be poll-based or push-based for v1?Poll-based for v1 (simpler). Push (webhook) for Wave 4.
D-4How long to retain Central-owned data in nathel-prod after Phase 3 import to fin-central-prod?30 days dual-write parallel, then prune from nathel-prod.
D-5Where do FIN Central’s scrapers run — Worker cron or external scheduler?Worker cron + Durable Objects for stateful scraping; external scheduler for long-running scrapes.
D-6Federal mode: separate Neon project or flag on Central?Separate Neon project on FedRAMP-authorized region. Wave 4.

12. Risks

R-1: Cross-contamination during Phase 3

If Central-owned data is duplicated or moved incorrectly, both deployments could be inconsistent.

Mitigation: dual-write parallel for 30 days. Reconciliation projection detects drift. Prune from nathel-prod only after Central side is proven.

R-2: Code drift between roles

If feature flags are misapplied or new features ship without gating, the demarcation degrades.

Mitigation: CI gate that verifies every new module declares its DEPLOYMENT_ROLE requirement. Lint rule that fails build if missing.

R-3: Taproot sync staleness

If sync fails silently, tenant operates against outdated Plane 3 knowledge.

Mitigation: signal.taproot_synced events with cadence threshold alerts. Sync delays > 24h emit signal.taproot_sync_stalled.

R-4: Identity confusion (Josh/Jake/Alex dual roles)

People holding both FIN-partner and Nathel-tenant identities could accidentally access the wrong context.

Mitigation: distinct accounts per role (different email aliases or SSO mappings). UI clearly labels which context user is in. Audit log of context switches.

R-5: Solo-operator overload

This is significant work during the Nathel proof phase.

Mitigation: spread Phase 1-5 over 2 weeks. Defer optional sophistication (push sync, full marketplace plumbing) to later waves. Use this work as the dogfood for the harness — Claude/Codex helps execute.

13. Stop Conditions

Halt and reassess if:

  • Data integrity issue detected during Phase 3 migration → roll back, diagnose
  • Tenant operational performance degrades because of sync overhead → raise sync interval, defer push-based sync
  • A FIN Central feature cannot be gated without major refactor → reconsider gate location or accept temporary mixed-mode with documented exceptions
  • Solo-operator burnout signals appear → pause; ship per-phase separately

14. Success Criteria

Demarcation is complete when:

  • fin-central-prod and nathel-prod are independent Neon projects with no shared data except via the Taproot sync API
  • A single fin-agentic build deploys cleanly to either role with only env-config differences
  • Nathel can fully operate (operator agent, projections, portals) without depending on its old self-contained data; data flows from Central Taproot via sync
  • Rob + Josh + Jake + Alex can access the FIN Central intranet at intranet.fin.app; Nathel staff can access the Nathel intranet at intranet.nathel.fin.app; access scopes are enforced
  • No FIN Central code or canonical data resides in nathel-prod
  • No tenant operational data resides in fin-central-prod
  • The architecture demonstrates the multi-tenant federated intelligence model in a single working deployment — provable to investors, partners, and federal evaluators

15. Why This Demonstrates The Multi-Tenant Federated Intelligence Vision

Once this demarcation is in place:

  • Adding a second tenant is mechanical (clone the Phase 1-5 pattern)
  • The Taproot sync mechanism IS the federated intelligence primitive
  • Anonymized aggregate upload from tenants to Central IS the federated learning primitive (Wave 4+)
  • Per-tenant overlays demonstrate “shared canon + private knowledge” patterns
  • The control plane / data plane split IS the architecture investors and federal reviewers expect to see in a credible critical infrastructure platform
  • One deployment serving FIN as Tenant Zero, plus one tenant deployment for Nathel, is the minimum viable proof. Two real tenants on a federated platform with a control plane is enormously stronger evidence than one mixed-mode deployment

This work is not infrastructure plumbing. It is the architectural proof of the multi-tenant federated intelligence claim.

Graph View

Backlinks