Skip to main content

Record ๐Ÿ“

Maturity

Official URL: https://bcgov.github.io/nr-pies/docs/spec/element/message/record

JSON Schema URL: https://raw.githubusercontent.com/bcgov/nr-pies/refs/heads/main/docs/spec/element/message/record.schema.json

Represents a message envelope for transmitting asset records.

Scopeโ€‹

This message type serves as a transport envelope for transmitting records between systems. A Record message combines Header metadata (transaction tracking, asset identification) with a resource payload selected via asset_kind.

The Record message can be composed of either an Anchor, Permit, or Project resource type defined in the specification. Refer to the Type Hierarchy for how messages, resources and data types compose together.

Structureโ€‹

A Record message shall contain all flattened Header properties.

All records shall be denoted with a kind property value of RECORD as defined in Message Kind.

Records shall declare an asset_kind property value as defined in Asset Kind:

Records shall declare the following properties in addition to flattened Header properties:

NameCardinalityTypeDescription & Constraints
(header fields)(varies)HeaderStandard Header properties, including the asset_kind selector (see below)

Bindingsโ€‹

The asset_kind field acts as a type selector, binding and identifying which resource type this message contains:

  • asset_kind: ANCHOR - Message payload conforms to Anchor resource schema
  • asset_kind: PERMIT - Message payload conforms to Permit resource schema
  • asset_kind: PROJECT - Message payload conforms to Project resource schema

This selection is enforced at the schema level via conditional if/then logic.

Specificationโ€‹

Loading ....

Implementation Guidanceโ€‹

Type Selection Patternโ€‹

The Record message uses a type selector pattern:

-- The asset_kind field declares which resource type the payload contains -- Systems generating records must declare a valid Asset Kind type -- The values must match the actual resource schema of the message payload -- Schema validation uses if/then logic to enforce the match

Resource-Specific Constraintsโ€‹

Each resource type that can be composed with Record defines its own constraints. Refer to the appropriate resource documentation:

  • Anchor - Foundational reference point
  • Permit - A permit record
  • Project - A grouping of related records

Systems should provide all known element definitions whenever available. Recipient systems must not assume a single message provides the full transactional state. Recipient systems should request additional Records if needed.

Choosing a Resource Typeโ€‹

When generating a Record message, use asset_kind to select the appropriate resource type:

Use asset_kind ANCHOR when the message is a reference point without state, for instance:

  • Establishing a baseline or foundational record
  • Registering a record for future association
  • Signaling record existence without process or hold context

Use asset_kind PERMIT when the message carries a permit's state, for instance:

  • Sharing a permit's journey through an application workflow
  • Conveying hold periods and reasons for review delays
  • Providing an auditable event history

Use asset_kind PROJECT when the message is describing a grouping of related assets, for instance:

  • Defining a project that encompasses multiple related assets

Referencesโ€‹

Message Structureโ€‹

Composable Resource Typesโ€‹

Design Principlesโ€‹