Morphism Cgom V2 Schema Review

assetactive

Morphism Cgom V2 Schema Review

Source: morphism-cgom-v2-schema-review.md (ingested 2026-03-28)

This is materially better. The rev2 changes move the system from “math-aware engineering” toward “math-constrained architecture.”

The strongest improvements are the right ones:

  • Promoting the schema line from CGOM v1 / GEP v1 to v2 is justified, because these are breaking semantic changes, not cosmetic edits. The foundations doc explicitly requires κ-first objects, GovernanceState, and required H⁰/H¹ fields where applicable, so pretending this is still v1 would blur a real contract break.
  • Adding cohomological_class and kappa_trend is directionally correct. The foundations doc already wanted kappa_trend on GovernanceState, and the SSOT/H⁰/H¹ framing clearly benefits from an explicit class field rather than scattered booleans.
  • Making Stage 9 explicit in ADR-002 is the right cleanup. In the original ADR-002, GovernanceState was only an implication of persistence/export, not a first-class stage, which left the loop mathematically incomplete.
  • The κ sign convention fix is especially important. The mathematical foundations are unambiguous: positive κ effect means added drift pressure, negative means contracting enforcement. Your rev2 note aligns to that, which is the correct direction.

So the batch is not just “fine”; it resolves real substrate ambiguity.

What I think is now correct

1. Versioning

Calling this CGOM v2 / GEP v2 is correct.

Why:

  • GovernanceState changes the canonical object set.
  • κ fields move from optional/implicit to required/explicit.
  • SSOT semantics become more formal.
  • pipeline semantics now include categorical/functor framing and explicit aggregate-state emission.

That is a contract break, not a patch. The original ADRs were still clearly pre-math-ratification artifacts.

2. Sign convention

Your rev2 sign convention is the right one:

  • positive = diverging pressure
  • negative = contracting/remediating effect

That matches the foundations exactly and should now be treated as canonical across:

  • DriftFinding.kappa_contribution
  • InvariantSignal.kappa_impact
  • PolicyDecision.kappa_contribution
  • rules[].then.kappa_effect
  • GovernanceState.kappa aggregation.

3. GovernanceState as explicit stage/output

Good change. Without an explicit τ_state or equivalent Stage 9, the pipeline still reads like a sequence of transforms plus storage, rather than a composite functor that closes into a workspace-level state object. The original ADR-002 did not yet fully capture that.

4. Enterprise waiver κ adjustment changing from +0.05 to -0.03

This is probably the most subtle but correct patch.

A positive waiver adjustment would mean the waiver itself increases divergence pressure. That is plausible in some governance models, but it would make the enterprise pack harder to keep net-contracting, and it would conflict with your stated pack-level profile of net_contracting: true. The foundations doc says well-formed packs should have negative expected aggregate κ effect.

So changing the waiver adjustment negative makes sense if your interpretation is:

  • a bounded, human-approved waiver can reduce immediate governance pressure relative to a blocking denial, while still remaining visible and auditable.

That is a legitimate model. Just document it explicitly so it does not read like you are “rewarding exceptions.”

The two things I would still tighten

1. cohomological_class needs a global enum definition

You added it to DriftFinding and KnowledgeArtifact, which is good. But unless you define a single enum centrally, you risk divergent meanings.

I would lock one enum in ADR-001 shared substrate types:

type CohomologicalClass = "none" | "h0" | "h1" | "mixed";

And then use it consistently for:

  • DriftFinding.cohomological_class
  • KnowledgeArtifact.cohomological_class
  • GovernanceState.ssot_obstruction_summary.cohomological_class

Reason: the foundations already imply exactly this kind of unified vocabulary.

2. kappa_trend must be tied to a precise temporal rule

Adding the field is good, but it becomes meaningless if its computation is not fixed.

I would define:

  • decreasing iff kappa_t < kappa_{t-1} - ε
  • stable iff |kappa_t - kappa_{t-1}| <= ε
  • increasing iff kappa_t > kappa_{t-1} + ε

with an explicit ε default.

Otherwise different implementations will disagree on trend while agreeing on current κ. The foundations gave the field, but not the rule; rev2 should finish that job.

One important caution on the pack changes

Your updated kappa_profile structure is better than the earlier loose form, but there is one consistency condition you should enforce:

If net_contracting: true, then:

  • expected_net_effect < 0
  • and the pack must not contain any unconditional positive-only rule set whose expected frequency dominates the negative rules.

That sounds obvious, but it should be machine-checkable, not just a descriptive field.

I would make semantic validation enforce:

  • convergence_class = "net-contracting" only if expected aggregate κ effect is negative under the declared model
  • otherwise error or warning

The foundations document already basically states this criterion in prose.

What I would review next before calling this stable

In order:

1. Full ADR-003 consistency pass

You created ADR-003, which is correct as the next hard artifact. Before patching anything else further, check that:

  • GovernanceState field names match ADR-001 exactly
  • OpenAPI response shape matches ADR-003 exactly
  • κ formula notation matches the sign convention you finalized

This matters because κ naming drift (kappa_contribution vs kappa_impact vs kappa_effect) is now system-critical.

2. Semantic validator rules

Your packs now depend on more mathematical semantics. The validator should explicitly check:

  • positive vs negative κ sign legality
  • kappa_profile.expected_net_effect coherence
  • cohomological_class compatibility with H⁰/H¹ booleans
  • pack version compatibility with CGOM-v2 / GEP-v2

The original mathematical foundations already made clear that the engineering taxonomy needs invariant-root mapping. This is where that becomes operational.

3. OpenAPI invariant-centric endpoints

Make sure the delta did not stop at adding endpoints and forget the schemas behind them.

You want:

  • GET /v1/governance-state
  • GET /v1/invariants/{id}/status
  • GET /v1/invariants/I-1/obstructions

But also:

  • GovernanceState
  • InvariantStatus
  • SSOTObstructionSummary
  • obstruction list response schema

The foundations explicitly called for these.

My overall verdict

This is now substantively good.

Not “looks polished.” Actually good.

The rev2 changes fix the most dangerous ambiguity: that Morphism could have ended up with mathematically flavored language but operationally ordinary policy-engine semantics.

You are now much closer to a real load-bearing mathematical substrate.

If I were signing off with action labels

Approve now

  • CGOM v2 / GEP v2 version bump
  • κ sign convention
  • GovernanceState as explicit stage/object
  • pack version bump to 0.2.0
  • kappa_profile becoming structured

Tighten next

  • global CohomologicalClass enum
  • formal kappa_trend rule
  • validator checks for net_contracting
  • full schema parity across ADR-001 / ADR-003 / OpenAPI

Do not delay on

  • patching the semantic validator and OpenAPI schemas to match rev2, because otherwise the docs and packs will be ahead of the executable contract.

The next best thing to show me is either the full ADR-003 or the full rev2 ADR-001 text after patching, so I can do a consistency audit instead of an architectural delta review.