FIN Central

Produce ERP Source-of-Record Leverage Program

11 min read

Produce ERP Source-of-Record Leverage Program

Date: 2026-05-18 Source artifacts: 132 PP resources (81 PDFs + 51 screenshots) at _03_Dev/Produce Pro_source docs research/ Companion docs:

  • docs/ingestion/produce-pro/CORPUS_MANIFEST.md (existing 92-artifact catalog)
  • docs/ingestion/produce-pro/FIELD_MAPPING_AND_SAFETY_SPEC.md (Module 09 ground truth)
  • docs/ingestion/produce-pro/SCREEN_INVENTORY.md (4-state coverage model)
  • docs/ingestion/produce-pro/PDF_EXTRACTOR_SPEC.md (PDF → CIR extractor)
  • docs/product/FIN_DATA_SIGNAL_OFFERINGS_2026-05-15.md (commercial offerings)

0. TL;DR

Nathel runs on Produce Pro (PP). PP’s user guide + 22 module PDFs + 51 screen captures + 14+ version release notes + invoice/passing/PO real samples are sitting at _03_Dev/Produce Pro_source docs research/. We’ve consumed ~30-35% of this surface area into FIN’s ingestion + reconciliation + shadow-agent layers. The other ~65-70% is leverage left on the table.

Same artifact shape recurs in other produce ERPs (Famous Software, Sage X3 Produce, NetSuite, Dynamics F&O). Designing this layer for cross-ERP fungibility today turns “Nathel-only tuning” into “ERP-pack-based onboarding” — a commercial moat.

This program structures the leverage in 5 tracks (A through E) with explicit dependencies, effort estimates, and success metrics.

1. Goals

#GoalMeasure of done
G1Codify every PP module’s field semantics + workflows as agent-readable knowledge18 PP module ontology MDs published; get_pp_module_reference MCP tool returns canonical answer per module
G2Achieve ≥85% extractor coverage of PP report types Nathel actually usesPer-report-type extractor count: ≥85% of CORPUS_MANIFEST entries have a per-type extractor wrapper or have an explicit “not-applicable” justification
G3Walk all 51 screenshots through raw → labeled → verifiedshadow_agent.screen_verified event count = 51
G4Eliminate PP-version-drift silent failuresAll PP extractors are version-pinned; signal.erp_version_changed fires when Nathel PP changes; new versions don’t silently corrupt extraction
G5Cross-ERP adapter pack contract proven by PP-as-referencePP code reorganized under packages/shared/src/parsers/erps/produce-pro/; ERP Adapter Pack contract codified; PP passes the contract; placeholder structure exists for future ERPs

2. Non-goals

  • Building extractors for non-Produce ERPs at FIN. We design the contract; we don’t onboard fictional tenants.
  • Replacing live PP at Nathel. PP remains system-of-record; FIN consumes its outputs and overlays operational intelligence.
  • Reverse-engineering PP UI beyond what user guides + screen captures + invoices provide. We don’t scrape closed-source binaries or violate ToS.
  • Cross-tenant aggregation of PP data. Per feedback_tenant_intel_sovereignty.md, tenant operational intel + derivations stay in tenant Neon.

3. The 5 tracks

Track A — PP Ontology Knowledge Pack (~3-5 days, highest leverage)

Deliverable: knowledge.domain='produce_pro_ontology' knowledge pack on fin-central-intranet (universal-plane); one MD per PP module.

Source artifacts:

  • ProducePro 2401.0 User Guide.PDF (master reference)
  • 22 module-specific PDFs:
    • 00 About / 01 QuickStart / 02 Searching / 03 Layout
    • 04 Config / 05 Charges / 06 Scanning / 07 Communication
    • 09 Purchasing / 11 Pricing / 12 Sales / 13 Shipping
    • 14 Transportation / 15 Sales Analysis / 16 AP / 17 AR / 18 GL
    • 20 Quick training / Trip and Route Editor / Customer Success Handbook 2025
    • Analytics Introduction Lessons 1-2 + YOY Comparison guide

Per-module MD contains:

  • Field-name canonical list with PP code + business meaning + data type + UoM
  • Workflow state machine (e.g., PO lifecycle: Created → Released → Received → Closed)
  • Validity rules + sentinel values (e.g., 0 = nothing expected (DNR / cancelled placeholder))
  • Cross-references to other modules (e.g., Purchasing → Receiving handoff)
  • Frontmatter: data_plane: universal_intelligence, linked_entities to each FIN entity referenced

