Jira progress: loading…

ZAR-CAT

ZAR Artifact Categories v1

1. schemas

Purpose: Machine-enforced contracts used at runtime (validation, interoperability, compute calls). Rule: Schemas are operational contracts and must be versioned + immutable when released.

Subcategories (minimal):

• schemas/compute JSON Schemas for compute methods: inputs/options/outputs (used by Computation Hub + MICE).
• schemas/signals JSON Schemas for signal payloads/events and SSSR signal API structures.
• schemas/reports JSON Schemas for report packaging (e.g., disclosure bundles, XBRL/iXBRL payload structures).
• schemas/common Shared schema building blocks (units, money, period, geo, org boundary, evidence refs).

---

2. manifests

Purpose: “Index files” that map a set of artifacts into a coherent versioned release. Rule: Manifests are the glue between registries and storage. They enable bulk publishing + reproducibility.

Subcategories:

• manifests/compute_methods Maps method_id → schema IDs, MEIDs, dataset requirements, framework refs.
• manifests/signal_packs Maps signal sets (by framework/sector/module) → signal IDs + schema refs.
• manifests/taxonomy_packs Declares versioned taxonomy releases (ESRS, EU taxonomy mappings, internal ontologies).

---

3. signals

Purpose: The semantic + operational “what” of ESG data points in ZAYAZ (SSSR layer). Rule: Signals are stable identifiers with metadata, not raw values.

Subcategories:

• signals/registry Canonical signal definitions (signal_id, names, types, units, owners, framework links).
• signals/mappings Mapping tables (signal ↔ ESRS/XBRL concepts, signal ↔ NACE relevance, signal ↔ compute methods).
• signals/lists Controlled vocabularies used by signals (units, categories, dropdown sources; references allowed).

---

4. taxonomy

Purpose: External and internal classification systems that drive obligations, mapping, and reporting structure. Rule: Taxonomies change—so they must be versioned and referenced by ID.

Subcategories:

• taxonomy/esrs ESRS structures, disclosure groupings, datapoint references (and links to XBRL concepts where used).
• taxonomy/xbrl XBRL concept maps, label/linkbase mappings, iXBRL packaging rules (high-level references).
• taxonomy/industry Industry classification & applicability (e.g., NACE-based obligation profiles, sector rules).
• taxonomy/internal ZAYAZ internal ontologies (USO, domain vocabularies, canonical enums).

---

5. datasets

Purpose: Declares “what reference data is required” to compute or validate (not necessarily storing the dataset). Rule: Datasets are referenced by dataset_id with provenance and licensing metadata.

Subcategories:

• datasets/registry Dataset descriptors (dataset_id, provider, version, license, update cadence).
• datasets/connectors Access definitions (S3 location, API endpoint metadata, credential requirements, caching policy).

---

6. rules

Purpose: Declarative logic that is not “code,” but still operational: thresholds, routing rules, validation rules. Rule: Rules must be traceable and versioned like code, because they change outcomes.

Subcategories:

• rules/validation DICE/DaVE rule packs: completeness thresholds, plausibility checks, unit constraints, outlier flags.
• rules/routing ZSSR/ZADIF routing rules: which engine/method to invoke based on context.
• rules/materiality SEEL and double materiality scoring rulesets (scoring weights, stakeholder bands).

---

7. docs

Purpose: Human-readable operational documentation tied to artifacts (auditors, verifiers, implementers). Rule: Docs must reference artifact IDs (ZAR:*), not filenames.

Subcategories:

• docs/methods Method explanations (math, assumptions, examples, interpretation).
• docs/signals Signal catalog docs (what it means, how to collect, common pitfalls).
• docs/governance CMCB rules, deprecation policy, assurance/audit guidance.
• docs/integrations ERP/API integration guidance and payload examples.

---

8. tools

Purpose: Utilities that build, validate, publish, and test ZAR artifacts. Rule: Tools are not artifacts themselves, but they govern artifact quality and release safety.

Subcategories:

• tools/validators Schema linting, manifest consistency checks, naming convention enforcement.
• tools/publishers Release tooling (GitHub → S3 publish, hash stamping, alias updates).
• tools/generators Template generators (scaffold new method schemas, signal definitions, docs skeletons).
• tools/testdata Golden test vectors for compute methods and schema validation (small and deterministic).

---

Minimal rule of thumb

• If it’s machine-enforced → schemas, rules
• If it’s a versioned index → manifests
• If it defines meaning/metadata → signals, taxonomy, datasets
• If it’s human-facing → docs
• If it helps manage the above → tools

Keep “examples” out of ZAR core

Examples belong in:

• docs/… (as examples embedded in docs), or
• tools/testdata (as deterministic test vectors)

Not in the “released artifact store” path.

---