Building an Applicability and Requirements Register

Good to see you again. In the previous lesson, you organized the SPP document stack and learned to separate a controlling tariff or agreement from a study manual, planning criterion, FAQ, or Transmission Owner requirement. The next step is to turn that document map into something auditable: an applicability register.

An applicability register is not a bibliography. It records a defensible decision about each individual requirement: what the source says, which version you used, why it applies to this particular project, how authoritative it is, and whether it is mandatory or advisory. This is the traceability layer that should exist before you build a PSS®E case, request an OEM model, or state that a project “meets” an interconnection requirement.

---

Applicability comes before verification

In an ETAP study, a thermal loading or short-circuit duty number becomes meaningful only when you can identify the case, rating basis, assumptions, and acceptance criterion. Requirements work has the same discipline, but it starts earlier.

There are two different questions:

1. Applicability: Does this requirement govern this project, project stage, operating mode, facility, or study?
2. Verification: What evidence demonstrates that the applicable requirement has been satisfied?

The applicability register answers the first question. Later, it will feed the traceability matrix for MQT reports and interconnection deliverables, where you will connect a requirement to a simulation case, plot, measured result, and conclusion.

A useful register prevents several common failures:

• applying a requirement from an obsolete revision without noticing;
• treating a regional manual as though it were a tariff, contract, or mandatory reliability standard;
• omitting a requirement because it applies only to BESS charging, a particular voltage class, or a later interconnection stage;
• calling a recommendation mandatory merely because it appears in an official-looking manual; and
• building a technically sound model-quality test that does not match the project’s governing acceptance basis.

---

The three decisions in every register row

A well-built row makes three separate decisions. Do not merge them into a vague note such as “ERCOT MQT requirement” or “SPP voltage criterion.”

Decision	The question to answer	Example of a defensible entry
Authority	Who issued this requirement, and what gives it force?	“ERCOT Planning Guide requirement,” “NERC Reliability Standard,” “SPP OATT Attachment,” “executed interconnection agreement,” or “Transmission Owner planning criterion.”
Applicability	Which project fact activates the requirement?	“Applies because the project is an ERCOT Energy Storage Resource above the stated size threshold,” or “Applies only upon submission of an FIS request.”
Mandatory or advisory status	Is compliance required, recommended, permitted, or subject to another document?	“Mandatory if this revision governs,” “advisory guidance,” or “mandatory only where incorporated by the FIS agreement.”

The wording of a clause helps, but it is not the complete answer:

• “Shall,” “must,” and “required” normally signal an obligation when the source is authoritative and the applicability condition is met.
• “Shall not” is a prohibition and should be treated as mandatory.
• “Should” usually signals guidance or an expectation, not an unconditional requirement.
• “May” normally grants discretion or permission; it is not an obligation.
• A manual’s “should” can become binding if a tariff, study agreement, commissioning procedure, or executed interconnection agreement explicitly incorporates it.

That final point matters in renewable interconnection work. A detailed Dynamic Model Working Group procedure may be the accepted technical method for demonstrating a requirement, while the Planning Guide or a project agreement supplies the underlying obligation. Your register should preserve that chain rather than claiming that every sentence in a manual has the same authority as a governing rule.

One row should represent one testable obligation

Do not make one row for “ERCOT Planning Guide Section 6.” That section contains distinct requirements concerning steady-state models, dynamic models, short-circuit cases, confidentiality, model updates, and more.

Instead, split the source into atomic entries such as:

• provide an appropriate dynamic model compatible with the prescribed planning software;
• provide model-quality-test results and associated simulation files;
• include all site-specific dynamic models in the tests;
• perform the specified test types;
• provide an explanation where model responses do not match; and
• submit updated information after a model revision.

Each row should survive independent review. A reviewer should be able to ask, “Does this particular obligation apply?” and reach a clear answer without having to interpret five unrelated requirements at once.

---

Read a governing source as a register builder

The supplied ERCOT Planning Guide is intentionally useful for this lesson because it shows several layers of requirements in one document: an applicability gate, process requirements, study-stage requirements, and technical performance criteria. Its dates also demonstrate why a register must capture the revision of the specific section, not just the name of a document.

The key lesson from this reading is that a document title does not tell you enough. “ERCOT Planning Guide” is not the actual requirement. A useful record is closer to:

ERCOT Planning Guide, Section 6.2(5)(c), specified revision and effective date, requiring model-quality-test results and associated simulation files for a Facility owner providing dynamics data; applicable to the planned solar-plus-BESS facility’s dynamic-model submission.

That statement contains a source, a location, an obligation, and an applicability rationale. It can be reviewed, challenged, updated, and ultimately verified.

---