Path: fin-central-intranet:docs/erp/produce-pro/modules/<NN-name>.md (mirrored to tenant via taproot rung 2)

MCP tool addition: get_pp_module_reference(module_name) reads the doc + returns structured field-mapping for the agent.

Why first: every other track grounds against this. Track B (extractor expansion) needs canonical field-mapping. Track C (screen verification) labels screens against module workflows. Track D (cross-ERP abstraction) generalizes from this proven structure. Track E (release notes) diffs against this baseline.

Track B — Extractor Coverage Expansion (~5-10 days, depends on A)

Deliverable: ≥85% of PP report types in CORPUS_MANIFEST have a per-type extractor.

Method:

  1. Audit: walk CORPUS_MANIFEST → existing parsers/pdf/extractors/produce-pro.ts → produce coverage matrix
  2. Priority queue (by Nathel operational frequency):
    • High (week 1): PO acknowledgement / PO confirmation, invoice, AR aging, sales analysis daily summary
    • Medium (week 2): pricing rail update, customer order entry, vendor passing report (already partial), trip/route manifest
    • Low (deferred): AP detail, GL detail (lower immediate operational value)
  3. Each new extractor:
    • Add Zod schema in packages/shared/src/parsers/erps/produce-pro/<type>.ts (after Track D restructure) or packages/shared/src/parsers/produce-pro/<type>.ts (before)
    • Add thin wrapper in packages/shared/src/parsers/pdf/extractors/produce-pro.ts calling extractPdfViaLLM<T>()
    • Add golden-PDF test with real sample from _03_Dev/Produce Pro_source docs research/
    • Emit extractor.pp_<type>_extracted event with schema validation pass/fail + version pin

Track C — Screen Verification Sprint (~5 days, gated on live PP access)

Deliverable: all 51 screenshots transition raw → labeled → verified per SCREEN_INVENTORY 4-state model.

Method:

  1. For each screenshot (raw → labeled):
    • Assign workflow (login / search / order_entry / receiving / inventory_check / export_report / navigate_channel / scrape_messages)
    • Assign module (per Track A ontology)
    • Capture nav crumb (path from PP root to this screen)
    • List visible fields + their FIN entity mapping
    • Emit shadow_agent.screen_labeled { screen_id, labeler, workflow, module }
  2. Verification batch (labeled → verified, requires live PP session):
    • Capture session metadata: timestamp, user role, PP build version, full module path
    • Emit shadow_agent.screen_verified { screen_id, verifier, pp_build, session_ctx }
  3. Drift watch (verified → labeled):
    • On UI drift detection (Track E release notes consumer flags this), demote screens
    • Emit shadow_agent.screen_demoted { screen_id, reason }

Gate: Track C-step-2 requires Nathel cooperation for live PP session access. Track C-step-1 can proceed independently.

Impact: unlocks shadow-agent from heuristic-only to plan-and-act trust level for PP UI navigation.

Track D — Cross-ERP Adapter Pack Contract (~5-7 days, depends on A locked + B started)

Deliverable: PP code reorganized under ERP-discriminated structure; ERP Adapter Pack contract codified; PP as the reference implementation.

Structural changes:

packages/shared/src/parsers/
├── erps/                                    # NEW (was: produce-pro/ flat)
│   ├── produce-pro/
│   │   ├── ontology/                        # Track A MDs (mirrored)
│   │   ├── parsers/                         # CSV parsers (moved)
│   │   ├── pdf-extractors/                  # PDF extractors (moved)
│   │   ├── screens/                         # Track C screen library (moved)
│   │   ├── workflows/                       # 8 PP workflows
│   │   └── adapter-pack.json                # Manifest declaring all of the above
│   ├── famous-software/                     # PLACEHOLDER for future
│   ├── sage-x3-produce/                     # PLACEHOLDER for future
│   └── netsuite-produce/                    # PLACEHOLDER for future
└── (other shared parsers)

ERP Adapter Pack contract:

type ErpAdapterPack = {
  erp_system: ShadowErpSystem;                   // already exists in types
  version_supported_range: { min: string; max: string };
  ontology_pack_path: string;                    // path to module MDs
  parsers: { [report_type: string]: ParserModule };
  pdf_extractors: { [report_type: string]: ExtractorModule };
  screen_library: ScreenInventoryEntry[];
  workflows: ShadowErpWorkflow[];
  field_mappings: { [erp_field: string]: FinEntityMapping };
  signal_subtype_map: { [erp_event: string]: SignalSubtype };
};

