Jira progress: loading…

RSLU

Resolution Engines

1. Identity

Attribute	Value
Type code	RSLU
Canonical name	Resolution Engines
Parent type	—
Type status	review
Tier scope	tier-1, tier-2
Invocation	chained
Payload effect	annotate
Lineage role	stamps-cmi

RSLU is a category boundary, not an identity. Members are identified by MEID, versioned through ZAR as CMIs, and carry mice.category: RSLU. The type itself has no MEID, no CMI and no runtime presence.

---

2. Purpose and boundary

Resolution Engines (RSLU) decide identity and relationship: which canonical entity a record refers to (legal entity, facility, Resource Point, supplier, product), which entity occupies, owns or operates what and for which period, which of several overlapping sources is authoritative for a measurement (reconciliation), and — through the GEOX sub-type — which region or zone a geometry falls in.

The output of a resolution engine is a resolved reference with the evidence that produced it, or an explicit unresolved state with the candidate set. It is never a numeric value. Resolution is rule-driven: match keys, precedence rules and effective-dated relationships registered in ZAR. Probabilistic matching belongs to ESTM, whose candidates an RSLU engine may consume.

RSLU takes over the two responsibilities that the retired UOM type had no home for — occupancy resolution and resource reconciliation over the Universal Organizational Model — and gives Geospatial Engines a parent.

---

3. Membership criteria

3.1 Inclusion tests

A micro engine is a member of RSLU when its specification satisfies the following:

• Its output is a reference to a canonical entity, a relationship between entities, or a precedence decision between sources — not a value.
• It follows registered deterministic rules (match keys, hierarchies, precedence, effective-dated relationships); where the rules do not yield exactly one answer it emits unresolved with the candidates.
• Its result is attached to the signal as an annotation; payload values are unchanged.
• Its MEID capability is RESOLVE, or CLASSIFY for the spatial classifications of the GEOX sub-type.

3.2 Exclusions

A micro engine is not a member of RSLU when any of the following is its responsibility; each belongs to the type named:

• ❌ compute, aggregate or normalise values (CALC, AGGR, NORM)
• ❌ attach taxonomy or framework context (META)
• ❌ validate contracts (VALI)
• ❌ infer identity probabilistically with a learned model (ESTM)

3.3 Boundary cases

• RSLU versus ESTM: deterministic match rules are RSLU; a learned matcher that emits candidates with probabilities is ESTM, and its candidates may feed RSLU.
• RSLU versus META: resolving which entity a record belongs to is RSLU; tagging what kind of thing it is (scope, framework, taxonomy) is META.
• RSLU versus AGGR: deciding which measurements belong to which facility for a period is RSLU (occupancy); summing them is AGGR.
• RSLU versus GEOX: GEOX is the spatial sub-type — resolution and classification from geometries and spatial layers. Everything else that resolves identity or relationship is RSLU itself.

---

4. Design rules

RULE-RSLU-001 — Rule-driven resolution

Resolution SHALL use registered match rules, precedence rules and effective-dated relationships. An RSLU engine SHALL NOT apply ad hoc heuristics.

RULE-RSLU-002 — Unresolved is a result

When the rules SHALL NOT yield exactly one canonical reference, the engine SHALL emit unresolved with the candidate set. It SHALL NOT emit a best guess.

RULE-RSLU-003 — Evidence

Every resolution SHALL record which rules matched, on which keys, and the registry versions used.

RULE-RSLU-004 — Non-mutating

An RSLU engine SHALL NOT alter payload values. Resolution is an annotation on the signal.

RULE-RSLU-005 — Temporal validity

A relationship resolution SHALL be effective-dated and SHALL state the period for which it holds.

---

5. Contract

5.1 Inputs

RSLU engines consume:

• records carrying reference fields (names, codes, foreign identifiers, coordinates),
• registries (entity, facility, Resource Point, supplier, product) and relationship tables at a declared version,
• match and precedence rules, and the period of interest,
• for GEOX: geometries, spatial layers and the declared CRS.

5.2 Outputs

RSLU engines emit:

• resolved references and relationship assertions, effective-dated,
• precedence decisions between overlapping sources,
• unresolved states with candidate sets,
• evidence: rules matched, keys, registry versions.

Consumers: AGGR (roll-ups over resolved relationships), META, RMAP, CALC; review workflows for unresolved sets.

---

6. Position in the computation chain

6.1 Placement

EXTR / CONN → VALI → RSLU → META → CALC / AGGR
                       ↓
                  unresolved → ALERT / review

6.2 Interaction with ZSSR

ZSSR selects an RSLU MEID by registry domain (entity, facility, Resource Point, supplier, product, spatial). Unresolved outcomes are routed to review through ALERT and CTRL; they never silently default to a parent entity.

---

7. Identity rules for members

Members are micro engines (CMPS-001 mice: block) whose identity satisfies all of the following:

• mice.category SHALL be RSLU.
• The CAPABILITY segment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one of RESOLVE, CLASSIFY.
• The DOMAIN segment SHALL be any registered MEID domain.
• Typical FUNCTION segments: RESOLVER, OCCUPANCY, RECONCILIATION.
• CMI kinds bound through zar.meid_cmi_binding SHALL be among ENGINE, RULESET.
• Lineage: members append their CMI stamp to the USO lineage tail.
• Tier scope: tier-1, tier-2; invocation: chained; payload effect: annotate.

---

8. Sub-types

8.1 GEOX — Geospatial Engines

Spatial resolution and classification from coordinates, geometries and spatial layers: containment, intersection, overlay, proximity. GEOX narrows RSLU to spatial references and adds the coordinate-reference-system obligations. See the GEOX document.

---

9. Bounded lifecycle assessment — 2026-10-25

Decision: advance to review. RSLU defines deterministic identity, relationship and source-precedence resolution. Its explicit match rules, effective-dated registry inputs, resolved-reference or unresolved-candidate outputs, evidence requirements and nonmutation guarantee form a useful type boundary. Numeric computation belongs to CALC/AGGR, probabilistic candidate inference to ESTM, and control-policy resolution to CTRL.

Occupancy and resource reconciliation are documented use cases; GEOX supplies the spatial subtype boundary. No engine document currently declares RSLU or GEOX at the assessed baseline. That is a development inventory observation, not a defect or a reason to block review of a well-defined type. No engine identity is invented to populate the category.

A future member must supply its concrete input/output schema, versioned registry/relationship snapshots, effective dates, precedence rules, ambiguous match behavior, governing policy and declared replay profile. A learned matcher may supply candidates but must not silently become the canonical identity decision. Classification must follow the completed member's responsibility, not provisional frontmatter alone.

Review permits classification under the existing eligibility rule. GEOX's existing status and subtype relationship remain unchanged. This decision does not certify any implementation, alter existing MEIDs, or authorize deployment.

10. Members

Loading micro engines…

---

11. Related types

• EXTR — Extraction Engines
• CONN — Connector Engines
• VALI — Validator Engines
• AGGR — Aggregation Engines
• META — Metadata Enrichment Engines
• RMAP — Risk Mapping Engines
• CALC — Calculation Engines
• ESTM — Estimation & Forecasting Engines
• GEOX — Geospatial Engines

---