The minimum register structure

Use a spreadsheet initially, but structure it as though it will become a controlled project database. The required fields are in bold below; the supporting fields make the required fields usable in practice.

Identity and source-control fields

Field	What to record
Requirement ID	A stable internal identifier, such as ERC-DYN-005 or SPP-GI-014. Do not encode a revision number in the ID.
Requirement statement	A short, faithful restatement of one obligation. Retain an exact quotation in a notes field when wording is legally or technically sensitive.
Source	Issuing organization, document title, and document type. For example: “ERCOT, Planning Guide,” “SPP, OATT Attachment V,” or “Host TO, Planning Criteria.”
Revision	Formal revision number, effective date, publication date, and access date. For project agreements, record execution date and amendment number.
Section	Section, subsection, paragraph, table, figure, and page number where available. A section citation without a paragraph is often too broad.
Controlled-copy location	Approved repository, document-management identifier, or confidentiality-controlled data-room location. Do not paste CEII or protected content into an uncontrolled spreadsheet.

Decision and management fields

Field	What to record
Authority	The authority category and its relationship to the project. Examples include NERC Reliability Standard, FERC-filed tariff, ISO/RTO planning requirement, Transmission Owner criterion, executed agreement, procedure manual, or OEM documentation.
Applicability	The trigger, scope, and factual evidence. State why the requirement applies, does not apply, or remains conditional.
Mandatory or advisory status	Use a controlled value such as Mandatory, Advisory, Conditional Mandatory, Not Applicable, or Needs Clarification.
Applicability confidence	Verified, preliminary, or unresolved. This avoids presenting an assumption as a settled conclusion.
Evidence needed	The eventual proof: a RIOO submission receipt, executed agreement, PSS®E case, PSCAD result plot, model file, calculation sheet, or written utility confirmation.
Responsible party and due stage	Project developer, OEM, consultant, Transmission Owner, or ISO/RTO; then application, study, commissioning, periodic maintenance, or model-update stage.
Cross-references	Linked requirements, agreement clauses, study-scope items, model-data requests, or report sections.
Change trigger	A new document revision, POI change, BESS charging change, service election, project-size change, model revision, or agreement amendment.

The bold fields satisfy the minimum learning outcome. The additional fields keep the register from becoming a static list that no one can act on.

Record a document revision precisely

“Current ERCOT Planning Guide” is not a revision entry. It is an unresolved claim.

A stronger revision record looks like this:

ERCOT Planning Guide; Section 5 dated April 1, 2023 in supplied controlled copy; retrieved on project date; current effective status to be confirmed through ERCOT’s controlled document repository.

Notice the distinction between:

• document title;
• section-level revision or effective date;
• the date you accessed the copy; and
• your conclusion that it is currently governing.

The supplied Planning Guide itself contains material with different section dates. That is not an administrative nuisance; it is exactly why source control belongs in the technical workflow.

---

Authority is a relationship, not a rank label

A practical authority taxonomy for U.S. interconnection studies is shown below. The precise legal hierarchy can vary by region and project, so use this as a classification framework rather than as a substitute for legal interpretation.

Authority category	Typical role in the register	Typical status
Law, regulation, or regulatory order	Establishes legal obligations or eligibility restrictions	Mandatory where applicable
NERC Reliability Standard	Establishes reliability obligations for registered entities and applicable facilities	Mandatory where applicable
FERC-filed tariff or ISO/RTO tariff	Establishes formal service, interconnection, study, and agreement processes	Mandatory where applicable
ISO/RTO protocol, planning guide, or operating guide	Establishes regional technical, data, and process obligations	Often mandatory where explicitly applicable
Regional planning criterion	Establishes study-performance criteria and planning assumptions	Mandatory for the defined planning study where applicable
Transmission Owner criterion	Adds local ratings, facility, protection, voltage, or clearing-time requirements	Mandatory where applicable; may be more restrictive
Executed study agreement or interconnection agreement	Establishes binding project-specific scope, milestones, deliverables, and commitments	Mandatory for the parties
Procedure manual or business practice	Explains approved implementation methods and detailed procedures	Often mandatory only when incorporated or referenced by a governing source
FAQ, presentation, training material, or OEM application note	Explains, interprets, or recommends	Advisory unless incorporated into a binding document

Do not resolve a conflict mechanically by selecting the “highest” source and deleting the rest. A Transmission Owner criterion may be more restrictive than a regional default and therefore control the specific facility. A study agreement may make a general process requirement concrete for a particular project. If two documents appear inconsistent, preserve both rows, record the conflict, and request written clarification from the party with authority to interpret the requirement.

---

Example: an ERCOT solar-plus-BESS register