Signal subtype renaming: signal.pp_arrival_logged → signal.erp.arrival_logged with data.erp_system: ShadowErpSystem discriminator. Backward-compat alias kept for ≥3 months.

Tool renaming: import-pp-data → import-erp-data with erp_system parameter. Same backward-compat.

Strategic outcome: day-1 onboarding for a future Famous Software / Sage X3 / NetSuite Produce tenant becomes:

  1. Ingest their user guide PDFs (Track A pattern)
  2. Generate adapter-pack scaffolding from the ontology
  3. Run extractor coverage + screen verification
  4. Tenant goes live in ~1-2 weeks instead of months

Track E — Release-Notes Drift Watcher (~2 days, standalone quick win)

Deliverable: all 14+ PP release notes processed; version-drift detection live.

Source artifacts: Produce Pro 2401.0 + 2401.1-4 + 2402.0-4 + 2501.0-3 + 2502.0-1 Release Notes (15 PDFs)

Method:

  1. Generic release-notes extractor: parses changelog entries, categorizes (new feature / field change / workflow change / breaking)
  2. Each release note → knowledge.domain='produce_pro_version_history' MD on fin-central + signal.erp_version_changed event per change
  3. Field-change events automatically diff against Track A ontology; on mismatch, fire shadow_agent.ontology_drift_detected to alert that the ontology MD needs updating
  4. Pair extractors with version pins: extractPpInvoiceV2401() vs extractPpInvoiceV2502()
  5. When Nathel upgrades PP (detected via session metadata or release note ingestion), signal.erp_version_changed routes new ingest to the right version-pinned extractor

4. Dependency graph

Track A (PP Ontology) ─────────┬──→ Track B (Extractor Coverage)
                                │       └──→ Track D (Cross-ERP)
                                ├──→ Track C (Screen Verification)
                                └──→ Track E (Release Notes Drift) ──→ feedback to A
  • A is the prerequisite for B + C + D. Ship A first.
  • E is standalone but informs A (when release notes show field changes, A’s ontology MDs need updates).
  • B and C can run in parallel once A locks.
  • D should start after B is partially done so the abstraction has 2+ extractor patterns to generalize from.

5. Cross-ERP fungibility — the commercial moat

Per FIN_DATA_SIGNAL_OFFERINGS_2026-05-15.md §2 (Business Audience offerings B-1 through B-5), FIN’s tenant model assumes multiple tenants beyond Nathel. Each tenant runs some produce ERP. The shape of the integration repeats:

Acquisition phaseWithout ERP Adapter PackWith ERP Adapter Pack
Sales discovery”Yes we integrate with PP, others TBD""Send us your ERP user guide + sample reports + screen captures”
Onboarding implementationEngineering ports PP code → 2-4 months per ERPAdapter-pack generator + 1-2 week tune-up
Tenant go-liveBottleneck on engineering capacityBottleneck on ERP-pack content quality
Multi-tenant fleet maintenanceEach ERP is a separate codebaseSingle FIN core + N adapter packs

The 132 PP artifacts you’ve gathered aren’t just “PP tuning material” — they’re the training corpus for an ERP-onboarding adapter-pack-generator agent. This is the bigger strategic asset.

6. Coordination with existing programs

Existing program / arch docProduce ERP Leverage dependency
PROJECTION_REMEDIATION_TRACKER_2026-05-17Closed (44/46, 95.7%). Substrate this program builds on.
QC_PROJECTION_ARCHITECTURE_2026-05-18QC pulls PP context for received lots via reconcile-inbound-load — Track B extractors expand this fidelity
SALES_MARKET_PROJECTION_ARCHITECTURE_2026-05-18po_intelligence + customer_commodity_matrix consume PP daily sales reports — Track B sales-analysis extractor improves richness
RECALL_AND_PROOF_PROJECTION_ARCHITECTURE_2026-05-18recall_trace upstream chain reads PP PO/lot data — Track B + Track C improve trace completeness
AGENT_AUDIT_PROJECTION_ARCHITECTURE_2026-05-18Shadow-agent sessions on PP screens captured as agent_harness_session via Track C
PLATFORM_OBSERVABILITY_AND_ONBOARDING_PROJECTION_ARCHITECTURE_2026-05-18tenant_readiness for future ERP-pack-onboarded tenants surfaces via this program’s Track D
EMAIL_INTEL_FUSION_AND_LIVING_SIGNAL_EXECUTION_PROGRAM_2026-05-04arrivals@ ingestion already routes PP data; Track A canonicalizes the field-mapping arrivals consumers use
project_pp_day_rollover (memory)Track A Module 12 (Sales) + Module 15 (Sales Analysis) ontology MDs codify the 3pm ET rollover semantics
project_pp_extractor_order (memory)Track B extends this ordering with priority queue

