Sightlinq · SchemaShifts · Vector Search · RAG · MCP

SchemaShifts Takes
Vision Further.

🎯

Sightlinq

Trains · Detects · Stores

customers adopt a SchemaShifts-governed database

📋

SchemaShifts

Governs schema · versioned migrations · immutable audit log

detection events · embeddings · vector indexes

🗄️

Vector-Capable Database

Cassandra · Spanner · CockroachDB · SingleStore · YugabyteDB · TiDB

ANN search · vector similarity · MCP

🧠

RAG + MCP

Evidence-grounded answers from inspection history

✔ Customer-controlled ✔ No separate vector store ✔ Schema governed

Sightlinq stores every detection — class, confidence, timestamp, camera ID. That is exactly what it is designed to do. But customers who want to go further — vector search across millions of inspections, RAG-grounded AI chat, MCP integration — need a database built for it.

That is where SchemaShifts comes in. Six of the nine databases SchemaShifts governs now support native vector search. When a customer adopts one of those databases, SchemaShifts handles every schema change the vision data layer requires — VECTOR column additions, ANN index creation, embedding dimension upgrades — with an immutable audit trail and rollback in one command.

Sightlinq does not change. The customer's database gains governance. And the inspection history that was locked in rows becomes searchable by meaning — a foundation for RAG, MCP, and whatever comes next.

Choose Your Database Database Profiles

The Opportunity

Detection Is Data.
SchemaShifts Makes It Searchable.

Sightlinq stores every detection — structured, local, reliable. Customers who want to go further have everything they need in that data. The question is which database they move it into, and whether that database's schema is governed well enough to support vector search, RAG, and MCP as the detection model evolves.

What Sightlinq gives you

Every detection event — defect class, confidence score, bounding box, camera ID, timestamp, batch ID — stored in DB on your own infrastructure. Clean, structured, queryable. A foundation you own completely.

What local DB cannot give you at scale

Semantic similarity search across millions of inspections. Vector indexes that survive billions of rows. Multi-site consistency. RAG retrieval that grounds AI answers in historical evidence. MCP integration. These require a database built for distributed, vector-native workloads — and a schema governance layer that keeps up as the model evolves.

What SchemaShifts enables

Six of the nine databases SchemaShifts governs support native vector search. When a customer adopts one — Cassandra 5 for air-gapped production lines, Spanner for global multi-site consistency, SingleStore for sub-millisecond HTAP — SchemaShifts governs every schema change that vision data requires: VECTOR column additions, ANN index creation, embedding dimension upgrades, rollback on performance regression. Immutable audit log included.

Why governance matters for vector schemas

A VECTOR column addition is not a routine ALTER TABLE. It changes the embedding dimension, invalidates existing ANN indexes, and may require a backfill from the inference pipeline. Without a versioned migration tool that understands this sequence, schema drift accumulates silently. SchemaShifts versions the entire lifecycle — from first VECTOR column to third embedding model upgrade — with the same rigour as any production migration.

Architecture

Two Deployments.
One Governed Stack.

Whether your data must never leave the building or you operate across ten factory sites globally, the architecture adapts. The database changes. The governance does not.

Air-gapped — Cassandra 5 + cassachange

🎯

Sightlinq detects · writes to DB

Detection events stored locally — class, confidence, bounding box, camera ID, timestamp, batch ID. Structured. Owned entirely by the customer.

⚙️

Customer pipeline — embed + write

Customer-built or third-party pipeline reads DB, generates embeddings from detection images using a local embedding model, writes detection + VECTOR to Cassandra 5. SchemaShifts governs that schema.

INSERT INTO detections (id, class, conf, ts, embedding) VALUES (?, ?, ?, ?, ?)

🗄️

Cassandra 5 — governed by cassachange

VECTOR column + SAI ANN-OF index. Every schema change — column addition, index creation, dimension upgrade — versioned by cassachange with immutable audit log and rollback.

