Description of Entities and Their Properties

This data and technology standard contains 9 entities; beneath each entity is a list of properties. Agencies could generally determine which properties are required for a given entity - the asterisks (*) below are suggestions for required properties. A property may also be “required” but only if applicable in a given situation or system. Note that all entities have a unique identification number property representing the record in a database as well as an identifier that can be shared across systems. All database IDs should be unique within the agency or component and entity; agencies should strongly consider using a universally unique ID (UUID). In some cases, it may be best practice to use an established standard-based ID, such as a Document Object Identifier for documents or datasets. CEQ’s recommended unique ID format for NEPA documents is represented as the “Federal Unique ID” listed under the “Process” entity. Other properties may vary in data type (e.g., paragraph text, alphanumeric, true or false) and length.

The properties below represent the minimum expected data fields (whether those fields are null or contain content); agencies are also free to add additional fields to share more data, such as “Other” or “Notes”, as well as more specific agency data if it adds context or improves communication and data sharing among systems. In this version of the data and technology standard, the allowed values of properties are rarely specified to allow maximum flexibility for agencies implementing this standard (i.e., there are no enumerated lists to pick from). Future versions of this data and technology standard may include partial or complete standardization of values, depending on the entity and property.

Entity 1: Project

A Project represents the agency’s activity or decision requiring initiation of a review or permit process. A project may have a relationship to multiple processes (i.e., NEPA review, permit application, or interagency consultation) which each contain information relevant to that specific NEPA or permit process (e.g., agency roles, milestones) - see Entity 2: Process.

Properties:

• Project ID*: Unique identification number1.
• Parent Project ID: Identification number of parent project, if applicable.
• Project Title*: Descriptive name of the project.
• Project Description*: Summary of the project’s goals and scope, which could include structured text required by the agencies for specific processes or remain at a high-level project description.
• Project Sector*: High-level project category (e.g., energy, transportation, land management). Sector may be specific to the agency. There is currently no enumerated list to select from, although agencies may use lists such as the sectors for FAST-41 covered projects; this field can be considered a “tag” to aid organization.
• Project Type*: A sub-type of project sector (e.g., pipeline, highway, habitat restoration), if applicable. There is currently no standard list to select from; this field can be considered a “tag” to aid organization.
• Project Sponsor*: Name of responsible entity, organization, or person and contact card information. Value of this field could be “None - action is led by the lead agency”.
• Lead Agency*: Federal agency that is undertaking the activity or responsible for the decision.
• Participating Agencies: Other agencies involved in the activity (distinct from agencies involved in the process; see below for more detail).
• Location: Geographic area, including relationship to GIS Object, optionally also stored as a simple property here (e.g., latitude / longitude coordinates of the centroid of the project footprint). Where location is more complex than a point or is multi-state or regional, could be a text response.
• Funding Source(s) or other Project Reference: Link to federal, state, local or other funding source(s) by reference (e.g., grant program, loan guarantee, appropriated funds).
• Properties aggregated from relationships (e.g., from processes):
  • Start Date: Initiation date for the related review or permit process (as defined by the agency and automatically pulled from related process status).
  • Current Status: Current phase (e.g., pre-application, in progress, paused, completed, cancelled) of the NEPA, permitting, or other authorization process (may be aggregated from related process status and related milestones or events).

Entity 2: Process

A Process refers to the environmental review, permit, or authorization that an agency is conducting, issuing, or otherwise completing as part of the decision-making process. A process is associated with, or nested beneath, a project – see Entity 1: Project. A process will also have documents associated with and nested beneath it – see Entity 3: Documents. A type of process may have a defined model associated with it that defines the workflow steps of the process and any relevant decision criteria for the process that is available in a machine-readable format. In implementation, agencies should distinguish a specific “Process Instance” from a generic “Process Model” – see Process Model below.

Properties of the Process Instance:

