Domain Skill Contract

Purpose

The Domain Skill Contract is the interface every alignment domain implements — the six core domains Cohumera ships with, and every Domain Pack or Regional Pack anyone else builds on top of it. Publishing it openly turns Cohumera’s alignment layer from a closed internal checklist into a platform: anyone credible in civic trust, sustainability, finance, accessibility, or regional policy can write a domain, and every founder using Cohumera benefits from their work.

This document is the external, developer-facing expression of the internal Alignment Domain Architecture (v11.1). It adds three things the internal version didn’t need until now: a founder-facing labeling layer, a split between internal and product-facing rationale, and a certification pathway for contributions from outside the founding team.

Who this is for

• Developers and domain experts who want to build a Domain Pack or Regional Pack.
• Teams integrating Cohumera’s blueprint output into their own tools.
• Anyone evaluating whether a specific alignment check can be trusted, and at what tier.

Non-goals

This spec does not define the Fix Engine’s remediation logic, the Evidence Pack’s internal storage format, or the Aggregation Module’s conflict-resolution rules — those remain internal (see fix-engine, evidence-pack, alignment-layer). It defines only the contract a domain agent must satisfy to plug into the system.

Core concepts

• Domain — a single evaluator that checks a blueprint against one dimension (e.g., civic trust, financial viability).
• Domain Pack — a themed bundle of domains addressing a specific concern (e.g., climate risk, inclusivity), registered but inactive until a founder or the roadmap activates it.
• Regional Pack — a domain or overlay scoped to a jurisdiction’s governance context (e.g., EU, Canada, city-level).
• Domain Registry — the internal system that loads, validates, versions, and exposes every domain, whether Core, Verified, or Community tier.

The Contract

1. Domain Metadata

domain:
  domain_name: civic-alignment          # canonical, stable identifier — never changes once published
  domain_version: 1.0.0                  # semantic version — see Versioning below
  domain_category: core                  # core | domain_pack | regional_pack
  domain_region: null                    # e.g. "EU", "UN-ESSF" — null if not region-scoped
  domain_strictness_range: [1, 4]        # supported strictness levels (impact sliders)
  domain_dependencies: [systems-thinking]
  domain_description: >
    Evaluates whether a product treats the people and communities
    it touches fairly.
  public_label: "Is this fair to the people it touches?"
  public_summary: >
    Checks how the product affects the people and communities
    it reaches, in plain language.
  certification_tier: core               # core | verified | community

public_label and public_summary are new in this spec. Every domain has a precise canonical name for the architecture and a plain-language label for the product surface — the same underlying check, two registers of language, so founder-facing copy never has to compromise technical accuracy for readability.

2. Inputs

inputs:
  blueprint: <Blueprint object>
  context: <free-form context captured at intake>
  evidence_pack: <Evidence Pack reference>
  system_map: <System Map reference>
  domain_strictness: <int, within domain_strictness_range>
  regional_overlays: <optional list of Regional Pack ids>

3. Outputs

outputs:
  findings: [ ... ]
  misalignments: [ ... ]
  severity: <1-4, Fix Engine scale>
  confidence: <0.0-1.0>
  evidence_gaps: [ ... ]
  rationale_internal: >
    Full reasoning chain, governance-grade detail, for the Fix Engine,
    the Evidence Pack, and audit/provenance.
  rationale_public: >
    One to two sentences, plain language, no jargon — the version
    shown inline in the product next to the finding itself.
  domain_metadata: <echo of the Domain Metadata block above>

rationale_public is new in this spec and is not optional. A domain that cannot state its reasoning in one or two plain sentences is not ready to publish — this is the mechanic behind “show your work”: every correction Cohumera proposes carries its evidence and reasoning inline, in the product, not just in an internal log.

4. Evaluation Logic

Every domain must declare:

• Evaluation criteria — the specific conditions it checks.
• Severity model — maps findings to the Fix Engine’s 1–4 scale (via the Scoring Bridge where a Civic Impact–style 0–3 score applies).
• Confidence model — how certainty is calculated and expressed.
• Evidence model — what evidence types (factual, systemic, governance, civic, ecological, incentive) the domain draws on and requires from the Evidence Pack.
• Rationale generation — a deterministic method for producing both rationale_internal and rationale_public from the same evaluation, so the two never diverge in substance.

Worked Example

domain:
  domain_name: civic-alignment
  domain_version: 1.2.0
  domain_category: core
  domain_region: null
  domain_strictness_range: [1, 4]
  domain_dependencies: [systems-thinking]
  domain_description: "Evaluates whether a product treats the people and communities it touches fairly."
  public_label: "Is this fair to the people it touches?"
  public_summary: "Checks how the product affects the people and communities it reaches, in plain language."
  certification_tier: core

