AURA Engineering Platform
Technical Note 06 · Release Evidence

API 684-1 frames rotordynamics as an acceptance program.

Mapping API-style rotordynamics acceptance logic onto AURA evidence gates — and preserving the engineering claim boundary after analysis, acceptance, delivery, and installation.

Document-status note. This note refers to API TR 684-1, 1st Edition, November 2019. The earlier API RP 684, 2nd Edition (2005), is listed by API as withdrawn. “API 684” is used here only as familiar shorthand for this rotordynamics tutorial family.
Practical rule: Under API-style rotordynamics acceptance logic, the need for an acceptance basis is already established. The additional question is how that basis remains attached to the engineering claim — and what the accepted evidence is still allowed to prove when the machine enters a different operating context.

1. What API TR 684-1 already makes clear

API’s current publication catalogue describes API TR 684-1 as a tutorial that explains and clarifies the API standard paragraphs forming a complete rotordynamics acceptance program designed to support equipment mechanical reliability. Its stated scope includes lateral critical speeds, unbalance response, stability, train torsional behaviour, and rotor balancing.

That makes the document more than a list of calculation topics. The calculations sit inside an acceptance context: a defined machine and operating basis, specified analyses, acceptance logic, and responsible engineering interpretation.

AURA interprets this as evidence-program thinking. That phrase is AURA terminology, not an API compliance term. The official API description is rotordynamics acceptance program.

A rotordynamic result is not self-authorising. Its decision authority comes from the basis, assumptions, acceptance logic, and applicability attached to it.

2. Mapping the five AURA evidence gates

The mapping below is methodological. The left-hand side summarises familiar API-style acceptance inputs; the right-hand side shows what AURA makes explicit as a persistent evidence object.

Gate 1

Application fit and acceptance context

API-style acceptance inputApplicable equipment requirements, machine configuration, operating range, required analysis scope, and purchaser / vendor decision context.
AURA evidence objectAn applicability record stating which machine state, duty, speed range, configuration, and decision the evidence is intended to support.
Gate 2

Support architecture and coefficient basis

API-style acceptance inputRotor, bearing, seal, and support representation; stiffness and damping inputs; modelling assumptions; and sensitivity to support behaviour.
AURA evidence objectCoefficient provenance: source method, geometry, clearance, pressure, operating state, interpolation or import path, validation level, and permitted use.
Gate 3

Rotor-dynamic analysis and screening

API-style acceptance inputLateral critical speeds, separation logic, unbalance response, stability indicators, and train torsional analysis where applicable.
AURA evidence objectA claim boundary around each result: what is supported, what remains screening-only, and where higher-grade coefficient provenance, model refinement, or test evidence is required.
Gate 4

Balancing and assembly state

API-style acceptance inputRotor balancing requirements, residual-unbalance basis, balancing procedure, and verification appropriate to the rotor and machine.
AURA evidence objectTolerance, correction, and measurement planes; machine capability; vector repeatability; component-to-assembly transfer; and the boundary between balance acceptance and rotor-system release.
Gate 5

Operating-envelope transfer

Accepted basisThe analysis and test conditions, machine configuration, and assumptions under which the rotordynamic acceptance conclusion was reached.
AURA extensionAn explicit transfer boundary for speed, load, thermal state, process conditions, duty cycle, mounting, controls, and site conditions. This is an AURA evidence-layer extension, not a new API requirement.

3. Where an accepted report can stop speaking clearly

Every acceptance program must draw a boundary. A rotordynamic acceptance file can demonstrate that a machine satisfied its specified analysis and test basis. It cannot automatically give the same claim authority to every later installation, duty cycle, thermal state, process load, control mode, or site condition.

That is not a weakness in the standard. It is a change in decision context.

If the accepted basis is not carried forward explicitly, a familiar attribution problem appears: the machine family and release basis may be nominally the same, while the field context and behaviour are different. Engineering then has to reconstruct the missing boundary after the event.

Design basisDid the machine remain inside the configuration, loads, speeds, and assumptions used for acceptance?
Installation basisDid mounting, alignment, piping, foundations, or site interfaces change the dynamic system?
Operating basisDid duty cycle, process state, transients, thermal conditions, or controls move outside the demonstrated envelope?
Evidence basisWas the original acceptance conclusion applied to a claim or context it was never intended to support?

4. The release-evidence object

For API-governed machinery, the conceptual gap is small. Engineers already work with analysis scope, acceptance criteria, test conditions, and responsible judgement. The procedural gap is preserving them as one reviewable object after the report is accepted.

AURA’s release-evidence object records:

ApplicabilityMachine, configuration, service, speed range, and decision context.
Model basisRotor, support, bearing, seal, coupling, load, and boundary-condition assumptions.
Coefficient provenanceSource, state, validation level, and allowed use of stiffness and damping data.
Dynamic evidenceCritical-speed, response, stability, and torsional outputs applicable to the review.
Balance and assembly statePlane mapping, correction path, measurement context, repeatability, and assembly transfer.
Operating envelopeSpeed, load, thermal, process, duty, installation, control, and site-condition boundary.

The release decision inherits both parts of the record: what was demonstrated, and where that demonstration remains valid.

5. Two claim scopes, two statuses

A machine can satisfy its rotordynamic acceptance basis while still requiring review before that evidence is transferred to a different operating context.

ROTORDYNAMIC ACCEPTANCE BASIS
PASS
OPERATING-ENVELOPE TRANSFER
REVIEW

This is not a contradiction. The first status speaks about the defined acceptance basis. The second asks whether site conditions, duty, thermal state, installation, process loads, and controls remain inside the evidence envelope that supported that conclusion.

AURA does not relax the acceptance program. It preserves the accepted basis and prevents a narrower result from being silently promoted into a broader release claim.

6. Boundary

This note is a methodology mapping, not a compliance statement. It does not claim API compliance or certification. It does not replace API TR 684-1, applicable equipment standards, purchaser specifications, vendor procedures, test requirements, or responsible engineering judgement. It does not assert a deficiency in API documents or in any organisation’s practice.

The term evidence program is AURA’s interpretive framing. API’s public description uses rotordynamics acceptance program. Gate 5 is presented as an AURA extension for preserving and transferring the evidence boundary after acceptance.

The purpose is narrow: to keep a rotordynamic acceptance result attached to the basis that gives it decision authority.

Related AURA evidence work

TN04 · Balancing evidence TN05 · Operating envelope Field Guide v1.1 Sample evidence map Release-evidence architecture

Source and status basis

  1. American Petroleum Institute. 2025 Refining Publications Catalogue. Entry for API TR 684-1, API Standard Paragraphs Rotordynamic Tutorial: Lateral Critical Speeds, Unbalance Response, Stability, Train Torsionals, and Rotor Balancing, 1st Edition, November 2019.
  2. American Petroleum Institute. 2025 Historical Publications Catalogue. Lists API RP 684, 2nd Edition (2005), as withdrawn.
  3. AURA Technical Note 04. “Residual Imbalance Is Not Release Evidence.”
  4. AURA Technical Note 05. “Release Evidence Has an Operating Envelope.”
All technical notes Release-evidence architecture Engineering evidence reviews