• Process ID*: Unique identification number for the process within a project.
• Parent Process ID: If applicable, reference to Process ID of parent process (for example, an earlier NEPA process that resulted in a programmatic analysis that the agency is tiering from for the new NEPA review).
• Related Project ID*: Reference to Project ID of parent project (see Entity 1 – Project).
• Agency ID: Process-specific ID assigned by agency, if assigned.
• Federal Unique ID: Unique identification number
• Process Type*: Level of NEPA review or other permit or authorization (for reference see Federal Environmental Review and Authorization Inventory).
• Process Status*: Indicates status of process (planned, pre-application, in progress, paused, completed, cancelled).
• Process Stage: Current stage of process, may be derived from the last case event with this Process ID.
• Process Description: Optional description of the process (distinct from project description).
• Purpose and Need: Optional purpose and need of the process.
• Start Date: Initiation date (may be aggregated from a related case event for the process, as defined by the agency); may be split into target date/actual date/original target date fields, although these are best stored in Case Events (see Entity 6: Case Events).
• Completion Date: Conclusion date (may be aggregated from a related case event for the process, as defined by the agency); may be split into target date/actual date/original target date fields, although these are best stored in Case Events (see Entity 6: Case Events).
• Process Outcome: Result, if applicable (e.g., Record of Decision (ROD), permit issuance).
• Public Comment Period: Start and end dates of time frame for public input.
• Lead Agency*: Federal or other agency that is responsible for conducting, supervising, or facilitating this process.
• Joint Lead Agency: If applicable.
• Cooperating Agencies: Cooperating agencies.
• Participating Agencies: Other involved agencies.

Process Model:

A process model is the “template” for a specific process, such as how an agency prepares an environmental impact statement (EIS). In the data model it refers to a coded representation of this generic process, ideally in a machine-readable format such as business process model notation (BPMN), and/or screening criteria that define when or if a process is relevant to a project. Agencies may not yet have process models developed in a machine-readable format; however, agencies can develop process models to represent the existing or future process by which an agency conducts a NEPA or permit review process. Process models contain decision elements (i.e., criteria for either starting the process or advancing/finishing decision trees within the process) and a provision for data to be exchanged at certain steps in the process to support automated pre-screening or use of decision support tools.

Properties of the Process Model:

• Process Model ID*: Unique identifier for the process model.
• Title*: Name of process model.
• Description*: Plain language description of the process model.
• Agency*: Agency responsible for carrying out this process.
• BPMN Model: If applicable or available, a BPMN representation of the process model.
• Legal Structure ID: Reference to ID of the legal structure that defines the business rules for the overall process (see Entity 9: Legal Structure).
• Screening Description*: Plain language description of the screening criteria that would lead to starting the process for an individual project.
• DMN Model: If applicable or available, a top-level Decision Model Notation representation of the inputs and outputs of the process.
• Decision Elements*: An array of objects that describe conditions (or criteria) for starting a process or resolving a decision tree within a process, including GIS screening.
  • Decision Element ID*: Unique identifier for the decision element.
  • Legal Reference: If applicable, citation for the legal structure related to the specific criteria; this may be the ID of a Legal Structure entity (see Entity 9: Legal Structure).
  • Title: Name of decision element.
  • Description*: Plain language description of the condition.
  • Category: An option to specify the category of the decision element, for example to distinguish threshold-based conditions (i.e., acreage limitations) from other types of conditions (i.e., extraordinary circumstances).
  • Process Model Reference: An option to specify where in the process model this decision element is used (if there are many steps or decision trees).
  • Measure: If applicable, a description of the type of thing being measured in the condition (e.g., threshold of contamination).
  • Threshold: Numeric value of the triggering measure (if applicable).
  • Spatial Indicator*: Identifies whether the condition is a spatial relationship.
  • Intersect: Identifies whether the spatial relationship is a simple intersection (e.g., floodplain).
  • Spatial reference: A container for reference to the screening criteria (e.g., API call for wetland data).
  • Form text: Text data to display on a screening form for a user to input data.
  • Form response: A description of the type of response expected on the form (e.g., text, select from list, number).
  • Evaluation method*: A description of how the response is matched against the condition and what the results could be, shared as free text or Decision Model Notation formulation.

Process Model Decision Elements and Decision Payload:

The process model and its decision elements form the template and logic structure of how a specific project moves through the process. The elements specify what information needs to be collected to complete the process. This could include simple yes/no questions as well as more complex requirements such as a Purpose and Need statement. The data from a specific project and the evaluation response is contained in a payload, which primarily has a relationship with a specific Process Instance.

Properties of the Decision Payload:

• Decision Payload: An array of data elements that deliver responses to and/or results of the evaluation criteria above.
  • Decision Payload ID*: Unique identifier for the decision payload.
  • Decision Element ID*: Reference to Decision Element ID for the relevant decision element.
  • Related Process ID: Reference to Process ID for related process (if applicable).
  • Related Project ID: Reference to Project ID for related project that the data is associated with.
  • Data Description*: Text of the data about the project in response to the evaluation condition.
  • Data Annotation: Additional context for the data payload.
  • Response*: Text description of the response from the evaluation mechanism (returned by an evaluation system; not included in submission).

