Mechanical Design Standards in NeqSim

NeqSim catalogs standards that may be relevant to process-equipment design. Catalog inclusion is not a statement that every requirement or calculation in a published standard has been implemented. The matrix below reports the calculation evidence that currently exists in NeqSim.

Maturity definitions

Maturity	Meaning
`CATALOGUED`	Standard identity, edition metadata, category, and equipment applicability are available, but no standard calculation is exposed.
`SCREENING`	A preliminary engineering calculation is available with the boundary stated in the matrix. It is not a conformity assessment.
`VALIDATED`	The stated calculation range has independent numerical validation and controlled regression evidence.
`QUALIFIED`	A controlled implementation and evidence package has been released for a stated use. Accountable engineering approval is still required.

No current entry is classified as VALIDATED or QUALIFIED. Existing calculations remain useful for preliminary screening, but project criteria, purchased standards, vendor data, and engineering review remain governing.

Current support matrix

The table between the generated markers is produced by StandardSupportAudit.generateMarkdownTable(). A regression test fails if the published table and the source catalog diverge.

Typed standard selection

New code can select an explicit current edition without depending on the registry’s process-wide version overrides:

StandardSelection selection = StandardSelection.strict(StandardType.API_521);
mechanicalDesign.setDesignStandard(selection);

StandardSelection.strict(...) requires a publisher-verified current edition and an exact typed kernel. It fails closed with a StandardSelectionException when the lifecycle is unverified, the edition is superseded or not current, the exact kernel is missing, the equipment context is missing, or the standard is not listed for that equipment type. The exception exposes a machine-readable reason so applications do not need to parse its message.

Use StandardSelection.historical(...) only for a controlled compatibility calculation whose exact non-current edition is implemented. It retains applicability and kernel checks but makes the historical basis explicit. StandardSelection.strictRegistry(...) is the transitional factory path; it verifies the current lifecycle, implementation maturity, registry connection, and applicability without claiming an edition-specific typed kernel.

Executable strict and historical selections reject project amendments until the selected kernel or requirement pack explicitly implements them. StandardSelection.legacy(...) can retain amendment metadata during migration, but doing so does not apply the amendments to a calculation.

StandardRegistry.assessApplicability(...) provides the applicability decision without creating a standard.

StandardSelection.legacy(...) is available for migrations that need an explicit edition while retaining the permissive factory behavior. It may create a metadata-only DesignStandard; it does not add calculation support.

Process-global setVersionOverride(...) and clearVersionOverrides() are deprecated. New code should retain a StandardEdition in each StandardSelection, then call StandardRegistry.requireDesignKernel(selection) when an executable implementation is required. The require call distinguishes missing kernel support from an unsupported edition. See the typed-kernel migration guide for a staged compatibility path.

Consolidated design kernels

EquipmentDesignKernel<I, O> extends the existing typed engineering-calculation contract with the implemented standard, audited maturity, and structured applicability. Kernels must not mutate their input or a ProcessSystem. Compatibility adapters defensively copy legacy mutable calculators.

StandardRegistry.getDesignKernel(...) returns an explicit lookup status. API 617, API 610, API 521, API 526, and API 12J have connected adapters and return IMPLEMENTED; standards that have not been adapted return NOT_IMPLEMENTED, never an empty or implied success. Each kernel returns an immutable assessment snapshot and always requires engineering review because its maturity remains SCREENING. Unsupported editions fail closed as EDITION_NOT_IMPLEMENTED until separately implemented and validated.

Only API 521 currently has both a publisher-verified current lifecycle and a matching exact kernel. API 526, API 617, API 610, and API 12J adapters implement legacy edition labels that do not match the current catalog editions; they are available only through an explicit historical selection until current-edition kernels and independent benchmark evidence are added.

The API 521 adapter defensively copies the mutable protected-item basis, requires at least one complete credible scenario, selects the governing rate, and records the sizing and accumulated pressure checks. The API 526 adapter accepts an explicitly unit-tagged required area and reports an inadequate result when a single standard orifice cannot cover it. These adapters do not establish scenario completeness or qualify valve construction, installation, reaction loads, flare-network effects, or vendor certification.

The API 617 adapter defensively copies a compressor-casing configuration before evaluating pressure containment, hydrotest, flange-rating, nozzle-load allowance, and thermal-growth screens. The API 12J adapter uses explicitly unit-tagged cut diameter together with K-factor and liquid residence time. Passing either result is not a package, vessel, or performance certification.

Cross-equipment requirement packs

Some standards express requirements across equipment, calculations, documents, and lifecycle activities and cannot honestly be represented by one DesignStandard subclass. Immutable StandardRequirementPack records make the existing NeqSim calculation and review capabilities discoverable without copying licensed standard text or implying complete conformity.

StandardSelection selection = StandardSelection.strictRequirements(StandardType.NORSOK_P_002);
StandardRequirementPack requirements = StandardRegistry.requireRequirementPack(selection);

Each capability declares whether it is a calculation screen or a review workflow, its implementation class, and its engineering boundary. Packs currently map NORSOK P-002, NORSOK S-001, NORSOK M-001, API 520 Part 1, API 650, API 660, DNV-ST-F101, ISO 10418, IEC 61511, and IEC 60534. Strict lookup still fails when the lifecycle is unverified; IEC 60534 therefore remains discoverable in the audit but cannot be selected as a verified current requirements basis.

Requirement packs are navigation and orchestration metadata. They do not contain publisher requirements, prove coverage, execute every mapped capability, or replace a project requirements register and independent conformity assessment.

How to interpret the registry

StandardRegistry.createStandard(...) remains backward compatible. The factory class shown in the matrix records what it currently creates; it does not prove that the resulting class implements the selected edition. StandardRegistry.getMappedImplementationClass(...) allows applications and audits to inspect that mapping without constructing equipment or accessing the design database.

The API 610 pump screen remains available through PumpMechanicalDesign. The consolidated PumpApi610DesignKernel is a pure adapter over the same calculator, so existing callers are not removed or redirected. The generic legacy factory still creates a base DesignStandard; executable kernel support is exposed explicitly through StandardRegistry.getDesignKernel(...).

Engineering boundary

Treat CATALOGUED entries as discovery metadata only.
Treat SCREENING results as preliminary design information with the stated boundary.
Do not infer certification, code compliance, vendor acceptance, or construction readiness.
Record the purchased edition, project amendments, input provenance, and accountable approval outside the current legacy registry.
Use the standards implementation program to prioritize current-edition kernels, benchmark evidence, and requirement coverage.

See the engineering capability statement for the broader process-to-engineering workflow and its qualification boundary.