Skip to main content
Jira progress: loading…

SCORE

Scoring Engines

1. Identity​

AttributeValue
Type codeSCORE
Canonical nameScoring Engines
Parent type—
Type statusreview
Tier scopetier-2, tier-3
Invocationchained
Payload effectderive
Lineage rolestamps-cmi

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

2. Purpose and boundary​

Scoring Engines (SCORE) are a capability class of Micro Engines (MICE) responsible for producing composite indicators, ratings, indices, or maturity scores from one or more input signals.

SCORE engines:

  • combine multiple metrics into a single evaluative output,
  • apply explicit weighting, thresholds, or models,
  • express interpretation, not raw measurement.

SCORE engines answer: “How does this perform, relative to a model?”
They do not claim factual truth — they express structured judgment.

Capability, not identity​

A Scoring Engine:

  • does not compute base metrics (CALC),
  • does not aggregate raw structures (AGGR),
  • does synthesize meaning across signals.

Multiple MEIDs may implement SCORE capabilities, across:

  • different domains (climate, governance, operations),
  • different scoring models (internal, regulatory, partner),
  • different disclosure or decision contexts.

Summary​

Scoring Engines:

  • synthesize multiple signals into interpretable indicators,
  • make evaluative logic explicit and auditable,
  • support benchmarking, ratings, and decision support,
  • remain separate from assurance and governance by design.

They are the interpretive synthesis layer of the ZAYAZ platform.

3. Membership criteria​

3.1 Inclusion tests​

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

  • Combine multiple signals into a composite indicator
  • Apply weights, bands, or scoring functions
  • Produce ratings, indices, or maturity levels
  • Express relative performance or alignment

Examples

  • climate transition readiness score
  • ESG maturity index
  • governance compliance rating
  • supplier risk score
  • internal benchmark or percentile ranking

3.2 Exclusions​

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

  • ❌ compute primary values (CALC)
  • ❌ project future scenarios (SCEN)
  • ❌ validate data correctness (VALI)
  • ❌ certify trust or compliance (AME)
  • ❌ enforce policy decisions (ZSSR)

A SCORE engine evaluates —
it does not decide or certify.

3.3 Boundary cases​

  • SCORE versus RMAP: a weighted composite of several signals is SCORE; a threshold-based category under one framework is RMAP.
  • SCORE versus AME: a trust score produced as an assurance meta-signal from lineage and evidence is AME (see MEID_TRUST_SCORE_CALCULATOR); a performance or maturity score from metric values is SCORE.

4. Design rules​

RULE-SCORE-001 — Explicit Scoring Model

All weights, thresholds, and aggregation logic SHALL be declared and versioned.

RULE-SCORE-002 — Interpretive Transparency

A score SHALL be explainable in terms of its contributing inputs.

RULE-SCORE-003 — Deterministic Evaluation

Given the same inputs and model version, outputs SHALL be reproducible.

RULE-SCORE-004 — Non-Authoritative by Default

Scores are evaluations, not facts, unless an assurance meta-signal covers them.

RULE-SCORE-005 — Auditability

Every score references the exact scoring model and input set used.

5. Contract​

5.1 Inputs​

Typical SCORE inputs include:

  • validated metrics or aggregates,
  • optional scenario-adjusted values (from SCEN),
  • scoring model definitions (weights, thresholds),
  • contextual parameters (peer group, industry, region).

All scoring models SHALL be:

  • explicit,
  • versioned,
  • referenceable.

5.2 Outputs​

SCORE engines emit:

  • a composite score or rating,
  • optional sub-scores or component breakdowns,
  • explicit references to the scoring model,
  • lineage metadata linking all contributing inputs.

Outputs are commonly consumed by:

  • dashboards and analytics,
  • reporting and disclosure layers,
  • RMAP engines (risk interpretation),
  • assurance workflows (optional certification).

6. Position in the computation chain​

6.1 Interaction with ZSSR​

ZSSR does not route to “SCORE” generically.

Instead, it:

  • selects specific MEIDs implementing scoring logic,
  • binds them to an approved scoring model,
  • enforces policy constraints (e.g. “no external ratings allowed”).

Tags such as score, rating, or maturity may be used as fallback selectors, but explicit rules always dominate.

7. Identity rules for members​

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

  • mice.category SHALL be SCORE.
  • The CAPABILITY segment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one of SCORE.
  • The DOMAIN segment SHALL be any registered MEID domain.
  • Typical FUNCTION segments: FINAL, EVALUATOR, CALCULATOR.
  • CMI kinds bound through zar.meid_cmi_binding SHALL be among ENGINE, MODEL.
  • Lineage: members append their CMI stamp to the USO lineage tail.
  • Tier scope: tier-2, tier-3; invocation: chained; payload effect: derive.

10. Members​

Loading micro engines…
  • AGGR — Aggregation Engines
  • NORM — Normalization Engines
  • SCEN — Scenario Engines
  • RMAP — Risk Mapping Engines
  • META — Metadata Enrichment Engines
  • AME — Assurance / Meta engines
  • ALERT — Alert Engines
  • CALC — Calculation Engines
  • VALI — Validator Engines


GitHub RepoRequest for Change (RFC)
Last updated on by ZAYAZ