Entity 3: Documents

Documents are created during the environmental review, permit, or authorization process. A document will have a relationship with a process – see Entity 2: Process. Agencies may track official records only (e.g., a record of environmental consideration or EIS) or use this data structure to track any documents associated with a process (e.g., supporting documents that were created as part of the environmental review).

The data object for the document includes metadata that identifies the document and its context and a container for summary information from the contents of the document that lays out, at a minimum, the table of contents (or heading structure) of the document - see Document Structures.

Documents are also likely to have many GIS objects associated with them that provide information on the physical footprint of the project or the analysis conducted. In published documents these GIS objects are typically flattened to images but could be represented as data that is stored along with a published document for future reuse – see Entity 7: GIS Data. The document entity is flexible enough to accommodate datasets or other types of content if agencies choose to track these in NEPA or permitting systems.

Properties:

• Document ID*: Unique identification number for the document.
• Related Process ID*: Reference to Process ID of parent process for the document.
• Related Case Event ID*: Reference to Case Event ID of event in the process that the document is related to, if applicable.
• Related Document ID: If applicable, any related documents (for example, an EIS might reference the NOI here).
• Document Type*: For example, NOI, EIS, supplemental EIS, programmatic EIS, ROD, environmental assessment, finding of no significant impact, categorical exclusion determination, other documentation or memorandum to file, etc. Documents may include working documents, drafts, etc. if agencies choose to record these as well.
• Title*: Document title.
• Volume Title: Volume title (e.g., Appendix).
• Document Revision: Indicates which revision of the document (e.g., first revised Draft EIS).
• Supplement Number: If the document is a supplement to another document, this indicates the sequence number of the supplement.
• Publish Date: Publication or submission date.
• Prepared By*: Responsible entity.
• Contributing Agencies: Identifies agencies that contributed to preparation or review of the document.
• Status: Document production phase.
• Public Access: Disclosable or non-disclosable.
• URL: Online link if available.
• Related Document IDs: Unique identification number for related document(s).

Entity 4: Comments

Comments include feedback submitted by individuals or organizations. A comment has a relationship with a document that the individual or organization is providing feedback on as part of a specific environmental review or permit process. This data structure for comments is meant to accommodate both the entire original communication from a commenter and any extracted specific comments; if applicable, this may be supported by nesting comments using parent/child relationships. Agencies that manually organize and review comments could implement this data structure manually. Alternatively, agencies could incorporate this data structure into automated comment processing systems. This data structure may also be used to track grouped comments with a single reply or other aggregation of comments that the agency conducts.

Properties:

• Comment ID*: Unique identification number.
• Commenter Name*: Individual or organization.
• Organization: Optional organization field.
• Category: Optional category to organize types of comments or to tag comments based on the topics addressed in the comment.
• Content*: Text of the comment.
• Date Submitted*: Submission date.
• Related Document ID*: Reference to Document ID of the document to which the comment is related.
• Related Process ID: Reference to Process ID of the process (or processes) to which the comment is related.
• Method of Submission*: Online, email, mail, in-person.
• Document location reference: If applicable, the part of the document being referenced by the comment.
• Agency Response: Formal reply, if applicable.
• Public Access: Public or internal to agency.

Entity 5: Public Engagement Events

Opportunities for interaction in the environmental review or process, including consultation. This entity is meant to be distinct from case events, which are specific points in time when something has happened; it should document windows for involvement such as public meetings, consultations, etc. This entity is designed to be flexible and may not be applicable to all processes or agencies.

Properties:

• Event ID*: Unique identification number.
• Type*: Public meeting, notice, solicitation.
• Date*: Event date and time, to include start and end dates if applicable.
• Location: Physical, virtual, hybrid. (Note that this may also be encoded as a relationship with a GIS object).
• Related Process ID*: Reference to Process ID of the associated process(es) for this event.
• Related Document IDs: Reference to Document ID of the documents released or referenced for this event.
• Attendance: Participant count.

Entity 6: Case Events

A case event represents a milestone or step within the environmental review or permit process and is typically tracked in a case management system or other system for task management or a reporting dashboard. A case event will have a relationship to a specific process – see Entity 2: Process.

Properties:

