MICE Type Profile Specification
1. Purpose
A MICE Type is the controlled category a micro engine belongs to: Calculation Engines, Validator Engines, Aggregation Engines and so on. The type library under content/computation-hub-calcs/micro-engines/mice-types/ is the only place such a category is defined.
This specification is the document-type profile for the documents in that library. It defines:
- what a MICE Type document is, and is not;
- the Constitutional Header requirements and the
mice_type:block; - the fixed body structure, including the membership criteria every type publishes;
- how the type code relates to the MEID capability code and the CMI kind, so that the three identity layers stop duplicating one another;
- the registry projection of the type library and the validation rules VW-DL applies.
The profile exists because mice.category is today a free-text value in 92 micro-engine documents, carried by zar.micro_engine_registry.category without any vocabulary table behind it. Ten different values are in use in the Computation Hub alone, and the TrustGate engine documents fill the same field with MEID capability codes. A category that is sometimes a type, sometimes a capability and sometimes a typo cannot drive routing, documentation tables or code generation.
2. Architectural Position
DOCUMENTATION-CONSTITUTION
|
ZYZ-STD-CM-CS (Constitutional Header)
|
DTPR-001 (document type profiles)
|
+--- CMPS-001 (component profiles: mice: block of a micro engine)
|
+--- MTPS-001 (this profile: mice_type: block of a MICE Type)
The profile is registered in the Document Type Profile Registry as:
document_type_profile:
profile_id: mice-type
document_type: mice-type
description: Controlled category boundary for micro engines
required_fields: [mice_type]
controlled_fields: [mice_type.type_code, mice_type.allowed_capabilities, mice_type.cmi_kinds]
validation_rules: [MTYPE-001 … MTYPE-012]
schema_reference: profiles/mice-type.schema.json
component_profiles: []
lifecycle_policy: type-lifecycle
Profile resolution follows the repository convention already used for micro engines: the presence of the mice_type: block selects the profile, in the same way the presence of mice: selects the micro-engine profile in CMPS-001.
3. Definitions
A MICE Type is a named, governed category of micro engines that share one responsibility boundary. A type defines what kind of work its members do and what they do not do. A type is not executable and has no MEID, no CMI and no runtime identity.
The type code is the document id of the MICE Type document. It is the value every member carries in mice.category.
A member is a micro-engine document whose mice.category equals the type code and which satisfies the type's membership criteria.
A sub-type is a MICE Type whose mice_type.parent_type names another type. A sub-type narrows its parent's boundary; it never widens it.
A capability is the CAPABILITY segment of a MEID, resolved through zar.meid_capability. It is an attribute of a MEID, never of a type document.
A CMI kind is the KIND segment of a Canonical Managed Identifier, resolved through zar.cmi_kind_registry. It describes the executed artifact, never the engine family.
4. Identity Model
4.1 Three layers, three registries
| Layer | Question answered | Carried in | Vocabulary |
|---|---|---|---|
| MICE Type | Which category of engine is this? | mice.category | MICE Type documents, projected to config/system/mice-types.json |
| MEID | Which logical engine is this? MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION> | mice.meid | zar.meid_domain, zar.meid_capability, zar.meid_function, zar.meid_registry |
| CMI | Which governed artifact executed? | zar.meid_cmi_binding, USO lineage tail | zar.cmi_registry, zar.cmi_kind_registry, zar.cmi_artifact_name_registry |
The type answers a documentation and governance question. The MEID answers a routing question. The CMI answers an audit question. One value SHALL NOT serve two layers.
4.2 Rules
mice.category SHALL be the exact id of a MICE Type document with mice_type.status of review, active or deprecated. Any other value is a validation error.
mice.category SHALL NOT carry a MEID capability code, a MEID function code, a CMI kind or a tier. Where a type code and a capability code are spelled the same (CALC, AGGR, SCORE), the coincidence is permitted but implies nothing: the type document declares its allowed capabilities explicitly in mice_type.allowed_capabilities.
When no registered type's membership criteria admit a micro engine, the author SHALL propose a new MICE Type document with mice_type.status: proposed and SHALL NOT assign the nearest existing type. The member document carries the proposed type code only after the type is registered.
A MICE Type document SHALL declare component_registry: exclude and SHALL NOT carry a mice: block, a MEID, a CMI, an API route or signal contracts of its own.
A type code SHALL NOT be renamed. A type whose name is wrong is deprecated and a new type is registered; members migrate by changing mice.category once the new type is registered.
A micro engine SHALL belong to exactly one type. An engine that satisfies the criteria of two types indicates a defect in the criteria, and the type documents are corrected before the engine is classified.
The CAPABILITY segment of a member's MEID SHALL be one of the type's mice_type.allowed_capabilities. The CMI kinds bound to a member's MEID SHALL be among the type's mice_type.cmi_kinds.
5. Constitutional Header
5.1 Base requirements
A MICE Type document carries the full Constitutional Header defined by ZYZ-STD-CM-CS. The following values are fixed for this profile:
asset_type: specification
component_registry: exclude
classification:
- MICE-Type
hub: computation-hub-calcs
omr_module_ids:
- computation-hub
governed_by:
- MICE
description is required and SHALL state the responsibility boundary in one sentence. related lists the neighbouring type documents and SHALL use registered document ids only.
5.2 The mice_type: block
mice_type:
type_code: CALC # equals the document id
parent_type: null # registered type id for a sub-type, otherwise null
status: review # proposed | review | active | deprecated | retired
tier_scope: [tier-1, tier-2, tier-3]
invocation: chained # chained | policy-invoked | ingress | service
payload_effect: derive # none | annotate | derive | transform
lineage_role: stamps-cmi # stamps-cmi | emits-meta-signal | both
domain_scope: [] # MEID domain codes, empty = domain-independent
allowed_capabilities: [CALC] # MEID capability codes (zar.meid_capability)
typical_functions: [CALCULATOR, INTENSITY] # MEID function codes (zar.meid_function), informative
cmi_kinds: [ENGINE] # zar.cmi_kind_registry
upstream_types: [VALI, TRFM] # registered type ids
downstream_types: [AGGR, VALI] # registered type ids
excluded_types: [VALI, TRFM, AGGR] # types whose work this type SHALL NOT do
sub_types: [] # registered type ids
5.3 Field semantics
| Field | Required | Meaning |
|---|---|---|
type_code | yes | Equals id. Redundant by design so the block is self-describing when projected. |
parent_type | yes (nullable) | Registered type id of the parent for a sub-type. |
status | yes | Lifecycle of the type itself (chapter 12). Independent of the document status. |
tier_scope | yes | Tiers in which members run: tier-0, pre-tier, tier-1, tier-2, tier-3. |
invocation | yes | chained (selected by ZSSR inside a computation chain), policy-invoked (triggered by policy or governance, Tier-0), ingress (runs at the acquisition boundary), service (called by an orchestration layer on demand). |
payload_effect | yes | What members do to the payload: none (observe only, emit a separate result), annotate (attach metadata, values unchanged), derive (produce a new payload from inputs), transform (change the representation of the same signal). |
lineage_role | yes | stamps-cmi (members append a CMI stamp to the USO lineage), emits-meta-signal (members emit a new meta-signal USO), both. |
domain_scope | yes | MEID domain codes the type is bound to; empty for domain-independent types. |
allowed_capabilities | yes | MEID capability codes members MAY use. Enforced by RULE-MTYPE-007. |
typical_functions | no | MEID function codes commonly used by members. Informative. |
cmi_kinds | yes | CMI kinds members MAY bind. |
upstream_types | yes | Types whose outputs members typically consume. |
downstream_types | yes | Types that typically consume members' outputs. |
excluded_types | yes | Types whose responsibility members SHALL NOT take on. Mirrors the "does not do" criteria in section 3 of the body. |
sub_types | yes | Registered sub-type ids. |
All list values that name a type SHALL be registered type ids. All capability, function and CMI kind values SHALL resolve through the ZAR vocabulary tables named in chapter 4.
6. Body Structure
Every MICE Type document SHALL use the following sections, numbered as shown. Section numbers are stable identifiers: Jira work orders and cross-references address a type document by section number, so an omitted optional section leaves its number unused rather than renumbering what follows.
| § | Heading | Required | Content |
|---|---|---|---|
| 1 | Identity | yes | Type code, canonical name, parent type, status; the sentence that a type is a category and not an identity. |
| 2 | Purpose and boundary | yes | What the type exists for, in prose. |
| 3 | Membership criteria | yes | Chapter 7. |
| 4 | Design rules | yes | Chapter 8. |
| 5 | Contract | yes | Inputs and outputs members share; consumers of the outputs. |
| 6 | Position in the computation chain | yes | Chain diagram, interaction with ZSSR, interaction with complementary types. |
| 7 | Identity rules for members | yes | Allowed capabilities, typical functions, CMI kinds, lineage role — rendered from the mice_type: block. |
| 8 | Sub-types | no | One subsection per registered or proposed sub-type. |
| 9 | Governance and audit | no | Audit record, change control, provenance obligations specific to the type. |
| 10 | Members | yes | Generated table: <MiceRegistryTable filter={{ category: ['<TYPE>'] }} />. |
| 11 | Related types | yes | Neighbouring types with one line each; registered ids only. |
Headings SHALL be ## for sections and ### for subsections. The body SHALL NOT carry a StatusBadge; status lives in the header. The body SHALL NOT import components it does not use.
7. Membership Criteria
Section 3 of every type document is the decision procedure for classifying a micro engine. It SHALL contain:
- 3.1 Inclusion tests — a list of observable properties; an engine that satisfies all of them is a member. Each test is a statement that can be checked against the engine's specification (its inputs, outputs, payload effect, invocation model).
- 3.2 Exclusions — the responsibilities that belong to other types, each naming the type that owns them. These are the same types listed in
mice_type.excluded_types. - 3.3 Boundary cases — where the type is commonly confused with another, and the test that separates them (for example VALI versus AME, TRFM versus NORM, TSER versus SENS).
Every inclusion test SHALL be phrased so that two reviewers reading the same engine specification reach the same answer. Tests that depend on intent, quality or importance are not admissible.
The types named in section 3.2 SHALL equal mice_type.excluded_types. A name in one and not the other is a validation error.
8. Design Rules
Section 4 carries the normative invariants of the type as constitutional RULE objects:
:::note[RULE-<TYPE>-NNN — <short title>]
<one or more normative statements using SHALL, SHALL NOT, SHOULD or MAY>
:::
<TYPE> is the type code. Numbering is sequential from 001 and never reused. Normative statements use the CDF keyword set (SHALL, SHALL NOT, SHOULD, MAY); the keyword CDF reserves SHALL NOT appear. Rule bodies describe member behaviour, not the type document.
9. Members Section
Section 10 SHALL render the member list from the generated registry, filtered by category:
<MiceRegistryTable filter={{ category: ['CALC'] }} />
The table SHALL NOT be filtered by tags or classification. Tags are selectors and hints; they are not identity, as every type document already states for ZSSR routing.
MiceRegistryTable currently accepts tags, classification, domain and tier filters only. Extending MiceFilter with category?: string[] and comparing it against the row's category is a prerequisite for this profile and is listed under registration requests in the header.
10. Registry Projection
10.1 Generated registry
The type library is projected to config/system/mice-types.json by a generator in the same family as scripts/generate_micro_engine_registry_json.mjs:
{
"generated_from": "content/computation-hub-calcs/micro-engines/mice-types",
"vocabularies": {
"tier_scope": ["tier-0", "pre-tier", "tier-1", "tier-2", "tier-3"],
"invocation": ["chained", "policy-invoked", "ingress", "service"],
"payload_effect": ["none", "annotate", "derive", "transform"],
"lineage_role": ["stamps-cmi", "emits-meta-signal", "both"]
},
"entries": [
{
"type_code": "CALC",
"title": "Calculation Engines",
"description": "…",
"status": "review",
"parent_type": null,
"allowed_capabilities": ["CALC"],
"cmi_kinds": ["ENGINE"],
"source_file": "/computation-hub-calcs/micro-engines/mice-types/calculation-engines.mdx"
}
]
}
The generated file is never edited by hand. registry-manifest.json lists it as the canonical registry for mice.category.
10.2 ZAR
zar.micro_engine_type
type_code text primary key
canonical_name text not null
description text
parent_type text references zar.micro_engine_type(type_code)
status text not null references zar.meid_status(status_code)
source_doc_id text
created_at, updated_at
zar.micro_engine_registry.category gains a foreign key to zar.micro_engine_type.type_code. The importer (scripts/import_micro_engine_registry.mjs) SHALL refuse a row whose category does not resolve, in the same way it refuses a row without source_key.
allowed_capabilities and cmi_kinds are projected to two binding tables (zar.micro_engine_type_capability, zar.micro_engine_type_cmi_kind) with foreign keys to zar.meid_capability and zar.cmi_kind_registry, so RULE-MTYPE-007 can be enforced in the database as well as in lint.
11. Validation Rules
11.1 Type documents
| Rule | Severity | Description |
|---|---|---|
| MTYPE-001 | error | mice_type block present and type_code equals id |
| MTYPE-002 | error | component_registry: exclude; no mice: block |
| MTYPE-003 | error | status is a value of the type lifecycle |
| MTYPE-004 | error | tier_scope, invocation, payload_effect, lineage_role resolve through mice-types.json vocabularies |
| MTYPE-005 | error | allowed_capabilities resolve through zar.meid_capability |
| MTYPE-006 | error | cmi_kinds resolve through zar.cmi_kind_registry |
| MTYPE-007 | error | parent_type, upstream_types, downstream_types, excluded_types, sub_types resolve to registered type ids |
| MTYPE-008 | error | Sections 1–7, 10 and 11 present with the governed headings and numbers |
| MTYPE-009 | error | Section 3.2 exclusions equal excluded_types |
| MTYPE-010 | warning | typical_functions resolve through zar.meid_function |
| MTYPE-011 | error | Section 10 uses a category filter and no tag or classification filter |
| MTYPE-012 | error | No StatusBadge in the body; no unused imports |
11.2 Member documents (extends CMPS-001 §5.5)
| Rule | Severity | Description |
|---|---|---|
| MICE-014 | error | mice.category resolves through mice-types.json with status review, active or deprecated |
| MICE-015 | error | MEID capability segment is in the type's allowed_capabilities |
12. Type Lifecycle
proposed → review → active → deprecated → retired
proposed— the document exists; members SHALL NOT reference it yet. Created under RULE-MTYPE-003.review— registered inmice-types.json; members MAY reference it; criteria may still change.active— criteria frozen except by versioned change; members and routing rely on it.deprecated— no new members; existing members carry a migration note.retired— no members remain.
A new type is proposed by submitting the type document with status: proposed, a machine.registration_requests entry of kind mice-type, and at least one candidate member that fails every existing type's membership criteria.
13. Migration of the Existing Type Library
The sixteen documents under mice-types/ were authored in two section layouts ("capability class" and "engine type"). Migration maps the legacy sections onto the governed structure without removing content:
| Legacy section | Governed section |
|---|---|
| Overview; Position in the MICE Model | 1 Identity, 2 Purpose and boundary |
| Scope of Responsibility (what engines do); What engines do not do | 3 Membership criteria |
| Design Principles; Governance Principles | 4 Design rules (as RULE objects) |
| Inputs; Outputs | 5 Contract |
| Position in the computation chain; Interaction with ZSSR; Interaction with SEM | 6 Position in the computation chain |
| Canonical identification | 7 Identity rules for members |
| LINK Engines; Core Assurance Capability: CFIL | 8 Sub-types |
| Audit & Provenance; Governance & Change Control | 9 Governance and audit |
| Registry view; Example engines | 10 Members |
| Related engine types | 11 Related types |
| Summary; Design rationale | folded into 2 Purpose and boundary |
Member documents migrate their mice.category as follows:
| Current value | Governed value | Note |
|---|---|---|
CALC, AGGR, SCORE, VALI, SCEN, NORM | unchanged | already type codes |
TRANS | TRFM | TRANS is the MEID capability |
VALIDATE | VALI | TrustGate engines |
ENRICH, TAGG | META | tagging is a META subset |
NORMALIZE | TRFM | signal normalisation is representational; NORM is mathematical rescaling |
INGEST | EXTR | review: parser at the TrustGate ingress |
UOM | UOM-TYPE | pending the open question on UOM-TYPE |
ATTEST, ANCHOR, REPLAY, EXPORT, MONITOR, ROUTE, POLICY, CONFIG, JOB | none | RULE-MTYPE-003 applies: new types or reclassification as engines |
... | none | placeholder; the document is reclassified from its specification |
14. Conformance
This specification conforms to DOCUMENTATION-CONSTITUTION (CD-001 to CD-004, CD-103, CD-104), ZYZ-STD-CM-CS, DTPR-001 and CMPS-001, and takes the MEID grammar and lifecycle from MEID_STANDARD without restating them.
Where this specification and CMPS-001 §5.2 differ on the meaning of mice.category, this specification governs; CMPS-001 is amended to reference it.