Skip to content

Federation

quicue.ca projects federate knowledge through CUE's type system and W3C linked data standards. No external triplestore, no SPARQL endpoint, no contract test framework. CUE unification already is one.

The .kb/ pattern

Each project that uses quicue.ca can maintain a .kb/ directory — a multi-graph knowledge base tracking decisions, patterns, insights, and rejected approaches:

your-project/
  .kb/
    cue.mod/module.cue       # Root module
    manifest.cue              # #KnowledgeBase — declares graph topology
    decisions/
      cue.mod/module.cue      # Independent CUE module
      decisions.cue           # core.#Decision entries
    patterns/
      patterns.cue            # core.#Pattern entries
    insights/
      insights.cue            # core.#Insight entries
    rejected/
      rejected.cue            # core.#Rejected entries

Each subdirectory validates independently with cue vet . — directory structure IS the ontology.

Downstream Consumers

Project Module Patterns Status Has KB
homelab homelab.quicue.ca 14 active no
cmhc-retrofit quicue.ca/cmhc-retrofit@v0 15 active yes
maison-613 rfam.cc/maison-613@v0 14 active yes

Dependency tracking

A downstream project's deps.cue records every definition it imports from quicue.ca:

_pattern_deps: {
    "#InfraGraph": {
        source:  "quicue.ca/patterns@v0"
        used_in: ["graph.cue"]
        purpose: "Dependency graph computation"
    }
    "#BlastRadius": {
        source:  "quicue.ca/patterns@v0"
        used_in: ["projections.cue"]
        purpose: "Transitive impact scope"
    }
}

This is documentation. The enforcement comes from CUE itself — if #InfraGraph changes a field name, every file that imports it fails to unify.

How Federation Works

Multiple teams maintain independent .kb/ directories in their own repos. "Federating" them is just importing and letting CUE unify. If two teams assert contradictory values for the same field, cue vet produces a unification error. Conflicts are caught at build time, not discovered in a meeting six months later.

CUE struct unification is:

  • Commutative — order of import doesn't matter
  • Idempotent — importing the same fact twice is harmless
  • Conflict-detecting — contradictory values fail loudly

No merge strategy. No conflict resolution policy. The lattice handles it.

The #Rejected type

#Rejected requires an alternative field — you can't record "we tried X and it failed" without saying where to go instead. In a federated setup, a failed experiment in one team's repo becomes a navigational signpost for another team.

rejected_001: core.#Rejected & {
    id:          "rejected-001"
    title:       "VizExport pattern for graph rendering"
    date:        "2025-12-10"
    description: "Attempted #VizExport wrapper — CUE exports ALL public fields, causing 4x JSON bloat"
    reason:      "Public field leak: Graph field exported entire input struct (75KB vs 17KB)"
    alternative: "Use hidden _viz wrapper + explicit viz: {data: _viz.data, resources: ...}"
}

Cross-References

SKOS vocabulary alignment enables cross-namespace navigation:

  • skos:exactMatch — "See also" links between equivalent concepts across registries
  • skos:closeMatch — "Related" links between similar concepts in different domains
  • skos:broader / skos:narrower — hierarchical breadcrumbs within a concept scheme

The make check-downstream target runs cue vet on all registered consumers. Renaming a field in #InfraGraph produces a unification error in any consumer that references it, caught at build time rather than discovered in production.