Skip to content

[Ecosystem] Add repository responsibility catalogue and service capability manifests #1014

Description

@seonghobae

Buyer-visible gap

PR #1013 establishes the organization-level API/event/command envelope and federated integration baseline, but it does not yet provide an executable catalogue that answers, for each CWL repository relationship:

  • which product owns the authoritative fact;
  • which repository provides and consumes the capability;
  • whether the boundary is a package, independent service, offline scientific worker, artifact handoff, event/API contract, or build control;
  • which data classification and purpose authorize the flow;
  • whether the relationship is planned, accepted architecture, active in a PR, or implemented on protected main;
  • what the consumer must do next on success, rejection, timeout, duplicate, and rollback.

Without that catalogue, leaf repositories may independently reproduce integration prose, confuse architecture with deployed behavior, copy credentials or product data, or drift toward direct cross-repository SQL.

Product boundary

The central .github repository owns only the organization-wide vocabulary, compatibility rules, schemas, catalogue and reusable validation. Product repositories own domain semantics, their databases, API/event payloads, release artifacts, runtime adapters and acceptance evidence.

The design must preserve the previously established boundary:

Each product owns its product truth; other CWL products contribute bounded identity, communication, ingestion, document, retrieval, psychometric, temporal, AI and engineering capabilities without silently becoming co-owners of that truth.

Orgmetra is the first high-leverage consumer case: it owns people, employment, organization, job, position, assignment, performance and employment-decision truth, while Keyverse, Naruon, Psychometrics Commons, fast-mlsirm, TEPP, Semantic Data Portal, OriginWeave, document services and ingestion services remain independent owners of their specialist responsibilities.

Required central artifacts

1. Service capability manifest schema

Add a strict JSON Schema Draft 2020-12 manifest with at least:

  • schema_version
  • service_id
  • repository
  • product_boundary
  • integration_mode
  • maturity
  • authority_domains
  • consumer_repositories
  • API/event/package/artifact contract references
  • database ownership declaration
  • explicit prohibition of direct cross-repository SQL
  • data classifications
  • released artifact identities
  • customer/operator next actions

Allowed integration modes:

  • in_process_package
  • independent_service
  • offline_scientific_worker
  • build_operations_tool

2. Repository relationship catalogue schema

Add a graph catalogue with unique services and purpose-bound relationships containing:

  • provider, consumer and authoritative data owner;
  • contract kind and immutable/versioned reference;
  • data classification and purpose code;
  • allowed data-flow class such as reference-only, purpose-bound projection, aggregate artifact, schema contract, no business data, or explicit opt-in projection;
  • controlled maturity;
  • customer/operator next action.

Reject unknown services, duplicate identities, self-edges, ambiguous ownership and unknown maturity/data-flow values.

3. Initial reviewed catalogue

Cover at least the first high-leverage ecosystem set:

  • .github, naruon, Orgmetra, Keyverse, contextual-orchestrator;
  • Psychometrics Commons, fast-mlsirm, TEPP;
  • Semantic Data Portal, OriginWeave, NewsDOM, RankWeave, ThreadWeave, EgressWeave, LineageWeave;
  • Inkspan, Clearfolio;
  • MHTML ETL Gateway, mightyETL, pg-erd-cloud;
  • EmbedRelay, AppGuardrail, LifeOS and BandScope.

Do not label an integration implemented_on_protected_main merely because it appears in a PRD, issue, branch, prototype or conversation. The catalogue is an architecture/deployment ledger, not marketing copy.

4. Documentation and ADRs

Add:

  • federated repository responsibility map;
  • closed-loop enterprise value chain diagram;
  • ADR for package/service/worker/tool selection;
  • ADR for purpose-bound service/event ownership metadata;
  • compatibility, rollout and rollback rules;
  • a PII design that preserves authorized operational use through owner-service lookup, workload identity, attribute-based authorization, field-level encryption, purpose audit, controlled study views, retention and revocation—without broadcasting raw PII or imposing workflow-breaking blanket masking;
  • CSAP and SOC 2 control mapping as an engineering aid only, without claiming certification;
  • APA 7 doctoring based on primary specifications.

Reuse #1013's event/command envelope and standards profile after it merges. Do not create a competing second event schema.

Test-first quality contract

  • Add RED tests before production validation code.
  • Strict UTF-8, bounded file size, duplicate-key and non-finite JSON rejection.
  • Closed-object validation and bounded recursive values.
  • Cross-check schema top-level keys with production constants.
  • Reject unknown/duplicate service and relationship identities, direct SQL, credential copying, raw PII event broadcast, inferred lineage promoted to audit truth, and unversioned consumption.
  • Production statement coverage: 100%.
  • Production branch coverage: 100%.
  • Public module/class/function docstrings: 100%.
  • Compile and CLI acceptance tests.
  • Permanent exact-head workflow with immutable action pins, least privilege, security/SAST/SBOM/provenance evidence and git diff --check.

Leaf adoption sequence after central merge

  1. Orgmetra, Keyverse and Naruon capability manifests and identity/communication contracts.
  2. Psychometrics Commons, fast-mlsirm and TEPP result/study contracts.
  3. MHTML ETL Gateway, mightyETL, pg-erd-cloud and Semantic Data Portal migration/schema contracts.
  4. Document, retrieval, AI and inferred-lineage adapters.
  5. Explicit opt-in LifeOS professional-development projection and BandScope rehearsal handoff.

Each provider/consumer pair requires exact-version tests in both repositories, released artifacts/clients, protected-main acceptance and rollback evidence before maturity promotion.

Non-goals

  • No shared global business database.
  • No direct cross-service foreign keys or SQL.
  • No copying every CWL repository into Orgmetra or naruon.
  • No universal HTTP MSA for small deterministic libraries.
  • No Git submodule as a GA integration mechanism.
  • No LLM, retrieval score, inferred lineage or psychometric output promoted directly to a high-stakes business fact.
  • No claim that documentation, a green schema test or a string such as 20b establishes commercial valuation.

Dependency and sequencing

Definition of done

The issue closes only when the central catalogue and service schema are on protected main, leaf adoption instructions are executable, exact-head quality/security gates are terminal, and at least one real provider/consumer pair demonstrates versioned contract validation, authorized data dereference, duplicate-safe processing and rollback without direct SQL or credential copying.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions