Stage R

Rules

SP_CORE_CONFORM_RULE

After the Conform write, ordered apply passes inject programme values onto the same facts. The schema holds three apply surfaces — two kinds of SPEC, and one kind of specialised Rule — not a single “map + rules” blob. Letter R is the apply sequence.

Where Rules sits in CRISP

Rendering diagram…

Highlighted: Rules stamp catalogue, map, and sign onto Conform rows.

What surfaces does Rules use?

Three surfaces — two SPEC, one Rule

Split by shape of the join, not by business domain. Catalogue and Map share one vocabulary table but answer different questions. Specialised Rules leave that table when the outcome is not a simple core_code.

SPEC · Catalogue

Catalogue

CONFORM_RULE_SOURCE_VALUE_MAP · row_kind=CATALOGUE

Which programme codes are approved?

Closed set of core_code values for a vocabulary scope. Not the native spelling — the governed token.

CLAIM_PAYMENT

Approved transaction_kind on monetary facts — not the CLAIM entity itself.

SPEC · Map

Map

CONFORM_RULE_SOURCE_VALUE_MAP · row_kind=MAP

Which catalogue entry does this native literal belong to?

Per-source (and optional release) crosswalk: native token → catalogue core_code.

CAS1:Transaction:PAID → CLAIM_PAYMENT

Claims PAS native type, scoped by canonical source_system after pass 1.

RULE · Specialised families

Specialised families

CONFORM_RULE_FINANCIAL_SIGN_RULE (flagship)

How should this amount be interpreted for the enterprise?

Match on conformed kind (and lane); stamp enterprise-centre sign. Claim payments are outflows.

CLAIM_PAYMENT → × −1

Native magnitude stays positive; accounting_amount_enterprise_signed = amount × sign_to_enterprise.

Orchestration only: CONFORM_RULE_APPLY_ORDER sequences which surface runs when — not domain content. Rejected patterns: one physical SPEC per domain, or one giant table for Catalogue + Map + sign + lifecycle together.

How are catalogues and maps stored?

Vocabulary table — row kinds (SPEC)

Catalogue and Map are row kinds in CONFORM_RULE_SOURCE_VALUE_MAP — same table, different jobs.

row_kind	Role
CATALOGUE	SPEC — approved programme codes (core_code) for that scope.
MAP	SPEC — native literal → catalogue entry, usually scoped by canonical source_system (+ optional release).

What does a vocabulary scope mean?

Vocabulary scopes — type vs entity

Types ask “which approved programme code does this literal belong in?” — not “are these two natives the same subject?” (that is Identity). spec_entity names a vocabulary scope (e.g. PARTY_ROLE_TYPE), not “the party domain’s SPEC table.”

Kind	Examples	Wires to
spec_type	source_system · country_iso	Cross-entity — reusable on many Conform columns via metadata.
spec_entity	PARTY_ROLE_TYPE · LOCATION_USAGE · CONTACT_CHANNEL	Entity-bound vocab — one attribute family; still rows in the shared map.

When is a specialised rule needed?

Specialised rule families (RULE)

Signage is the teaching example: enterprise-centre money sign. Other families reuse the same pattern — match columns in, stamped outcomes on Conform facts.

Family	Table (pattern)	Stamps on facts
FINANCIAL_SIGN	CONFORM_RULE_FINANCIAL_SIGN_RULE	Enterprise-signed monetary columns (*_enterprise_signed).
MONETARY_LIFECYCLE	CONFORM_RULE_MONETARY_LIFECYCLE_RULE	Programme lifecycle interpretation on monetary posts.
GWP_ELIGIBILITY	CONFORM_RULE_GWP_ELIGIBILITY_RULE	is_written_premium_candidate (and peers) for Publish measures.
NORMALISED_STATUS (illustrative)	Specialised status / alias tables	Closed status tokens when join shape ≠ simple MAP.

What else can Rules stamp?

Programme scopes (beyond vocab)

Scope	Role
source_temporal_timezone	Per-PAS IANA default (+ attribute override) for adaptor TIMESTAMP_TZ lift.
cluster_eligibility	Optional funnel — which natives may enter name-match Identity; omit when guards + discrete suffice.

What must stay true for Rules?

Theory

Catalogues and maps are release-controlled and inspectable. Pipeline code must not silently invent enterprise tokens.
Pass order matters: pass-2 MAP rows often scope by canonical source_system stamped in pass 1.
Delivery tooling may inline joins into INSERT … SELECT or dbt intermediates — the C→R invariant stays fixed.
When catalogues or rule families change on existing rows, production needs MERGE or governed re-apply — not silent drift on historical assertions.

What does apply look like in code? Learn more about Governance

Pseudocode

Ordered apply — Catalogue / Map SPEC, then specialised Rules

# SP_CORE_CONFORM_RULE — three surfaces
order = SELECT * FROM CONFORM_RULE_APPLY_ORDER
        WHERE enabled ORDER BY apply_sequence

for pass in order:
  match pass.spec_kind:
    FEED_TO_CANON:                    # Map SPEC (source_system)
      # MAP: extensions.source_feed_code → fact.source_system
      UPDATE conform SET source_system = map_feed(extensions)

    SOURCE_VALUE_MAP:                 # Catalogue + Map SPEC
      # CATALOGUE = approved core_code set
      # MAP = native_token → core_code (scoped by source_system)
      UPDATE conform
      SET typed_col = MAP.core_code
      FROM CONFORM_RULE_SOURCE_VALUE_MAP MAP
      WHERE MAP.row_kind = 'MAP'
        AND MAP.scope_source_system = conform.source_system
        AND MAP.native_value = conform.native_token

    FINANCIAL_SIGN | MONETARY_LIFECYCLE | GWP_ELIGIBILITY | …:
      # Specialised RULE families — not the source-value map
      apply_family_join(pass.spec_rule_family)

mark_load_ready_for_identity()

Next: Identity