Skip to main content

Document Type Profile Registry Specification

1. Purpose

The Document Type Profile Registry defines the governed profiles used by VW-DL to validate specialised Constitutional Headers.

The Constitutional Header contains universal metadata applicable to all ZAYAZ documentation assets.

Document Type Profiles define additional requirements based on the purpose and nature of the asset.

The registry prevents a single flat metadata model from being applied to all documentation types.

A:

  • knowledge document;
  • architecture specification;
  • operational design;
  • schema specification;
  • micro-engine specification;
  • engine specification;
  • API contract;
  • registry specification;
  • validator specification;
  • report specification;
  • Pergamum Pulse asset

require different metadata.


2. Architectural Position

The relationship is:

Constitutional Metadata Standard
|
v
Universal Constitutional Header
|
v
Document Type Profile Registry
|
v
VW-DL Validation
|
v
Self-Describing Architecture Graph

The registry determines:

  • required fields;
  • optional fields;
  • controlled vocabularies;
  • component profiles;
  • validation rules;
  • schema references.

3. Registry Object

A Document Type Profile SHALL contain:

document_type_profile:

profile_id:

document_type:

description:

required_fields:

optional_fields:

controlled_fields:

validation_rules:

schema_reference:

component_profiles:

lifecycle_policy:

4. Profile Resolution

VW-DL resolves profiles through:

Document Header
|
v
document_type
|
v
Document Type Profile Registry
|
v
Applicable Validation Rules

Example:

document_type:
micro-engine

loads:

Universal Constitutional Header Rules

+

Micro Engine Component Rules

5. Base Document Profile

All documents inherit the base profile.

Required:

id:
semantic_id:
title:
version:
document_type:
status:
owners:
classification:
security_level:

Validation:

BASE-001 ID exists

BASE-002 semantic_id exists

BASE-003 version valid

BASE-004 status valid

BASE-005 owner resolves

BASE-006 classification resolves

6. Specification Profile

Used for technical and architectural specifications.

Example:

document_type:
specification

Additional fields:

specification:

purpose:

scope:

architecture_position:

interfaces:

dependencies:

schemas:

validation:

Validation:

SPEC-001 Purpose required

SPEC-002 Dependencies resolve

SPEC-003 Interface references resolve

SPEC-004 Schema references resolve

7. Operational Design Profile

Used for operational frameworks and workflows.

Example:

document_type:
operational-design

Additional fields:

operations:

workflows:

roles:

responsibilities:

gates:

procedures:

escalation_paths:

Validation:

OPS-001 Workflow references resolve

OPS-002 Roles resolve

OPS-003 Gates defined

OPS-004 Escalation model defined

8. Knowledge Document Profile

Used for Pergamum Pulse governed knowledge assets.

Additional fields:

knowledge:

source:

rights:

provenance:

applicability:

knowledge_scope:

retrieval_profile:

Validation:

KNOW-001 Source lineage required

KNOW-002 Rights metadata required

KNOW-003 Provenance required

KNOW-004 Retrieval eligibility resolves

9. Micro Engine Profile

Used for MICE documentation.

Required:

mice:

meid:

category:

domain:

capability:

function:

signals_in:

signals_out:

Validation uses:

zar.meid_domain

zar.meid_capability

zar.meid_function

zar.meid_registry

zar.meid_status

zar.meid_cmi_binding

Rules:

MICE-001 MEID format valid

MICE-002 MEID registry entry exists

MICE-003 Domain resolves

MICE-004 Capability resolves

MICE-005 Function resolves

MICE-006 CSI signals resolve

10. Engine Profile

Used for major engines.

Required:

engine:

eid:

purpose:

signals_in:

signals_out:

micro_engines:

dependencies:

Validation:

ENG-001 EID resolves

ENG-002 Dependencies resolve

ENG-003 Micro-engine dependencies resolve

ENG-004 CSI contracts resolve

ENG-005 CMI binding exists

11. API Profile

Required:

api:

route:

method:

input_schema:

output_schema:

authentication:

Validation:

API-001 Route declared

API-002 Method valid

API-003 Input contract resolves

API-004 Output contract resolves

12. Registry Profile

Required:

registry:

registry_id:

owner:

schema:

version:

Validation:

REG-001 Registry identity resolves

REG-002 Schema resolves

REG-003 Owner resolves

REG-004 Version valid

13. Validator Profile

Required:

validator:

validator_id:

hecate_profile:

evidence_requirements:

Validation:

VAL-001 Validator exists

VAL-002 HECATE profile resolves

VAL-003 Evidence requirements defined

14. Report Profile

Required:

report:

report_id:

report_type:

data_sources:

generation_profile:

Validation:

REP-001 Report identity resolves

REP-002 Sources resolve

REP-003 Generation profile resolves

15. Pergamum Pulse Profile

Required:

pergamum_pulse:

ingestion_profile:

rights_profile:

retrieval_profile:

knowledge_type:

Validation:

PP-001 Ingestion Profile resolves

PP-002 Rights Profile resolves

PP-003 Retrieval Profile resolves

PP-004 Source lineage exists

16. Profile Composition

A document may use multiple profiles where permitted.

Example:

Pergamum Pulse Knowledge Document

+

Knowledge Document Profile

+

Retrieval Profile

+

Schema Profile

Profile conflicts SHALL be detected.


17. Versioning

Document Type Profiles are versioned.

Rules:

  • incompatible changes require major version;
  • additive fields require minor version;
  • clarification-only changes require patch version;
  • historical profiles remain resolvable.

18. Relationship to VW-DL

VW-DL executes:

Read Constitutional Header



Resolve document_type



Load Document Type Profile



Execute validation rules



Create findings

19. Foundational Principle

Document types are architectural contracts.

A document is not only text. It is a governed representation of knowledge, architecture, behaviour, ownership and relationships.

The Document Type Profile Registry ensures that every ZAYAZ asset declares the metadata required for humans, AI agents, validation systems and downstream generators to understand what the asset is and how it participates in the platform.




GitHub RepoRequest for Change (RFC)