Assume a training scenario: a proposed transmission-connected ERCOT facility consists of 300 MW of solar and 150 MW of BESS at a 345 kV POI. The project is preparing for interconnection and may request a Full Interconnection Study. This is not a claim about an actual project’s governing documents; it is a structured example of how to populate the register.

Source and authority portion

ID	Atomic requirement statement	Source, revision, and section	Authority
ERC-GIM-001	Use the Generator Interconnection or Modification process when the facility meets the stated generator or ESR applicability threshold; identify whether it is a large generator.	ERCOT Planning Guide, supplied Section 5 dated April 1, 2023; Section 5.2.1(1) through (3), pp. 5-1 to 5-3.	ERCOT Planning Guide requirement.
ERC-GIM-002	Initiate a qualifying GIM through RIOO with the required request information, documentation, and fee.	ERCOT Planning Guide, supplied Section 5 dated April 1, 2023; Section 5.2.2(1) and (4), pp. 5-3 to 5-4.	ERCOT Planning Guide requirement.
ERC-FIS-003	Submit prescribed Resource Registration information, including applicable dynamic-model and model-quality-test material, to initiate an FIS.	ERCOT Planning Guide, supplied Section 5 dated April 1, 2023; Section 5.3.2(3)(b), pp. 5-13 to 5-14.	ERCOT Planning Guide requirement.
ERC-FIS-004	Identify the actual study elements, scenarios, and base cases in the FIS agreement and study scope.	ERCOT Planning Guide, supplied Section 5 dated April 1, 2023; Section 5.3.2.3(1), p. 5-17.	ERCOT Planning Guide requirement, implemented through project-specific FIS agreement.
ERC-DYN-005	Provide dynamic data, MQT results, and associated simulation files for the planned facility.	ERCOT Planning Guide, supplied Section 6 dated April 1, 2023; Section 6.2(5)(a) through (c), pp. 6-3 to 6-5.	ERCOT Planning Guide requirement.
ERC-MQT-006	Test BESS at full real-power withdrawal in the MQT simulation setup.	ERCOT DWG Procedure Manual, Revision 20, ROS-approved date indicated in supplied filename; Section 3.1.5.1, “Simulation Set Up.”	ERCOT procedure-manual guidance supporting the Planning Guide’s MQT requirement.
ERC-PLAN-007	Meet the specified steady-state voltage criterion for transmission-level buses above 100 kV in the defined planning conditions.	ERCOT Planning Guide, supplied Section 4 dated June 1, 2022; Section 4.1.1.4, pp. 4-5 to 4-6.	ERCOT planning-performance criterion.

Applicability and status portion

ID	Applicability conclusion and factual basis	Mandatory or advisory status
ERC-GIM-001	Applicable, pending current-revision confirmation. The proposed facility includes solar generation and an Energy Storage Resource well above the stated threshold. Record solar injection, BESS discharge, and BESS charging limits separately.	Mandatory if the cited revision remains governing.
ERC-GIM-002	Stage-conditional. It applies when the developer initiates the GIM; it is not evidence that an application has already been submitted.	Mandatory at GIM initiation.
ERC-FIS-003	Stage-conditional. Applies when the project requests an FIS. It creates a forward data-deliverable obligation, not necessarily an immediate submittal obligation during early siting.	Mandatory at FIS initiation, subject to the current applicable procedure.
ERC-FIS-004	Applicable once the FIS scope exists. The Planning Guide establishes the need for the project-specific scope; the signed FIS agreement identifies the actual case years, scenarios, studies, and deliverables.	Mandatory process control; project-specific details are governed by the agreement.
ERC-DYN-005	Applicable. A planned solar-plus-BESS facility will require facility dynamic representation. The exact model family, software release, and test matrix require confirmation against the current DWG procedure and project scope.	Mandatory if the facility is submitting dynamics data under the governing Planning Guide.
ERC-MQT-006	Applicable guidance. The facility includes BESS, so charging or withdrawal operation must be considered. However, the cited text uses “should,” not “shall.”	Advisory as written; becomes mandatory only if adopted by a controlling requirement, study scope, or agreement.
ERC-PLAN-007	Applicable to the 345 kV POI planning assessment. It applies only to the stated voltage class and contingency categories. Check whether a Transmission Service Provider has a more restrictive approved local criterion.	Mandatory planning criterion if the cited section is current and no more restrictive applicable criterion supersedes it.

The most important distinction is between rows ERC-DYN-005 and ERC-MQT-006. The Planning Guide states the obligation to provide model-quality-test results and files. The procedure manual describes detailed test setup and expected practices. They are connected, but they should not be assigned identical authority and status without confirming the incorporation path.

---

Trace the technical procedure back to its governing requirement