7. Success metrics (final exit gate)

The program completes when:

✓ G1: 18 PP module ontology MDs published on fin-central + mirrored to nathel
✓ G2: ≥85% report-type extractor coverage of CORPUS_MANIFEST
✓ G3: 51 screen verifications complete (shadow_agent.screen_verified count = 51)
✓ G4: Version-pinned extractors live; signal.erp_version_changed firing on detected upgrades
✓ G5: ERP Adapter Pack contract codified; PP passes; 3 placeholder pack folders exist

Plus the optional commercial readiness gate:

☐ ADP-Gen: ERP-pack-generator MCP tool exists (takes user guide PDFs + sample reports → produces scaffolding for new ERP adapter pack)
☐ Tier-2-onboarding-doc: customer-facing "How to bring your ERP onto FIN" doc published

8. Open questions

IDQuestionDefault until answered
PE-Q1Should ontology pack live in produce_pro_ontology domain or under commodity-style universal-plane?New produce_pro_ontology domain — cleanest isolation; mirror to tenant via taproot.
PE-Q2Track C live-PP access — Nathel session recording vs co-working session vs screen-capture-on-demand?Co-working session for the first 5; rest can use screen-capture-on-demand once labeled.
PE-Q3Track D — break backward-compat at v1.0 vs maintain signal.pp_* aliases?Maintain aliases ≥3 months; deprecate after first non-PP tenant onboards.
PE-Q4Release note ingestion (Track E) — historical backfill of all 15+ existing PDFs or just newer ones forward?Backfill all; LLM-extraction is cheap; gives baseline for future diffs.
PE-Q5Track B extractor priority — order by Nathel frequency or by FSMA 204 evidence-bundle value?Nathel frequency. Recall & Proof family’s deterministic re-render reads existing extractor outputs; doesn’t require new ones to ship first.
PE-Q6Where do future-ERP placeholder folders live — committed empty in parsers/erps/ or only listed in adapter-pack registry?Committed empty with .gitkeep + README explaining the contract. Makes the structure self-documenting.
PE-Q7Should shadow-agent ontology drift alerts (Track E feedback into A) auto-PR the ontology MD update or just alert?Just alert for now. Auto-PR comes after ontology pack stabilizes.

9. Stop conditions

  • Cross-ERP fungibility legal review fails (e.g., ERP vendor ToS prevents user-guide-derived ontology publication) → Track D paused; Tracks A/B/C/E continue PP-specific
  • Track A ontology MDs prove unfit for agent reasoning (i.e., LLM can’t use them effectively in eval) → re-architect Track A before B+C+D continue
  • Track E shows continuous breaking changes in PP (e.g., quarterly major schema breaks) → escalate to “freeze on PP 2401.0 baseline, support newer versions only when ROI clear”
  • Track C live-PP access never materializes → Tracks ship without verified screens; shadow-agent operates at labeled trust level only
Week 1: Track A (PP Ontology Knowledge Pack)
        Track E (Release Notes Drift Watcher) — parallel, standalone

Week 2: Track B (Extractor Coverage Expansion) — depends on A
        Track C (Screen Verification Sprint, raw→labeled) — depends on A, parallel with B

Week 3: Track B continues
        Track C step 2 (labeled→verified) — gated on Nathel live PP access
        Track D (Cross-ERP Adapter Pack Contract) — starts when B has 2+ patterns

Week 4: Track D continues
        Final exit-gate verification

(Total: ~4 weeks of focused work; less with parallel chip dispatch)

11. Sign-off

This program is the canonical reference for any PP / ERP-source-of-record / cross-ERP ingestion work. Future work in this space MUST cite this doc + the relevant track in PR descriptions. Cross-mirrored to fin-central-intranet:docs/processes/PRODUCE_ERP_LEVERAGE_PROGRAM_2026-05-18.md.

— claude_orchestrator (Opus 4.7 1M-context, session 7612a827-b892-47e3-86cd-08835737208e)

Graph View