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
- Orgmetra, Keyverse and Naruon capability manifests and identity/communication contracts.
- Psychometrics Commons, fast-mlsirm and TEPP result/study contracts.
- MHTML ETL Gateway, mightyETL, pg-erd-cloud and Semantic Data Portal migration/schema contracts.
- Document, retrieval, AI and inferred-lineage adapters.
- 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.
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:
main;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
.githubrepository 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:
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_versionservice_idrepositoryproduct_boundaryintegration_modematurityauthority_domainsconsumer_repositoriesAllowed integration modes:
in_process_packageindependent_serviceoffline_scientific_workerbuild_operations_tool2. Repository relationship catalogue schema
Add a graph catalogue with unique services and purpose-bound relationships containing:
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;Do not label an integration
implemented_on_protected_mainmerely 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:
Reuse #1013's event/command envelope and standards profile after it merges. Do not create a competing second event schema.
Test-first quality contract
git diff --check.Leaf adoption sequence after central merge
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
20bestablishes commercial valuation.Dependency and sequencing
mainas a path-bounded successor; keep feat(integration): establish CWL ecosystem contract v1 #1013's envelope files authoritative.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.