PLM Rules Platform

I would first establish that PLM remains authoritative for released part identity, while PartFlow owns intake, validation evidence and approval workflow. The critical path is draft → validate → freeze submission revision and rule bundle → auto-approve or human review → reliably create once in PLM → reconcile. Rule editing is a separate governed path with tests and impact simulation. I would ask whether PLM supports idempotency or a unique external reference.

V1 has six versioned forms, dependent fields, approved vocabularies, format and cross-field rules, live feedback, final server validation, automatic approval for no blocking violations, exception queues, reviewer decisions, rule proposals and PLM creation. A warning can pass; a blocking violation cannot auto-approve but may be reviewable depending on policy. Reviewers can approve an exception with reason, return for revision or reject. Adding a new rule from a case is a separate proposal—it must never retroactively change the already reviewed decision.

• Validation is deterministic and explainable.
• Submission revision and evaluated rule bundle are frozen together.
• PLM creation success is a state, not assumed from approval.

Sixty submissions/min is 1/s peak, modest for workflow writes. Three hundred validation events/s are burstier, but client debounce and cached pure rules reduce server load. At 80% auto-approval, 20% of 10,000 monthly submissions means 2,000 human reviews. If each takes eight minutes, that is 267 hours/month, roughly 1.7 full-time reviewers at 160 hours before peaks and coverage. Queue design and better evidence matter more than raw compute.

10,000 × 20% = 2,000 reviews/month
2,000 × 8 min = 16,000 min = 267 h
267 / 160 ≈ 1.7 reviewer-months

Submission is a workflow aggregate with optimistic row version. Every save creates or updates a draft, but submit seals an immutable SubmissionRevision with content hash. Rule and RuleVersion separate stable identity from immutable logic; approved versions assemble into a content-addressed bundle per effective context. Evaluation keys submission revision plus bundle, storing facts and rule trace. ReviewTask is leased. PLMCommand is keyed by submission and deterministic business key. PLMMapping proves the external part ID and observed PLM version.

• One approved submission has at most one active PLM command by unique constraint.
• Part business key is normalized and checked against both local cache and PLM.
• Old evaluations remain replayable after rule changes.

Use a constrained typed DSL, not arbitrary JavaScript. Rules declare context, effective interval, input paths, predicate, severity, message, exception policy and stable rule ID. Compile the DSL to a validated AST and deterministic evaluator. Pure field rules may be sent to the client as a signed compiled subset for responsiveness, but server evaluation is authoritative. Cross-record uniqueness and PLM lookups run server-side as versioned facts. Each evaluation emits rule ID/version, inputs read, intermediate values, result and message.

The client loads schema and bundle IDs, evaluates safe local rules, and debounces server validation. On submit it sends expected draft revision and idempotency key. The service canonicalizes fields, seals SubmissionRevision, resolves the approved bundle for context/time, fetches external facts through cached adapters, and writes Evaluation. In one transaction it moves Submission to APPROVED_PENDING_PLM and writes PLMCommand to the outbox. An integration worker sends the canonical payload with unique client reference. It records the PLM ID, transitions to CREATED, and a reconciler later reads PLM to confirm fields/version.

• User sees “approved, creation pending” rather than a false success.
• Notifications consume state-change outbox events.
• Duplicate submit returns the same sealed revision/result.

A steward creates a draft RuleVersion with unit examples and rationale. Static checks verify types, referenced fields, unreachable branches, conflicts and effective-date overlap. The simulator runs it over recent anonymized submissions and a curated boundary suite, showing changed pass/review/reject counts and which cases move. Another role approves. Publication creates a new immutable bundle in a serializable transaction; caches key by bundle hash. In-flight submissions keep their frozen bundle. A kill switch marks a bundle unavailable for new evaluations and falls back to the prior approved version, while preserving decisions already made.

• Rule change is code: review, tests, diff, staged rollout.
• Simulation includes human workload impact.
• No retroactive re-evaluation without explicit campaign.

Our DB transaction writes approval state and PLMCommand outbox atomically. The worker leases the command and sends unique client reference equal to submission ID. On timeout, it first queries PLM by that reference; only if absent does it retry with exponential backoff. PLMMapping has a uniqueness constraint on tenant + external reference and PLM part ID. If PLM accepts but the response is lost, lookup resolves it. If payload conflicts with an existing reference, quarantine for operator review. A scheduled reconciler compares pending/created commands with PLM and repairs local mapping, never blindly creates again.

