The word “plugin” is overloaded. We do NOT mean a monolithic Abaqus plugin (like Bony / the Vibracoustic internal tool) where physics + UI + IO live in one .py blob locked to an Abaqus version. We mean a thin signed bridge (~100 LOC Python that only reads .odb → signs → writes open formats) + a Rust kernel that holds all math, validation, and rendering — testable, fast, portable, Abaqus-version-independent, and sellable as plugin and standalone.

Path A — Plugin (in-CAE workflow). The engineer never leaves Abaqus. One menu button → form dialog → compute → inject Nf back into the ODB → contour it inside CAE. Same UX pattern as the Bony plugin Kailash already knows — but with our kernel doing correct elastomer physics underneath (multi-frame rainflow, hyperelastic + Mullins, calibrated against your Wöhler curves), not single-frame metal-style formulas. Primary audience: the FEA analyst.

Path B — Standalone app (manager / supplier view). Point the app at a folder of .odb files; the bridge runs invisibly as a subprocess; results land in our own 3D viewer + PDF report. No CAE write-back needed. Sells as a separate SKU (review tool / supplier portal / manager dashboard) and shares ~95% of code with Path A — same kernel, same bridge, only the UX wrapper differs. So both ship as separate revenue channels from one codebase.

Path C — where we are today (honest snapshot). Kernel + dashboard are the strongest pieces (done + tested). The bridge wiring (full per-frame export, output-ODB write-back), the real NR-C023A-500 material-card path, and the Wöhler/SN fatigue lookup + temperature field are the load-bearing gaps — the work mapped out in the Part I roadmap.

The two-section flowchart Kailash shared on 2026-05-26 — “Strain Extraction from ODB” + “Durability Evaluation by Wöhler Curve” — is our canonical algorithm spec. Every step maps onto something already in our stack or in active build:

The two formerly-blocked rows (2.2 + 2.3) are now unblocked from the source side — the formulas were recovered in the decompile and are porting 1:1 into Rust. Everything else is either done or actively built. The “thick generic extractor” upgrade to the bridge is the load-bearing piece for the next two weeks.

Done + tested in the all-Rust engine (40 tests passing as of 2026-05-30):

In progress: - Full per-frame ODB export — walk every frame/step and export the called fields. - Output-ODB Nf write-back — inject the computed life field back into a thin output ODB for in-CAE contour (the Path A killer-UX feature).

Next — formulas now in hand from the decompile, not yet wired: - Wöhler S-N — single + multi-slope (v02r single-slope N = Crit^b·A; v02i multi-slope/knee). - Goodman mean-stress correction Seq = Sa·Rm/(Rm−Sm). - Coffin-Manson-Basquin strain-life NE = NEeq + (σf−Sm)/E·N^b + εf·N^c. - Wöhler CSV material-data loader — wire the parsed CTRF-003 curves into the damage path. - Temperature / aging derating — once temperature handling is confirmed (open Q5).

NeoHooke material card NR-C023A-500:

Neo-Hooke is Yeoh with C20 = C30 = 0 — so it drops straight into the existing kernel hyperelastic path, no new code.

Wöhler CSV CTRF-003 (NR-C023A-500):

The whole C023A family shares the slope (per-compound intercepts differ).

Damage conventions — two frames, side-by-side: - CED (Mars/Verron) + Mullins + rainflow — the rubber-physics supplement that catches energy-dissipation Wöhler can’t model. - Basquin HCF + Coffin-Manson LCF + Miner — the established industrial strain-life + cumulative-damage frame (same family that fe-safe ships), now with measured rubber Wöhler curves (exactly what you sent — CTRF-003, 128 rows × 31 compounds), making it rubber-correct for the industrial use-case.

  ElastoForge          ──┬──▶  Thermal-mechanical fatigue (temp coupling)
  (rubber durability)    ├──▶  Multi-axial / weld & bond-line durability
   one Rust core,        ├──▶  Automated design-of-experiments (param sweep)
   one ODB bridge        ├──▶  Other CAE solvers, same bridge (Ansys/LS-Dyna)
                         └──▶  Cloud / batch runs for whole-vehicle ODB sets

Every branch reuses the thin-Python-bridge + all-Rust-engine pattern — no rewrite, just new modules on the same core. Each new CAE vendor gets its own thin bridge; the Rust core is unchanged, so customers running multiple solvers (most Tier-1 OEMs) get one tool that ingests from all of them. A vendor-supplied material library (ship the validated Vibracoustic dataset as a starter, version cards in the SQLite catalog) and a hosted, hash-chained reproducibility tier sit on the same foundation.

The thick-generic-extractor decision. The Python bridge makes no analytical decisions — it is a thick generic extractor that dumps everything from the ODB to open formats (HDF5 numeric arrays + SQLite catalog/metadata + Parquet columnar slices), each content-hashed and Ed25519-signed. The bridge decides nothing; the Rust kernel decides everything. This also moves the reproducibility primitive one level down: reproducibility is content-hashed, not .pyc-tied — the same content-hashed extraction can be fed to your existing VC plugin and our Rust kernel, with a log-diff between the two outputs (stronger than PYC + logs alone, and it works across organisations).

Output-ODB write-back of Nf. Per Kailash’s 2026-05-26 21:47 note — “the funfact is output results is also will be odb. but less size. It consist only those strains which we called” — the Abaqus durability output is itself an ODB, holding only the fields we called. So our pipeline writes the computed life field (Nf) back into a thin output ODB (~50–200 MB) for in-CAE contour, in addition to handling the (4.8 GB-class) input ODB. That round-trip is the Path A in-CAE killer-UX feature.

Two deployment modes from one binary. The same Rust artefact ships as a standalone app and as a plugin installed alongside Abaqus — KERNEL → DASH → standalone and KERNEL ⇢ Nf contour write-back → plugin. Both algorithms (CED + Wöhler-Miner) ship side-by-side; the strain-life model carries the originating method’s name in the dashboard UI.