Instrumentation Standards: An Adopted Base, Not a Rewrite

Instrumentation standards for a refinery should start with applicable legal requirements and adopted industry documents, then add controlled company requirements only where the facility needs a defined choice, restriction, or practice. Country of origin alone is not a valid selection criterion. Jurisdiction, process risk, equipment scope, existing plant conventions, and lifecycle support drive the decision.

Authority and Scope Baseline

Before anything else, confirm which authority governs the facility and what equipment the proposed document will cover. The authority having jurisdiction (AHJ) interprets and enforces requirements adopted for the location. A code or standard becomes mandatory when legislation, regulation, a permit, a contract, or an approved corporate requirement incorporates it.

1. Identify the physical jurisdiction for the refinery, including any authorities responsible for electrical, fire, pressure, environmental, and occupational requirements.
2. Request the current permit conditions, corporate engineering requirements, insurer requirements, and project contract documents.
3. Define the instrumentation boundary: field instruments, analyzers, control valves, shutdown devices, wiring, control systems, installation details, inspection, testing, and maintenance.
4. Record exclusions and interfaces with electrical, piping, mechanical, process-safety, and control-system documents.

Document type	Function	How it becomes binding
Law or regulation	Legal obligation	Issued by the governing authority
Code	Organized requirements for design, construction, or operation	Adopted by an authority, permit, or contract
Industry standard	Common technical rules, methods, interfaces, or practices	Referenced by regulation, contract, or company policy
Company standard	Facility-specific engineering choices and restrictions	Approved through the company document-control process

Do not move on until the scope statement names the governing authorities, mandatory documents, covered systems, and excluded systems.

Source-Document Selection

Select source documents by technical subject and legal status rather than by the country associated with an issuing organization. ISA, API, and IEC publish material for different technical domains; their names alone do not establish applicability. Review each candidate document’s title, scope, exclusions, normative references, and edition status.

1. Build a requirements matrix with one row for each instrumentation subject.
2. For each row, identify the legally adopted requirement first.
3. Add corporate, customer, insurer, and project requirements.
4. Map industry documents to the subjects they actually address.
5. Compare the candidate requirements with installed equipment, maintenance capability, and existing plant conventions.
6. Record the selected edition and the approval basis in the controlled register.

Selection question	Required record
Does an authority mandate it?	Adoption instrument, permit, or regulatory reference
Does its scope cover the equipment?	Applicable subject and stated exclusions
Does another document invoke it?	Normative or contractual reference
Can the plant maintain the resulting design?	Competency, spares, test tools, and documentation impact
Does it conflict with an existing requirement?	Conflict disposition and approving authority

The check is a traceable matrix in which every selected document has a governing reason, applicable scope, controlled edition, and document owner.

Requirements Hierarchy and Conflict Control

Set the hierarchy before drafting technical clauses. A company document cannot cancel a legal requirement, and choosing the apparently stricter clause does not automatically resolve a conflict. Two requirements may use different definitions, test methods, environmental assumptions, or acceptance criteria.

1. Place laws, regulations, permit conditions, and formally adopted codes at the top of the hierarchy.
2. Place contractual and approved corporate requirements below mandatory jurisdictional requirements.
3. Place referenced industry standards and project specifications according to the authority assigned by the contract or corporate system.
4. Define which document controls when requirements overlap.
5. Send genuine conflicts to the designated engineering authority and, where required, the AHJ.
6. Record the decision, technical basis, affected clauses, approver, and date.

Do not combine isolated clauses from several documents without checking their definitions and dependencies. A test criterion may depend on a particular design method; separating the two can create a requirement that cannot be verified.

Release the hierarchy only after a sample conflict can be followed from both source clauses to a signed disposition.

Company-Specific Requirements

Use the company standard to close defined engineering choices, not to reproduce whole industry publications. Incorporate external documents by controlled reference where licensing and document-control rules permit. Write original clauses for site-specific selections such as preferred architectures, tagging conventions, documentation formats, environmental design bases, approved materials, installation practices, inspection points, and maintainability rules.

1. Mark each proposed clause as adopted, supplemented, restricted, or company-specific.
2. State the engineering reason for every deviation from a selected source document.
3. Assign ownership to instrumentation while identifying required reviews by process safety, electrical, mechanical, inspection, operations, and maintenance.
4. Define terminology once and use it consistently across drawings, data sheets, purchase specifications, and test forms.
5. Include a deviation process with requester, technical justification, risk review, approval authority, and permanent record.
6. Apply revision control so projects cannot silently use obsolete editions.

A clause is ready only when a designer can apply it, a supplier can quote against it, and an inspector can determine compliance from an objective record.

Implementation and Acceptance Package

Convert the approved requirements into working project documents. A company standard has little value if its clauses never reach requisitions, drawings, inspection plans, commissioning sheets, or maintenance records.

1. Map each requirement to its implementing document, such as an instrument data sheet, installation detail, purchase specification, inspection checklist, or test record.
2. Define required supplier submittals and the review responsibility for each one.
3. Identify hold points, witness points, measurements, and pass/fail criteria.
4. Train affected engineering, procurement, construction, commissioning, operations, and maintenance personnel on changed requirements.
5. Check existing templates and design tools for conflicting defaults.
6. Run a controlled pilot on a representative instrument package before broad release.

For the pilot, trace selected requirements from the source register through the design document, supplier response, installed item, and acceptance record. Do not move on until every sampled requirement has an owner, implementation location, and measurable acceptance result.

End-to-End Verification

Approve the standard through the company’s engineering-governance and document-control process, then verify it as a complete lifecycle system rather than as a standalone document.

1. Confirm that mandatory jurisdictional requirements appear in the compliance matrix.
2. Confirm that every external reference has a controlled title, edition, owner, and review status.
3. Confirm that conflicts and company deviations have signed dispositions.
4. Confirm that procurement and design templates invoke the approved requirements.
5. Inspect the pilot installation against the issued drawings and acceptance criteria.
6. Execute the applicable functional tests and record actual results, test equipment, responsible personnel, and open defects.
7. Close deviations and defects, update affected records, and verify that operations and maintenance receive the final controlled package.

Final acceptance occurs when a requirement can be traced from its governing source to the approved company clause, issued design, installed equipment, completed test, and retained record.

Frequently Asked Questions