docs(copy): remove EDI and SFTP from supported-format copy

PRODUCTION_SURFACE.md

@@ -15,7 +15,7 @@ ingest -> canonicalize -> validate -> persist evidence -> export
 These surfaces are part of the core production spine when their corresponding routers are mounted in `server/main.py`.
 
 - Ingestion and webhook CTE intake
-- CSV, EPCIS, and EDI FSMA data intake
+- CSV and EPCIS FSMA data intake
 - Inflow Workbench preflight and commit gate
 - Canonical record and CTE/KDE persistence
 - Compliance rules, readiness, exception, and audit review workflows

README.md

@@ -39,8 +39,7 @@ Implemented capabilities in the current tree. Route availability is controlled b
 | Paid endpoint subscription gate | [services/ingestion/app/subscription_gate.py](services/ingestion/app/subscription_gate.py) |
 | CSV template download and CSV or Excel `.xlsx` CTE ingest (workbook converted to CSV text on the same route) | [services/ingestion/app/csv_templates.py](services/ingestion/app/csv_templates.py), [services/ingestion/app/shared/xlsx_rows.py](services/ingestion/app/shared/xlsx_rows.py), [docs/engineering/TRACEABILITY_FILE_INTAKE.md](docs/engineering/TRACEABILITY_FILE_INTAKE.md) |
 | EPCIS 2.0 JSON and XML ingest, including the `/ingest` dashboard upload tab | [services/ingestion/app/epcis/router.py](services/ingestion/app/epcis/router.py), [frontend/src/lib/epcis-upload.ts](frontend/src/lib/epcis-upload.ts) |
-| EDI X12 ingest for 856, 850, 810, 861, 944, and 945 (856/861/944/945 emit one CTE per item line; 850/810 stay one event per transaction set) | [services/ingestion/app/edi_ingestion/](services/ingestion/app/edi_ingestion/), [docs/engineering/TRACEABILITY_FILE_INTAKE.md](docs/engineering/TRACEABILITY_FILE_INTAKE.md) |
-| GS1 identifier check-digit validation (GLN/GTIN/SSCC) used by webhook, EDI, and EPCIS ingest | [services/shared/fsma_validation.py](services/shared/fsma_validation.py) |
+| GS1 identifier check-digit validation (GLN/GTIN/SSCC) used by webhook and EPCIS ingest | [services/shared/fsma_validation.py](services/shared/fsma_validation.py) |
 | Optional Jev CSV column mapping and file-CTE suggestions, confidence-based review, upload UI prompts, and operator preview/evaluation tools; automatic application defaults off | [services/shared/jev/](services/shared/jev/), [docs/engineering/JEV_HEADER_MAPPING.md](docs/engineering/JEV_HEADER_MAPPING.md) |
 | Optional LlamaIndex Extract v2.5 document extraction: a fail-open second pass on bulk-upload supplier PDFs the table parser cannot read, with per-field citations, confidence and evidence; rows still go through classify, validate and human commit; operator command-line tool | [services/shared/document_extract/](services/shared/document_extract/), [docs/engineering/DOCUMENT_EXTRACT.md](docs/engineering/DOCUMENT_EXTRACT.md) |
 | Inflow Workbench preflight, readiness, fix queue, scenario library, and commit gate | [services/ingestion/app/inflow_workbench.py](services/ingestion/app/inflow_workbench.py) |
