Extending a third-party matrix

A matrix is a self-contained operating model. But when you install matrices from different sources into the same workspace, they don't automatically know about each other. A vendor's customer management matrix and your internal CRM matrix might model the same real-world concepts with different vocabularies. Extensions let you bridge those gaps without modifying either matrix, and create interoperability between the two.

What Extensions Are

An extension is a separate RDF document that get merged into a base matrix at deployment time. Extensions are workspace-scoped: they belong to your workspace and target a specific installed matrix. When Poliglot assembles the matrix, the extension statements are merged alongside the base specification.

Extensions are additive only. You can add new triples (new relationships, new imports, new mappings), but you can't remove or modify triples from the base matrix. This keeps the base matrix's contract intact while layering workspace-specific adaptations on top.

Vocabulary Bridging

The most powerful use of extensions is creating bridges between independently developed matrices. When two matrices model related concepts with different vocabularies, extensions let you declare the relationships.

Aligning concepts across matrices

A vendor's project management matrix uses vendor:Customer. Your internal CRM uses crm:Client. They represent related concepts. An extension declares the relationship using rdfs:subClassOf:

@prefix rdfs:   <http://www.w3.org/2000/01/rdf-schema#> .
@prefix vendor: <https://vendor.example/spec/projects#> .
@prefix crm:    <https://mycompany.example/spec/crm#> .

vendor:Customer rdfs:subClassOf crm:Client .

Once deployed, RARS can reason across both vocabularies. A query for all crm:Client instances will also include vendor:Customer instances, because the subclass relationship is declared in the graph. This is RDFS inference at work: if a vendor customer is a kind of client, then every vendor customer is also a client.

Adding cross-domain relationships

The vendor matrix doesn't know about your CRM, but you need to link vendor projects to your internal client records. An extension adds the relationship:

@prefix owl:    <http://www.w3.org/2002/07/owl#> .
@prefix rdfs:   <http://www.w3.org/2000/01/rdf-schema#> .
@prefix vendor: <https://vendor.example/spec/projects#> .
@prefix crm:    <https://mycompany.example/spec/crm#> .

vendor:Matrix rars-mtx:imports <https://mycompany.example/spec/crm#> .

crm:managedByVendor
    a owl:ObjectProperty ;
    rdfs:domain crm:Client ;
    rdfs:range vendor:Project ;
    rdfs:label "managed by vendor project" .

This extension adds an import (so the vendor matrix can resolve CRM types) and a new cross-domain property. RARS can now traverse from your CRM clients to the vendor's project data.

Specializing with subclass relationships

Your workspace has an industry-specific classification that the base matrix doesn't include. An extension can declare subclass relationships:

@prefix rdfs:     <http://www.w3.org/2000/01/rdf-schema#> .
@prefix vendor:   <https://vendor.example/spec/projects#> .
@prefix industry: <https://mycompany.example/spec/industry#> .

industry:GovernmentProject rdfs:subClassOf vendor:Project .
industry:DefenseProject rdfs:subClassOf industry:GovernmentProject .

RARS can now use these classifications for inference. A query for all vendor:Project instances will include government and defense projects.

When to Use Extensions vs New Matrices

Extensions modify an existing matrix. A new matrix introduces a new domain. The choice depends on ownership and purpose.

Use an extension when:

• You need to bridge two matrices that don't know about each other
• You're adding workspace-specific translations between vocabularies
• The change is about how existing concepts relate, not about new concepts
• You don't own the target matrix

Use a new matrix when:

• You're introducing new domain concepts with their own lifecycle
• The new concepts need their own actions, shapes, and data products
• The change should be versioned and deployed independently

If you find yourself adding entire ontologies through extensions, that's a signal it should be its own matrix that imports the target matrix instead.

How Extensions Are Deployed

When you create or update an extension, Poliglot re-assembles the target matrix with the extension triples merged in. This triggers the same validation pipeline as a normal deployment (namespace checks, import resolution, shape validation). If the extension introduces a violation, the assembly fails and the extension is not applied.

Extensions go through the same validation as base matrix specs. You can't bypass shape constraints or namespace rules.

Summary

• Extensions bridge vocabularies: align concepts with subclass relationships, add cross-domain properties, and create interoperability between independently developed matrices
• Additive only: extensions add triples, they can't remove or modify the base matrix
• Same validation applies: extensions go through the full assembly and validation pipeline