CREATE CUSTOM INDEX ON detections(embedding) USING 'StorageAttachedIndex';

🧠

RAG + MCP — built by customer

Customer builds RAG queries against the vector store. MCP integration connects the inspection history to AI agents. SchemaShifts ensures the schema beneath it is version-controlled and audit-ready.

SELECT * FROM detections ORDER BY embedding ANN OF ? LIMIT 10

📋

cassachange — schema governance throughout

Every VECTOR column addition, index change, or embedding dimension update is a versioned migration. LWT distributed locking prevents concurrent conflicts. CI/CD integrated.

cassachange deploy --profile prod --tag 3.2.0

✔ Zero internet ✔ Customer-controlled pipeline ✔ Schema governed end-to-end ✔ Full audit trail

Why Cassandra 5 for air-gapped deployments

Cassandra was built for write-heavy, time-series workloads at scale — exactly the pattern a 24/7 production line generates. A single inspection line producing one detection every 100ms generates 864,000 events per day. Across ten lines, that is 8.6 million rows daily. Cassandra handles this without partitioning anxiety.

Cassandra 5's native VECTOR type stores the embedding in the same row as the detection event. The SAI ANN-OF query finds visually similar historical detections at millisecond latency across billions of rows — giving customers a foundation to build RAG and MCP tooling on top, without a separate vector store.

cassachange governs the schema with LWT distributed locking. As the detection model evolves — new defect classes, embedding dimension changes, new index types — cassachange versions every migration. The question "who added the embedding column, when, and was it approved?" has an automatic answer.

Regulatory fit. Manufacturing environments under ISO 9001, pharmaceutical sites under 21 CFR Part 11, and defence contractors under ITAR all require schema changes to be documented, approved, and auditable. cassachange's immutable audit log satisfies this requirement automatically — no additional tooling.

Multi-site — Spanner + spanchange

🎯

Sightlinq at each factory site

Each site runs Sightlinq locally. Detection events stored in local DB. No raw image leaves the factory — only structured detection metadata moves.

⚙️

Customer pipeline — embed + write to Spanner

Per-site pipeline reads DB events, generates embeddings locally, writes to Spanner via private VPC endpoint. spanchange governs the Spanner schema across all sites.

INSERT INTO detections (site_id, id, class, embedding) VALUES (@site, @id, @cls, @vec)

🌐

Spanner — globally consistent · governed by spanchange

Strong consistency across all sites. 10B+ vector search via ScaNN. VECTOR INDEX additions tracked by spanchange through Spanner's async DDL — no other tool handles this correctly.

SELECT * FROM detections ORDER BY embedding <=> @query LIMIT 10

🧠

Cross-site RAG + MCP — customer-built

Customer builds RAG or MCP tooling on top of the Spanner vector store. Cross-site pattern recognition — a defect at APAC-03 matched against EMEA-01 history — without centralising raw images.

📋

spanchange — schema governance across all sites

Same migration tag deployed identically across dev, staging, prod, and every site's keyspace. Serialisable audit log. Async DDL completion tracked and waited. Rollback-ready.

spanchange deploy --profile prod-global --tag 4.1.0

✔ Global consistency ✔ No raw image egress ✔ Customer-controlled pipeline ✔ Serialisable audit log

Why Spanner for multi-site deployments

Spanner is the only database that is both globally distributed and strongly consistent by default. For a quality system spanning ten factory sites across three continents, this matters: a detection event written at APAC-03 is immediately visible to a query from EMEA — with the same read guarantees as a local query.

Spanner's vector search scales to 10 billion+ vectors using Google's ScaNN algorithm. Combined with Spanner Graph (GQL), customers can traverse root cause chains — defect → batch → supplier → shift — in a single query that also performs vector similarity search. SchemaShifts governs the VECTOR INDEX lifecycle that makes this possible.

spanchange handles Spanner's async DDL model — VECTOR INDEX additions are long-running operations that must be polled to completion. spanchange tracks and waits, surfacing completion in the audit log. No other migration tool handles this correctly.

