Fluxor Software builds data and AI infrastructure — cloud-native or fully offline, your choice. Sightlinq, PyEdge, and SchemaShifts came out of solving real problems for real clients across vision, edge, and distributed data — then were productized for anyone to use, at any size, in any industry.
What We Do
Built for Edge Hardware, Cloud Platforms & Distributed Databases
Not Built In A Vacuum
Sightlinq, PyEdge, and SchemaShifts weren't built speculatively and then pitched to customers. Each one solved a real problem for a real client first — in vision analytics, edge IoT, and distributed database governance — and was productized once the pattern proved out. That's still how Fluxor works: from large enterprises to single-site small businesses, what gets built for one client's hardest problem often becomes the next product anyone can use.
Deployment Philosophy
Fluxor doesn't force one deployment model. Every product plugs into the AI and cloud stack you already run, or runs with zero cloud dependency at all — same platform, your choice.
Sightlinq connects to AWS Bedrock, Google Vertex AI, and Azure OpenAI for model backends, and to Azure Blob, S3, or GCS for storage. SchemaShifts governs your database wherever it's hosted. Multi-site and hybrid deployments are a config change, not a re-architecture.
Air-gapped, factory LAN, or remote site with no reliable connectivity — every product runs fully on your own infrastructure with no cloud account, no per-event metering, and no external calls required.
What We Build
Each product stands on its own — different buyer, different problem, no requirement to use the others. Any company, any size, any industry: from a Fortune 50 enterprise to a single-site small business.
End-to-end visual AI training — capture, annotate with AI assistance, train on your own GPU/CPU or a cloud backend (Bedrock, Vertex AI, Azure OpenAI), and deploy back to the edge. Any industry with a camera and a detection problem, not just manufacturing.
Edge stream processing for anyone with sensor or event data and a rule to run against it — no vision required. SQL-style rules, a REST API, and a role-based dashboard, with zero dependencies beyond the standard library.
Schema governance for distributed databases — versioned migrations, immutable audit logs, and distributed locking across Cassandra, Spanner, DynamoDB, CockroachDB, and more. For any company running a distributed database, vision or AI use case not required.
When the answer needs to be custom, not a platform: bespoke vision analytics systems from cloud pipelines to privacy-first on-sensor inference, plus AI infrastructure — self-hosted LLM serving (vLLM), RAG, and MCP integration for teams who want AI without renting someone else's API.
Fluxor Engineering
When the answer isn't a platform, it's a bespoke build. Vision AI systems across retail, logistics, agriculture, safety, and beyond — cloud or edge, image-retaining or privacy-first. And AI infrastructure: self-hosted LLM serving with vLLM, RAG, and MCP integration for teams who want AI on their own terms. Same philosophy, two engineering tracks.
Sightlinq — How It Works
Every step after image capture is automated. The only human action is annotation — and by Round 4, even that is mostly reviewing what the model already got right.
No GPU required. Intel i7-1355U laptop, 30 epochs, 83 minutes. The missing_hole class reached mAP50 0.894 — production-quality for inline inspection on commodity hardware.
Privacy by Design
Most camera-based AI systems treat privacy as a policy — a promise made in a document, honoured until a breach, a misconfiguration, or a subpoena. Fluxor Vision treats privacy as an architecture. The guarantee holds regardless of what happens downstream.
That said, not every deployment should discard the image. Quality inspection needs the frame. Security forensics depends on it. Audit trails sometimes require visual evidence. We support both approaches — traditional image pipelines and on-sensor inference — and help you choose the architecture that fits your context, with a clear view of what each carries with it.
Two architectures, two different sets of trade-offs. Fluxor Vision supports both — the right choice depends on what your deployment actually needs.
GDPR requires that personal data be adequate, relevant, and limited to what is necessary for the stated purpose. On-sensor inference is a direct technical implementation of this principle — if the purpose is to count occupants, producing a count satisfies the purpose. Producing a video archive does not.
A data protection policy states what an organisation intends to do with data. A hardware guarantee defines what the system is architecturally incapable of doing. When pixel data is discarded on-sensor, no policy violation, misconfiguration, breach, or legal compulsion can produce footage that was never created.
A count of persons in a room is unlikely to constitute personal data. A precise skeletal keypoint sequence associated with a named individual may. The output format and combination of signals determines exposure — not the hardware alone. Seek legal review for any inference model whose output could identify or profile individuals.
Regardless of pipeline choice, responsible deployment includes: a Data Protection Impact Assessment scoped to the context; clearly defined retention windows for any stored data; transparency signage where individuals may be present; and a legal review of inference outputs against applicable data protection law.
Full Capability Map
Every capability below is available across both pipeline approaches. The badge indicates the natural fit — but every deployment is a considered decision, not a default.
Responsible deployment — whichever approach you choose
Every Fluxor Vision engagement includes a configuration review against your stated use case, guidance on Data Protection Impact Assessments, retention policy recommendations, transparency signage requirements where individuals may be present, and a frank conversation about whether image capture is justified by the deployment context — or whether structured output is sufficient. We do not have a default answer. We have a process for arriving at the right one.
SchemaShifts + Vision AI
Sightlinq stores every detection — structured, local, completely customer-owned. Customers who want to go further — vector search across millions of inspections, RAG-grounded AI tooling, MCP integration — need a database built for it. Six of the nine databases SchemaShifts governs support native vector search. SchemaShifts handles every schema change that vision data requires as the detection model evolves.
Sightlinq stores every detection — that is exactly what it is designed to do. Customers who want to build vector search, RAG, or MCP tooling on top of that data need a governed database that supports it. That is the role SchemaShifts plays.
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 deployments, SingleStore for sub-millisecond HTAP — SchemaShifts governs every schema change: VECTOR column additions, ANN index creation, embedding dimension upgrades. Immutable audit log included.
Sightlinq does not change. The customer's chosen database gains the governance layer it needs to support vector search, RAG, and MCP as the detection model evolves and new defect classes are added.
Full Technical Deep-DiveVECTOR column type + SAI ANN-OF queries + HNSW indexing. Billions of detection events stored alongside embeddings — no joins, no separate store. Best fit for air-gapped, high-throughput production lines.
GA vector search to 10B+ vectors via ScaNN. SQL + graph GQL + vector in one query. Best for globally consistent, multi-site deployments with regulatory traceability requirements.
Distributed vector indexing via C-SPANN (v25.2). REGIONAL BY ROW keeps embeddings close to where they were generated. pgvector-compatible SQL. Multi-region data residency aware.
HNSW and IVF via Faiss, in-memory for sub-millisecond ANN search. HTAP handles real-time detection writes and historical trend analytics in one engine — no ETL required.
USearch HNSW + Vector LSM storage. pgvector-compatible. Geo-partitioned tablespaces keep per-site embeddings local while a global aggregate view remains queryable centrally.
Native VECTOR type + HNSW index + TiFlash HTAP. GraphRAG support — knowledge graph traversal (defect → batch → supplier) combined with vector similarity for root cause retrieval.
Customers who want vector search, RAG, or MCP on top of their Sightlinq detection data can adopt any of the six SchemaShifts-governed databases that support it. Fluxor can help you choose the right database for your deployment — air-gapped, multi-site, or cloud — and get the schema governance in place.
SchemaShifts
Versioned migrations, immutable audit logs, and distributed locking across Cassandra, Spanner, DynamoDB, CockroachDB, YugabyteDB, and more. SchemaShifts has its own home.
Sightlinq · Visual AI Platform
Annotation, training, and deployment — unified in one interface that runs on your network, on your hardware, with your data.
A 500-image batch that takes 8–10 hours to annotate manually takes 30 minutes by Round 4. By Round 5, it's a spot-check.