The Dynamic Working Group procedure illustrates how to document that incorporation path. Its MQT material is highly relevant to the later PSS®E and PSCAD modules, but a register should identify whether a particular detail is an explicit obligation, a technical expectation, or guidance subject to project-specific direction.

For example, the procedure manual says submitted models must be accompanied by MQT results, simulation files, and plots, while the Planning Guide establishes that Facility owners must provide MQT results and associated simulation files. A robust register records both:

• the Planning Guide row as the primary data-submission obligation; and
• the DWG procedure row as the technical method and test-definition source, with its authority linked back to the Planning Guide reference.

This becomes especially valuable when a utility reviewer asks why a PSCAD test was included, why an omitted test was considered inapplicable, or why the PSS®E and PSCAD cases used a particular BESS charging condition.

---

A repeatable method for building the register

Use the following sequence every time you receive a new regional document set, study agreement, or Transmission Owner requirement.

1. Freeze the project facts first.
   Record the project type, POI/POD, voltage, host utility or Transmission Owner, queue stage, requested service, solar capacity, BESS discharge and charging capability, data-center load characteristics where relevant, and target in-service year. Cite the version of the project data sheet used.

2. Capture the controlled source.
   Save the document title, issuing body, revision, effective date, access date, section, page, and controlled location. For confidential cases, record the authorized package name and release notes without copying protected information into an open register.

3. Atomize the clause.
   Create one row per obligation, criterion, prohibition, deliverable, or conditional requirement. Preserve the original context so that a short paraphrase does not alter the meaning.

4. Identify the authority path.
   Ask whether the requirement is direct, incorporated by reference, project-specific, or merely explanatory. Record cross-references explicitly. For example, an MQT procedure can be linked to a Planning Guide data-submittal requirement.

5. Write an applicability statement using project facts.
   State both the trigger and the evidence. “Applies to BESS” is weak. “Applies because the project permits 150 MW transmission-system charging, and the FIS scope includes charging-mode evaluation” is reviewable.

6. Assign status without overstating certainty.
   Use controlled statuses such as:

   • Applicable — Mandatory
   • Applicable — Advisory
   • Conditional — Mandatory when trigger occurs
   • Not Applicable — documented rationale
   • Needs Clarification — written interpretation required

7. Specify verification evidence and change triggers.
   A requirement that will later be verified through a PSS®E plot should say so. A requirement affected by a change in POI, project size, OEM controller version, or BESS charging rights should be flagged for re-review.

Preserve “not applicable” rows

Do not delete a requirement just because it does not apply. Retain it with a concise rationale.

For example:

Status: Not Applicable.
Rationale: PSCAD phase-angle-jump testing is not required for this PSS®E-only screening study; however, it will be revisited if an ERCOT PSCAD MQT package is required.

This record demonstrates that the requirement was considered deliberately. It also creates a future trigger when the project advances into EMT or PSCAD work.

---

Maintain the register as a living technical control

The register should be reviewed whenever any of the following changes:

• an ISO/RTO, NERC, WECC, SPP, ERCOT, or Transmission Owner document is revised;
• the project changes POI, voltage, requested MW, in-service date, service election, or queue position;
• BESS charging from the grid is added, removed, or limited;
• a project proceeds from screening to interconnection application, cluster study, FIS, facility study, commissioning, or operations;
• the OEM changes inverter hardware, protection settings, PPC firmware, or dynamic/EMT model version;
• an agreement, study scope, or utility interpretation is issued or amended; or
• an identified planning criterion is replaced by a more restrictive local requirement.

For a multi-region developer, maintain one master structure but do not force all regions into identical assumptions. An ERCOT MQT requirement, an SPP DISIS methodology item, a WECC/NERC planning criterion, and a host Transmission Owner protection requirement can all use the same columns while retaining their different authority paths and applicability triggers.

---

Key takeaways

• An applicability register is a controlled record of which requirements govern, not merely a document list.
• Each row should contain one atomic requirement and, at minimum, its source, revision, section, authority, applicability rationale, and mandatory-or-advisory status.
• Authority, applicability, and mandatory status are separate decisions. A highly authoritative requirement may not apply; a procedure manual may become mandatory only through incorporation; a recommendation can become binding through an agreement.
• Record revision and effective-date information precisely. “Current document” is not a defensible revision entry.
• Preserve conditional, unresolved, and not-applicable entries rather than silently omitting them.
• The register is the bridge from interconnection requirements to technical evidence: PSS®E cases, PSCAD tests, model files, plots, study reports, and final conclusions.

Next, you will use this register to create a minimum technical-data request checklist for solar, solar-plus-BESS, standalone BESS, and data-center projects.