Data Ownership and Agentic Search

The search layer joins records for discovery; it does not merge the source systems into a new authority. Every result must retain its source system, stable record identifier, and snapshot or live-read freshness.

System-of-record matrix

Information	Authoritative system	Search behavior
Native CAD file and CAD revision	Aras PLM / connected CAD vault	Return engineering identity and lifecycle context
Engineering part and revision	Aras PLM	Preserve part ID, revision, generation, and lifecycle state
Engineering BOM intent	Aras PLM	Show the governed structure and release eligibility
Documents and specifications	Aras PLM	Preserve document identity and relationship to the part
Product operational identity	Odoo ERP	Return Odoo record ID and internal reference
Supplier and purchasing information	Odoo ERP	Return current operational records
Stock and replenishment signals	Odoo ERP	Treat as time-sensitive operational data
Manufacturing BOM and routing	Odoo ERP after release	Distinguish published manufacturing data from PLM intent
Derived geometry and DFM findings	RapidDraft	Reference the analyzed model and component revision
Cross-system query index	Search gateway	Treat as a rebuildable projection only
Conversation and answer	LibreChat	Treat as interaction history, never master data

Shared identity

A canonical part identity links representations without replacing native IDs. The demonstration uses a stable, lowercase integration key such as:

part:rd-bat-housing-001

Each result can then carry:

• canonical integration identity;
• business part number, such as RD-BAT-HOUSING-001;
• native Odoo record ID;
• native Aras item ID and revision;
• source system;
• lifecycle or operational status;
• projection or live-read timestamp.

Native IDs remain necessary for audit, deep links, updates, and reconciliation. The canonical identity is the join key, not an authorization shortcut.

Release-aware synchronization

sequenceDiagram
    participant CAD as CAD adapter
    participant PLM as Aras PLM
    participant Gate as Release policy
    participant ERP as Odoo ERP
    participant Search as Search projection

    CAD->>PLM: Submit revision metadata
    PLM->>Gate: Evaluate lifecycle state
    alt Released
        Gate->>ERP: Build publication plan
        ERP-->>Gate: Return proposed changes
        Gate->>ERP: Apply only after explicit approval
    else Not released
        Gate-->>ERP: No publication
    end
    PLM->>Search: Publish engineering projection
    ERP->>Search: Refresh operational projection

The integration console currently stops at a dry-run plan unless an authorized operator explicitly selects a write operation. This keeps search validation independent from master-data mutation.

Agent answer contract

The ERP/PLM Agent should:

1. identify the matched part or assembly before summarizing it;
2. distinguish Aras engineering facts from Odoo operational facts;
3. include record identifiers and lifecycle/status fields when they affect the answer;
4. state whether Odoo data was read live and when the Aras snapshot was generated;
5. disclose missing or conflicting records instead of reconciling them silently;
6. avoid presenting a Preliminary or In Review revision as released;
7. never infer stock, supplier approval, DFM compliance, or release state from unrelated fields.

For example, a supplier question should be answered primarily from Odoo. The Agent may add Aras lifecycle context, but it must not imply that a supplier record proves an engineering release.

Current data posture

Source	Retrieval mode	Consequence
Odoo test database	Live read through JSON-2	Operational answers can reflect current test data
Aras test environment	Versioned snapshot in Railway	Engineering answers must expose snapshot freshness
RapidDraft DFM	Live authenticated request for a known model/component	Findings must remain tied to the analyzed model identity
CAD workstation	Explicit localhost bridge action	Railway cannot open or control CAD applications directly

The Aras snapshot is an intentional network boundary, not a claim of real-time synchronization. Until a private adapter is deployed, freshness must be visible and refreshes must be repeatable.

Demonstration coverage

The current battery-module dataset is intentionally small enough to audit end to end. It includes:

• 10 matched product/part identities;
• supplier and purchasing records;
• a multi-level BOM and routing operations;
• stock and replenishment context;
• Aras Part, Document, and CAD records with relationships;
• 6 Released, 3 In Review, and 1 Preliminary lifecycle examples.

This mix allows the Agent to demonstrate cross-system lookup while also proving that lifecycle gates and missing-data behavior work.

Open Questions

• What is the canonical conflict policy when Odoo and Aras descriptions or units of measure differ?
• How long may an Aras snapshot remain valid before the Agent must warn or refuse an answer?
• Which supplier and cost fields require role-based filtering in LibreChat responses?
• Should DFM results be persisted as Aras-controlled documents, RapidDraft records, or both?

Sources

• D:\02_Code\15_ERP\docs\Agentic_Search_Integration_v1.md
• D:\02_Code\15_ERP\docs\Phase_2_CAD_RapidDraft_Integration_Plan.md
• D:\02_Code\15_ERP\docs\Implementation_Status_v1.md
• D:\02_Code\15_ERP\outputs\019f98c8-a330-7672-bbd0-826effe7405f\RapidDraft_Demo_Data_v1.json
• D:\02_Code\15_ERP\services\search-gateway\data\cad-fixtures\