Privacy by design. Only detection metadata and embedding vectors leave each factory site — never raw images. The embedding is a mathematical representation that cannot be reverse-engineered into the original image. GDPR Article 5(1)(c) data minimisation compliance is preserved at the architecture level.

Database Profiles

Six Databases.
One Governance Platform.

Every database below supports native vector search — image embeddings stored and queried in the same system as detection metadata. SchemaShifts governs all six with an immutable audit trail as the schema evolves.

Apache Cassandra 5

cassachange

Vector · ANN

VectorVECTOR(n) column type · SAI ANN-OF queries · HNSW indexing · cosine / dot product / euclidean

RAG fitBillions of detection events + embeddings in one table. No joins. Sub-10ms ANN search at write-heavy throughput.

GovernanceLWT distributed locking · immutable history keyspace · CI/CD integration · 23-rule schema analyser (enterprise)

LockingCassandra LWT — prevents concurrent migration conflicts across CI pipelines

Best for: Air-gapped, high-throughput production lines. Single-site or factory-LAN deployments. When write speed and query simplicity matter more than global consistency.

Google Spanner

spanchange

Global · 10B+

VectorGA vector search to 10B+ vectors · ScaNN ANN algorithm · KNN + ANN · SQL + GQL + vector combined queries

RAG fitCross-site vector search with strong consistency. Graph traversal (defect → batch → supplier) in same query as similarity search.

GovernanceAsync DDL tracking · serialisable transaction locking · shadow test replay · multi-database pipeline deploys

LockingSpanner serialisable transactions — global deploy lock across all regions

Best for: Multi-site global deployments. Regulatory environments requiring strong consistency and global audit trail. When cross-site pattern recognition is the primary RAG use case.

CockroachDB

cockroachchange

pgvector · C-SPANN

VectorC-SPANN distributed vector indexing (v25.2) · pgvector-compatible SQL · prefix column partitioning · REGIONAL BY ROW

RAG fitEmbeddings indexed per camera (prefix column). Billion-vector index behaves like per-camera index. Geography-aware: EMEA search stays in EMEA nodes.

GovernanceMulti-region topology as code · DDL background job monitoring · zone config lifecycle · hash-sharded index scaffolding

LockingDistributed SQL serialisable transactions — concurrent deploy prevention at database level

Best for: Multi-region deployments where per-site data locality matters. PostgreSQL-compatible teams. When vector search must respect data residency boundaries.

SingleStore

singlestorechange

HNSW · HTAP

VectorHNSW + IVF + IVF-PQ via Faiss · in-memory vector indexes · VECTOR INDEX HNSW/IVF lifecycle managed by singlestorechange

RAG fitSub-millisecond ANN search (in-memory). HTAP: real-time detection writes (rowstore) + historical trend analytics (columnstore) in one engine.

GovernanceVECTOR INDEX lifecycle versioned · SHARD KEY + SORT KEY migrations · 7-rule analyser catches sharding anti-patterns

LockingDistributed locking at deploy time — prevents concurrent migration conflicts

Best for: High-frequency inline inspection where detection, analytics, and vector search all run at millisecond latency. When OLTP and OLAP must coexist without ETL.

YugabyteDB

ybchange

pgvector · USearch

VectorUSearch HNSW engine + Vector LSM storage · pgvector-compatible SQL · ybhnsw distributed index · cosine / L2 / inner product

RAG fitGeo-partitioned tablespaces keep per-site embeddings local. Colocation enables fast local ANN queries. Global view always available centrally.

GovernanceTablegroup + colocation YAML migrations · geo-partitioned tablespace lifecycle · xCluster DDL sequencing hints for replication

LockingYB-aware distributed locking — handles xCluster DDL sequencing correctly where other tools fail

Best for: PostgreSQL teams scaling to distributed infrastructure. Multi-site deployments where local query latency matters and global consistency is required for aggregate reporting.