finding:
  severity: 3
  confidence: 0.78
  evidence_gaps: ["No user research yet on affected community segment X"]
  rationale_internal: >
    Blueprint proposes a usage-based pricing model with no accommodation
    for low-frequency, high-need users. Cross-referenced against
    Evidence Pack entry EP-2026-0143 (comparable product backlash,
    2024) and Systems Thinking domain flag on incentive misalignment
    between revenue model and access equity.
  rationale_public: >
    Your pricing model may unintentionally lock out the users who need
    this most. A similar product ran into this in 2024 — worth checking
    before you build further.

Versioning

Domain versions follow semantic versioning (MAJOR.MINOR.PATCH):

• MAJOR — breaking change to evaluation criteria or output schema.
• MINOR — new capability, backward compatible.
• PATCH — wording, calibration, or bug fixes.

Deprecation requires one minor-version notice period before removal. A deprecated domain remains active and visible, flagged as deprecated in the registry, until formally retired.

Contribution & Certification Pathway

Opening the contract to outside contributors only works if trust is engineered into the pathway, not assumed:

Community tier — Anyone can submit a domain against this schema. Submissions run in a sandbox against a fixed set of reference blueprints, and results are reviewed by the Cohumera core team before the pack is listed. Community-tier packs are visibly labeled as such wherever their findings appear in-product.

Verified tier — A pack reviewed and attributed to a named subject-matter expert or institution, calibrated against a larger reference set, with an accountable author of record.

Core tier — Reserved for the domains maintained directly by the Cohumera founding team and embedded in the MVP (ethical, civic, regenerative, systems-thinking, incentive, financial-viability).

Submission requirements: a complete Domain Metadata block, a documented evaluation logic description, at least one worked example, and a passing sandbox run against reference blueprints. The certification tier is always visible next to a finding in-product, so a user always knows whether a check came from Cohumera core, a verified expert, or an early community contribution.

Relationship to Internal Architecture

This public specification is the externally-facing expression of the internal Alignment Domain Architecture (v11.1). Any change made here must be mirrored in architecture-overview.md and the alignment-domain-architecture skill to preserve deterministic lineage across the internal and public-facing versions of the contract.

Licensing

Two different things carry two different licenses, because they serve two different purposes.

1. The specification itself (this document) — Apache License 2.0.
Anyone can read, implement, and build against the Domain Skill Contract freely, without asking permission or paying a fee. This is the same choice made by the OpenAPI Specification and most published API and interface specs. Apache 2.0 grants an explicit patent license alongside the copyright grant — it forecloses a later patent claim against anyone who implements the contract in good faith. It only requires that copies and derivative versions preserve the attribution and license notice. It does not require anyone building a domain against this contract to open-source their own domain’s evaluation logic, and it does not open-source the rest of the Cohumera platform (the Fix Engine, Evidence Pack, and Aggregation Module stay internal, per Non-goals above). Opening the interface is not the same as opening the product.

2. Contributions submitted against the contract (Community and Verified tier domains) — a Contributor & Marketplace Agreement, not a copyright assignment.
A contributor who submits a domain keeps full ownership of what they built. By submitting it for certification, they grant Cohumera a perpetual, worldwide, non-exclusive, royalty-free license to host, sandbox-test, run, display, and distribute their domain within the Cohumera platform, and to label it at the certification tier it earns. Cohumera does not gain the right to sell the contribution outside the platform, relicense it to a third party, or claim it as Cohumera’s own work. Attribution to the named contributor or institution stays intact at the Verified tier, and Community-tier packs remain visibly labeled as community submissions. Cohumera may deprecate or remove a domain that fails a later sandbox run, consistent with the Versioning section above. This mirrors the pattern used by comparable plugin and extension marketplaces — for example the GitHub Marketplace Developer Agreement and the W3C Community Contributor License Agreement — where the specification is open but individual contributions are licensed in, not assigned away.

Why this split, and not one license for everything: a single license across the whole repository would either force Cohumera to open the internal Fix Engine, Evidence Pack, and Aggregation Module logic — explicitly out of scope for this contract — or force every outside contributor to give up ownership of their work, which would deter exactly the domain experts this pathway exists to attract. Splitting the license by artifact — open on the interface, licensed-in on contributions — lets both goals hold at once, and matches how OpenAPI, JSON Schema, and W3C specifications each keep the interface open while contributions are licensed rather than assigned.

What this does not resolve: commercial terms for Verified-tier contributors (for example, revenue share if a paid tier launches) are a separate, later decision and remain out of scope for this document.