• Case Event ID*: Unique identification number for the case event, assigned by the system.
• Related Process ID*: Reference to Process ID of the associated environmental review or permit process for this event.
• Parent Case Event ID: If applicable, reference to the parent ID of the case event.
• Related Document ID: Reference to Document ID of the document related to the event.
• Event Name: Name of event, if applicable.
• Event Date*: Event date.
• Event Description: Description of event.
• Source: Link to information about the event.
• Event Type*: Event class (e.g., issue NOI, sign ROD, issue document or permit).
• Public Access: Indicates whether events can be displayed publicly. (Binary Yes/No).
• Tier: Optional event hierarchy (e.g., Tier 1 NOI, Tier 2 Scoping Complete, Tier 3 Task assigned to Jane Doe).
• Status: Pending, completed, in progress.
• Outcome: Result or action taken.
• Assigned Personnel: Responsible individuals or agencies.
• Following Segment: Name of segment following this event (e.g., if this is “start of scoping” the next segment is “scoping”).
• Related Engagement Events: Related engagement event if applicable.

Entity 7: GIS Data

A container for location-based information, ranging from simple points to complex polygons, as well as maps and “collapsed” geospatial information. These data and technology standards are a layer on top of existing standards (e.g., FGDC, ISO); GIS data stored in the containers specified below should comply with relevant laws and standards (e.g., the Geospatial Data Act of 2018)2. For example, GIS data elements may have to comply with the controlled vocabulary and data and technology standard promulgated through DCAT-US 3.0 for describing geospatial datasets, including coordinate reference systems and geometry. There are three components of the GIS data container:

1. Metadata: Properties that encode relationships and high-level context for the GIS object.
2. Map Container: A container or section for a reference to or file containing a map image.
3. Data Container: A container or section for references to or files/code containing geospatial data itself (e.g., x-y coordinates, GeoJSONs, shape files).

Uses of GIS Data Layers in NEPA or Permit Processes:

1. Project GIS Data: Project-specific layers (e.g., project boundaries, analysis areas).
2. Analysis GIS Data: Data layers used for conducting impact analysis (e.g., habitat, wetlands inventory), including data stored or retrieved from outside the agency.
3. Base Map Data: Foundational layers (e.g., streets, elevation, zoning, utilities, and water resources (including wells)).

Properties:

• GIS ID*: Unique identification number of the GIS data.
• Related Entity ID*: Reference to the ID of the entity that the GIS object is related to (e.g., project, process, document).
• Description*: Where applicable, a description of the data.
• Extent*: Where applicable, the extent of the data.
• Date of Creation*: Where applicable, when the data was retrieved.
• Last Updated*: Where applicable, when the data was finalized.
• Source*: Origin of data.
• Creator*: Organization or individual.
• Contact Information: Contact card for creator.
• Other: Additional data from agencies.
• Container Inventory: Inventory of map image container and GIS data container, which may include a list of:
  • Format: GeoJSON, KML, GML, GeoTIFF, and other examples.
  • Access Method: URL, API, direct upload.
  • Coordinate System: Spatial reference system.
  • Bounding Box: Geographic extent.
  • Purpose: Bespoke, analysis, or base map.
  • Reference to Database: Whether this object references an identified GIS analysis in an official inventory.
  • Access Information: Instructions for access to data.

Entity 8: User Role

Defines stakeholders interacting with the NEPA or permit technology system. A user role may have connections to the responsibilities outlined in a process model, such as an applicant for a permit or a reviewer for a document. This is distinct from any “contact card” entities, specific users, etc. User role is a general class of entity that may play a role in processes, but this entity should not be considered a substitute for authentication, access, and secure data practices within systems. Agencies are expected to implement user roles such that they are compatible with overall system architecture rather than follow this data specification exactly.

Properties:

• User Role ID*: Unique identification number for the user role.
• Name*: Title of the role (e.g., Agency Staff, Agency Reviewer, Public Commenter, Decision Maker).
• Description: Responsibilities and access rights.
• Permissions: System access levels.
• Affiliation: Organization or group.
• Public: Role is member of the broader class of public user/stakeholders.

Entity 9: Legal Structure - Law, Regulation, Policy, or Business Rules

Legal, policy, or process data guiding the process, including thresholds and conditions for level of reviews or other decision criteria.

Properties:

• Legal Structure ID*: Unique identification number for the business rule.
• Title*: Official name.
• Citation*: Legal reference.
• Description: Summary and relevance.
• Text Content: Full text or excerpt.
• Issuing Authority: Government body.
• Effective Date: Implementation date.
• Compliance Requirements: Procedural mandates.