• At-least-once messages, effectively-once external business effect.
• PLM is authoritative for final part ID.
• Compensation may cancel a not-yet-released part; it does not erase audit.

Strong consistency protects bundle publication, final submission transition, review decision and command creation. Draft/live validation can be eventual but must report bundle/fact freshness. Cache immutable schema and rule bundle by hash. External PLM dictionaries use TTL plus version; final submit can require fresh facts for critical checks. Idempotency covers save/submit/decision and PLM command. Separate validation, review, notification and PLM queues. If PLM slows, cap worker concurrency and let APPROVED_PENDING_PLM backlog without taking down form validation.

The command remains SENT_UNKNOWN, not retried immediately. The worker queries by unique client reference. If found, it verifies payload hash, stores PLMMapping and completes. If lookup is temporarily unavailable, it retries reconciliation, not creation. Only an authoritative “not found” after a safe visibility window permits create retry. Metrics track unknown-age. Operator tooling can attach a discovered PLM ID with dual approval. This relies on requiring the client-reference field; without it, exact duplicate prevention would need a domain business-key reservation or PLM-side change.

Submit seals revision R and evaluation E. A ReviewTask leases that pair. A user editing afterward creates draft R+1 but cannot alter the task. Reviewer decision includes expected task version and evaluation hash. Approve-exception records violated rule IDs and reason, then atomically closes the task and creates the PLM command for R. If the applicant submits R+1 first, policy either cancels the old task or keeps both visibly linked; never silently apply an approval to new data. SLA queues use priority and expertise, with lease expiry and reassignment.

• Decision is on immutable facts.
• Reviewer can request revision without mutating applicant input.
• Dual review for high-risk exception classes.

The pre-publish simulator should flag workload delta, but we still need runtime guards. Monitor pass/review rates by bundle and workflow; a sudden breach trips a bundle kill switch for new submissions and restores the prior approved bundle. In-flight evaluations remain traceable. Quarantine the bundle, open an incident, diff affected decisions and decide whether a re-evaluation campaign is legally allowed. Reviewer queues get admission controls and aging priorities. Post-incident, add the missed cases to the boundary suite and require workload budget approval.

Tenant ID is part of every primary and index key. Form schemas, rules and dictionaries cannot cross tenants. Use SSO and roles for applicant, reviewer, steward, approver and integration operator; separate rule author from publisher. PLM credentials live in a secrets manager and workers receive short-lived tenant-scoped access. Rule DSL is sandboxed and cannot make network calls. Audit payload views, decisions, rule publication, exports and manual mapping. Sensitive supplier data is encrypted and masked in analytics. Agent-generated rule proposals are untrusted drafts.

• Row-level checks plus tenant-keyed caches.
• No raw payload in logs.
• Bulk export needs explicit permission and watermark.

Track validation p95, client/server disagreement, rule error rate, bundle cache hit, auto-approval by workflow, exception queue age, reviewer overturn and repeat-return. Integration SLIs: command backlog/age, unknown sends, PLM latency/error, lookup recovery, duplicate-prevention invariant and reconciliation divergence. Rule quality: simulation delta, production violation distribution, false-block complaints and approved-exception frequency by rule. Business outcomes include turnaround time and manual hours, but pair them with correction/duplicate rates so automation does not hide bad quality.

• Synthetic PLM canary verifies create/lookup contract without real release.
• Trace one submission across evaluation, review, command and PLM mapping.
• Alert on state age, not only error counts.

Start read-only: import PLM dictionaries and validate without changing workflow. Then one low-risk form with human approval for every case, compare recommendations, enable auto-approval for high-precision rules, and finally enable PLM writes behind a command kill switch. A rich general rule language is flexible but dangerous; constrained DSL is deliberately less expressive. Cached PLM facts improve latency but risk staleness, so critical checks refresh at submit. Traps are making PartFlow a competing source of record, executing remote calls inside transactions, retrying timeouts as new creates, and applying new rules to old approvals.

PartFlow owns guided intake and evidence; PLM remains authoritative for released parts. Versioned forms and a constrained deterministic DSL provide fast client hints and authoritative server validation. Submit seals an immutable revision with one approved rule bundle. Passing cases or reviewed exceptions become approval state plus an outbox command in one transaction. A lookup-before-retry saga and reconciler create exactly one PLM part despite timeouts. Rule publication uses tests, simulation, separation of duties and runtime guardrails. Metrics cover user latency, reviewer load and cross-system correctness.