TiDB

tidbchange

HTAP · GraphRAG

VectorNative VECTOR type · HNSW index · auto-embedding generation at insert · TiFlash OLAP engine for analytics

RAG fitGraphRAG: knowledge graph traversal (defect → batch → supplier → shift) combined with vector similarity. Root cause chains retrieved as grounding context.

GovernanceSQL + YAML hybrid migrations · TiFlash replica lifecycle · resource group versioning · TiDB Cloud Serverless PARTIAL status tracking

LockingDistributed locking — prevents concurrent DDL conflicts across OLTP and OLAP layers

Best for: Complex root cause analysis where defect → process → supply chain relationships must be traversed. When HTAP + GraphRAG + vector search are all needed in one system.

RAG in Practice

What Customers Can Build
on a Governed Vector Store.

Once detection data is in a SchemaShifts-governed vector database, customers can build RAG and MCP tooling on top. The schema governance means that as the detection model evolves, the vector layer evolves with it — versioned, audited, and rollback-ready.

Scenario 1 — Root cause retrieval

Quality Manager, Line 1, 06:30"Have we seen this bridging pattern before? When did it last appear and what was the root cause?"

Customer RAG tool — grounded on Cassandra 5 vector store (cassachange governed) 11 visually similar cases found across inspection history. 9 occurred on Line 2 during batch L2406-C on 2026-07-14 to 2026-07-17. Metadata correlation: stencil temperature logged 2.1°C below threshold on all 9 shifts. Line 1 showed no occurrences during the same period. The remaining 2 cases — 2025-11-03 — preceded a stencil supplier change flagged in batch records. Recommend checking current stencil temperature calibration logs.

Retrieved: 11 detection events · ANN search: 38ms · Schema governed by cassachange

Scenario 2 — Cross-site pattern recognition

Regional Quality Manager, EMEA, 09:15"Is this missing-hole defect pattern appearing anywhere else across our sites?"

Customer RAG tool — Spanner global vector search (spanchange governed) 23 visually similar cases across 3 sites in the past 30 days. APAC-03: 14 cases (component U4, pin 3). EMEA-01: 7 cases — same component, same pin. AMER-02: 2 cases — isolated. Common factor: all boards from supplier batch BRD-2026-Q3-14. APAC-03 and EMEA-01 share the same supplier run; AMER-02 does not. Recommend escalating to procurement immediately.

Retrieved: 23 events across 3 sites · Spanner global ANN: 94ms · Schema governed by spanchange

Scenario 3 — Schema audit

MLOps Engineer"When did we add the spurious_copper class to the schema? Who ran the migration and what changed?"

cassachange audit log — immutable, append-only V2.4.0__add_spurious_copper_class.cql deployed 2026-06-12 14:23:07 UTC by ci-runner-04, run ID 7f3a. Script added: ALTER TABLE detections ADD spurious_copper_conf float; ALTER TABLE detections ADD embedding_v2 VECTOR(1536); CREATE CUSTOM INDEX. Tag: release-2.4.0. 0 errors. Prior embedding_v1 (768 dimensions) remains queryable — no data dropped.

Source: cassachange history keyspace · Immutable · SOC2 CC6.1 compliant

Cassandra 5 — detection + vector schema

-- V1.0.0__create_detections.cql CREATE TABLE inspection.detections ( id UUID, camera_id TEXT, site_id TEXT, ts TIMESTAMP, class TEXT, conf FLOAT, bbox LIST<FLOAT>, batch_id TEXT, PRIMARY KEY ((site_id, camera_id), ts, id) ) WITH CLUSTERING ORDER BY (ts DESC); -- V2.0.0__add_embedding.cql (cassachange governed) ALTER TABLE inspection.detections ADD embedding VECTOR(1536); CREATE CUSTOM INDEX detection_embedding_idx ON inspection.detections(embedding) USING 'StorageAttachedIndex' WITH OPTIONS = { 'similarity_function': 'cosine' }; -- RAG query — ANN search SELECT id, class, conf, ts, batch_id FROM inspection.detections WHERE site_id = 'EMEA-01' AND class = 'missing_hole' ORDER BY embedding ANN OF [0.12, -0.34, ...] LIMIT 10;