@@ -77,7 +76,7 @@ ingest source record
   -> expose compliance/audit/export views
 ```
 
-The diagram describes the Workbench workflow. Direct webhook, CSV, EPCIS, and EDI intake has route-specific validation and persistence; it does not universally pass through Workbench. Event persistence is mid-migration from a legacy CTE store to a canonical hash-chain store: some write paths still write both stores, newer paths write canonical-only, and read paths have consumer-specific cutover flags. Chain verification defaults to canonical reads; FDA CSV export v1 retains a legacy code default. Historical rollout observations are recorded in the cutover runbook; current deployment flags must be read back separately (see [docs/persistence/dual-write-cutover.md](docs/persistence/dual-write-cutover.md)). Graph, NLP, generic regulatory-intelligence, and document-ingestion modules are present, but they should not be treated as the core product contract without checking the relevant tests and deploy wiring.
+The diagram describes the Workbench workflow. Direct webhook, CSV, and EPCIS intake has route-specific validation and persistence; it does not universally pass through Workbench. Event persistence is mid-migration from a legacy CTE store to a canonical hash-chain store: some write paths still write both stores, newer paths write canonical-only, and read paths have consumer-specific cutover flags. Chain verification defaults to canonical reads; FDA CSV export v1 retains a legacy code default. Historical rollout observations are recorded in the cutover runbook; current deployment flags must be read back separately (see [docs/persistence/dual-write-cutover.md](docs/persistence/dual-write-cutover.md)). Graph, NLP, generic regulatory-intelligence, and document-ingestion modules are present, but they should not be treated as the core product contract without checking the relevant tests and deploy wiring.
 
 ## Architecture
 
@@ -88,7 +87,7 @@ The repo still contains six service directories:
 | Directory | Purpose |
 | --- | --- |
 | [services/admin](services/admin) | tenants, users, roles, MFA, API keys, audit logs, admin routes |
-| [services/ingestion](services/ingestion) | webhook, CSV, EPCIS, EDI, sandbox, export, CTE persistence integration |
+| [services/ingestion](services/ingestion) | webhook, CSV, EPCIS, sandbox, export, CTE persistence integration |
 | [services/compliance](services/compliance) | compliance validation routes and FSMA rules JSON |
 | [services/graph](services/graph) | graph and supply-chain query modules |
 | [services/nlp](services/nlp) | regulatory/document extraction modules |

REPO_PURPOSE.md

@@ -6,7 +6,7 @@ RegEngine is a pre-production, API-first FSMA 204 food traceability evidence pla
 
 ## Scope
 
-- Webhook, CSV, EPCIS, and EDI ingestion for FSMA 204
+- Webhook, CSV, and EPCIS ingestion for FSMA 204
 - Inflow Workbench preflight, readiness, fix queues, and commit gates
 - Optional CSV column and event-type suggestions, subordinate to deterministic validation
 - CTE/KDE canonicalization

docs/PRODUCT_DESCRIPTION.md

@@ -8,7 +8,7 @@ RegEngine is an API-first FSMA 204 food traceability evidence platform: supplier
 
 ## Product description
 
-RegEngine works alongside an ERP, turning existing food supply-chain records into traceability evidence. It accepts webhook events, CSV uploads, EPCIS documents, and EDI records. Inflow Workbench provides a preparation workflow with preflight checks, readiness scoring, a fix queue, and a commit gate. Direct intake routes have their own validation and persistence paths; not every ingestion request passes through Workbench.
+RegEngine works alongside an ERP, turning existing food supply-chain records into traceability evidence. It accepts webhook events, CSV uploads, and EPCIS documents. Inflow Workbench provides a preparation workflow with preflight checks, readiness scoring, a fix queue, and a commit gate. Direct intake routes have their own validation and persistence paths; not every ingestion request passes through Workbench.
 
 Accepted events are stored with tenant boundaries in PostgreSQL. The platform evaluates versioned rules, records audit evidence, and provides FDA-oriented exports, request-response cases, auditor workflows, and recall readiness reports. Canonical and legacy persistence paths coexist during a documented cutover. Rule enforcement can be advisory or blocking according to configuration and route support.
 
@@ -22,7 +22,7 @@ Public synthetic artifacts, a browser verifier, a downloadable Python bundle ver
 
 | Capability | Availability and code evidence |
 | --- | --- |
-| Webhook, CSV, EPCIS, and EDI intake; CTE/KDE normalization | Core intake: [webhook routes](../services/ingestion/app/webhook_router_v2/routes.py), [CSV intake](../services/ingestion/app/csv_templates.py), [EPCIS](../services/ingestion/app/epcis/router.py), [EDI](../services/ingestion/app/edi_ingestion/). |
+| Webhook, CSV, and EPCIS intake; CTE/KDE normalization | Core intake: [webhook routes](../services/ingestion/app/webhook_router_v2/routes.py), [CSV intake](../services/ingestion/app/csv_templates.py), [EPCIS](../services/ingestion/app/epcis/router.py). |
 | Inflow Workbench and supplier preflight | Release-enabled: [Workbench](../services/ingestion/app/inflow_workbench.py), [supplier portal](../services/ingestion/app/supplier_portal.py). |
 | Jev CSV header and file-CTE suggestions | Optional integration: [settings and policies](../services/shared/jev/), [configuration and evaluation guide](engineering/JEV_HEADER_MAPPING.md). Requires provider configuration; automatic application is opt-in. |
 | Versioned rules and compliance scores | Release-enabled: [rules engine](../services/shared/rules/engine.py), [compliance validation](../services/compliance/app/routes.py), [score API](../services/ingestion/app/compliance_score.py). Enforcement is configuration-dependent. |

docs/product/WEBSITE_COPY.md

@@ -46,7 +46,7 @@ Current public positioning for the FSMA 204 traceability product.
 **Headline:** Inflow prepares the data. The Engine proves it.
 
 **Steps:**
-1. Preflight supplier data: Upload, paste, or simulate supplier CSV, spreadsheet, EDI-style, or API-shaped traceability records.
+1. Preflight supplier data: Upload, paste, or simulate supplier CSV, spreadsheet, or API-shaped traceability records.
 2. The Engine evaluates: FSMA 204 KDE and CTE rules produce readiness scores, blocked states, and fix queue tasks.
 3. Commit only clean evidence: Simulation, preflight, staging, and production evidence are separated by an explicit commit gate.
 
@@ -64,7 +64,7 @@ Supplier Data -> Inflow Lab -> Engine -> Commit Gate -> Evidence + Export
 
 ### Feature Copy
 
-**Supplier Data Readiness:** Upload or simulate CSV, spreadsheet, EDI-style, API, and supplier portal records in Inflow before they touch production evidence. Saved integration profiles preserve supplier-specific field mappings so the same feed can be replayed and improved.
+**Supplier Data Readiness:** Upload or simulate CSV, spreadsheet, API, and supplier portal records in Inflow before they touch production evidence. Saved integration profiles preserve supplier-specific field mappings so the same feed can be replayed and improved.
 
 **Preflight Validation:** The Engine evaluates each CTE against FSMA 204 KDE requirements, lot linkage expectations, malformed values, duplicate risks, and export readiness impact. Failures generate plain-language remediation work instead of disappearing into a rejected payload.
 

frontend/src/app/records/page.tsx

@@ -37,7 +37,6 @@ const SOURCE_LABEL: Record<string, string> = {
   xlsx_upload: 'XLSX Upload',
   epcis_api: 'EPCIS API',
   epcis_xml: 'EPCIS XML',
-  edi: 'EDI',
   manual: 'Manual',
   legacy_v002: 'Legacy',
 };