SKC Examples

These examples describe the SKC data model conceptually.

They are not yet a promise of a stable public API or CLI.

Example source graph

{
  "nodes": [
    {
      "id": "decision",
      "type": "decision"
    },
    {
      "id": "evidence",
      "type": "evidence"
    }
  ],
  "edges": [
    {
      "from": "decision",
      "relation": "supported_by",
      "to": "evidence"
    }
  ]
}

Canonical representation

A canonicalizer may normalize ordering and representation while preserving the declared semantic relationship.

{
  "nodes": [
    {
      "id": "decision",
      "type": "decision"
    },
    {
      "id": "evidence",
      "type": "evidence"
    }
  ],
  "edges": [
    {
      "from": "decision",
      "relation": "supported_by",
      "to": "evidence"
    }
  ]
}

Conceptual semantic core

{
  "n": [
    ["decision", "decision"],
    ["evidence", "evidence"]
  ],
  "e": [
    ["decision", "supported_by", "evidence"]
  ]
}

The compact form is illustrative.

The actual SKC encoding contract must define representation and ordering explicitly before developers can depend on it.

Reconstruction

semantic core
    ↓
decoder / reconstruction rules
    ↓
semantic graph
    ↓
canonicalization
    ↓
equivalence check

Validation result

{
  "ReconstructionFidelity": 1.0,
  "GraphEquivalence": true,
  "Deterministic": true
}

This example demonstrates the shape of a successful result and is not a published benchmark claim.

Developer rule

Until a stable SKC interface is published:

do not depend on undocumented field names
do not treat experimental serialization as stable
record the SKC version used for every experiment
retain source fixtures alongside reported metrics
distinguish measured results from illustrative examples

Return to SKC Overview →.