SingleStore — HNSW vector index + HTAP

-- V3.1.0__add_hnsw_index.sql (singlestorechange) ALTER TABLE detections ADD VECTOR INDEX embedding_hnsw (embedding) INDEX_TYPE HNSW_FLAT METRIC_TYPE EUCLIDEAN_DISTANCE; -- Hybrid: vector similarity + SQL filter SELECT id, class, conf, batch_id, DOT_PRODUCT(embedding, JSON_ARRAY_PACK(?)) AS similarity FROM detections WHERE site_id = 'APAC-03' AND ts > DATE_SUB(NOW(), INTERVAL 90 DAY) ORDER BY similarity DESC LIMIT 10; -- TiFlash replica for analytics (tidbchange pattern) ALTER TABLE detections SET TIFLASH REPLICA 1;

Schema Governance

The Model Evolves.
The Schema Must Keep Up.

Every time Sightlinq trains a new model version, the schema may change — new defect classes, new embedding models with different dimensions, new vector index types. Without governance, these changes accumulate as undocumented, untracked drift. With SchemaShifts, every change is versioned, auditable, and reversible.

🔢 New defect class added

A new defect type — spurious_copper — is added to the detection model. The schema needs a new column. cassachange scripts the ALTER TABLE, versions it as V2.4.0, applies it with LWT locking across all Cassandra nodes, and writes the event to the immutable audit log. If the column causes unexpected query performance issues, cassachange rollback reverses it in one command.

📐 Embedding model upgraded

The local embedding model is upgraded from 768 to 1536 dimensions. The VECTOR column width changes. The SAI index must be rebuilt. cassachange scripts the sequence: ADD COLUMN embedding_v2 VECTOR(1536), CREATE INDEX, backfill from the inference pipeline, DROP COLUMN embedding_v1 — as four versioned scripts with a dependency chain. Zero downtime. Full audit trail.

🌐 New factory site onboarded

A new site is added to the Spanner deployment. spanchange applies the same migration history from scratch against the new keyspace — CREATE TABLE, ADD VECTOR column, CREATE INDEX — in the correct order, with the same immutable audit log. The new site's schema is guaranteed identical to every other site's schema at the same tag.

🔍 SOC2 audit request

"Who changed the schema on the production detection database, when, and was it approved?" cassachange's append-only history table answers this automatically — operator identity, timestamp, run ID, script checksum, outcome. No additional tooling. No manual evidence gathering. The audit trail is the migration history.

Sample audit log — detection schema evolution

Timestamp	Run ID	Event	Operator	Script	Detail
2026-01-15 09:11:02	3a1f	DEPLOY_END	ci-runner-02	V1.0.0__create_detections.cql	44ms SUCCESS · tag=1.0.0
2026-03-22 14:23:07	7f3a	DEPLOY_END	ci-runner-04	V2.0.0__add_embedding.cql	VECTOR(1536) + SAI index · 312ms
2026-05-11 08:44:33	9b2c	DEPLOY_END	ci-runner-04	V2.4.0__add_spurious_copper.cql	ALTER + new float col · 29ms
2026-07-03 16:02:19	c4d1	DEPLOY_END	ci-runner-07	V3.0.0__upgrade_embedding_v2.cql	VECTOR(1536→2048) · index rebuild · 8.2s
2026-07-03 16:03:01	c4d1	ROLLBACK	ci-runner-07	V3.0.0__upgrade_embedding_v2.cql	Performance regression detected · rolled back in 1.1s

SchemaShifts TakesVision Further.

Detection Is Data.SchemaShifts Makes It Searchable.

Two Deployments.One Governed Stack.