Capture first
Preserve the original observation before higher-level interpretation changes how it is understood.
Program 02 ยท Operational intelligence
Scryer
Scryer by Savogelt is an operational-intelligence platform in development. It is being built to connect physical systems, machines, software, documents, data, sensors, and AI into a live, evidence-backed model of an organization's environment.
The aim is to observe what exists, reconcile changes over time, and make the record searchable and understandable. That record provides the basis for controlled reasoning and automation. Machine vision is where Scryer started, and remains one way it observes the environment.
Active developmentPre-commercial
SCRYER / ENVIRONMENT MODEL
ACTIVE DEVELOPMENT
- 01Observesources + signals
- 02Structureentities + relationships
- 03Reconcilestate + changes
- 04Retainhistory + provenance
- 05Understandsearch + reasoning
- 06Actcontrolled automation
TARGET WORKFLOW / IN DEVELOPMENT
SCRYER
Purpose
See what exists. Know what changed.
Understand why. Act through controlled automation.
A machine changes state. A service is updated. A requirement is revised. Each leaves a record somewhere, but the relationship between those records is often missing.
Scryer is being designed to bring those sources into a continuously reconciled environment model: what is present, how it relates, what changed, and what evidence supports the record.
Camera processing, document extraction, software records, and sensor data need different tools and checks. Each must preserve what was observed, what was inferred, and what still needs review. Actions should remain bounded by explicit authority and a record of what was done.
Engineering principle
Keep the observation behind the result.
Separate fact from inference
Pixels, source text, system records, measurements, extracted values, and model interpretations should remain distinguishable.
Make uncertainty visible
A useful environment model should communicate what it knows, what it estimates, and where confidence is limited.
Use deterministic tools for measurement
Geometry, calibration, measurements, transforms, and repeatable image processing should remain grounded in deterministic computation wherever practical.
Keep processing local when useful
Scryer is being designed around local networks, edge devices, and locally available compute rather than requiring cloud-first operation.
Retain provenance
Useful results should remain connected to their sources, observation and processing history, and relevant device, calibration, software, and model information.
System architecture
A shared model. Distinct responsibilities.
These modules describe the architectural direction. They are not a list of released products; working foundations and unfinished capabilities are separated in the development state below.
Scryer Core
Shared services and controlled execution.
The intended foundation for coordinating modules, preserving records, and applying access and execution boundaries.
Reasoning and automation should work from evidence and explicit authority, with a traceable record of their inputs and actions.
Scryer Environment Model
The environment and its relationships.
SEM is the generic model at the center of Scryer: physical assets, machines, hosts, software and services, networks, documents, and requirements.
It also covers agents, models, datasets, jobs, sensors, cameras, workflows, evidence, and events. The aim is to preserve their relationships, sources, and changes over time.
Scryer Connect
Bring existing systems into context.
The intended integration layer for software, data sources, machines, and operational systems, with source identity and provenance preserved.
Connections belong behind product-level interfaces. The architecture should allow implementations and providers to change without redefining the model.
Relationship: Sources feed the environment model; Core and the surrounding modules are intended to make that record usable for search, reasoning, and controlled action. Savogelt's environment is one deployment of SEM, with its own standards and workflows.
Modules around the model
Adopt the portions an operation needs.
Scryer Edge is intended for local sensing and processing; Scryer Mobile for capture, field observations, and operator interaction.
Scryer Vision covers machine-vision interpretation and measurement; Scryer Document covers source-linked document reading and extraction.
Scryer Observe is intended to track state, events, and changes across the environment.
Scryer SDK and Scryer API are the planned extension and access interfaces for integrations, tools, and applications.
Evidence workflow
Different sources. Traceable evidence.
Different sources need different processing paths. The target is a shared record that people and tools can inspect, search, and trace back to its source as the environment changes.
Acquire
Observe machines and sensors, read software and service records, capture images, or retain a document and its pages.
Process by source
Use calibration and measurement for images, text and layout extraction for documents, and source-specific checks for system data.
Reconcile + review
Compare new evidence with recorded state and requirements. Keep conflicts, uncertain readings, and unresolved relationships visible for review.
Retain evidence
Keep results with source locations, timestamps, change and processing history, and review state.
Use with context
Make the record searchable and available for reasoning and controlled automation, preserving its limits, provenance, and authorization boundaries.
Intended applications
Context for operational work.
Intended for industrial, engineering, manufacturing, laboratory, and other operational environments where provenance and local control matter. Integration and validation remain part of the development work.
Environment inventory
Relate assets, hosts, services, networks, and sensors to the work they support, with evidence for what is present and where it belongs.
Change history
Track configuration, document, and machine-state changes over time. Keep the evidence needed to investigate dependencies and explain what happened.
Manufacturing inspection
Surface condition, feature presence, assembly verification, orientation, defects, process evidence, and dimensional inspection.
Machine observation
Monitor machines, fixtures, tooling, workpieces, process states, and physical events that are difficult to expose through software alone.
Measurement
Calibrated image-based measurement, spatial relationships, geometry extraction, alignment, and change detection. Multi-view capture and 3D reconstruction for engineering reference data.
Controlled automation
Use reviewed evidence to support bounded workflows, with explicit permissions, human review where needed, and a record of actions and results.
Robotics
Provide visual observations and derived spatial information to cybernetic and robotic systems without binding the vision layer to a single robot architecture.
Engineering documentation
Connect photographs, observations, measurements, inspections, and visual evidence to the systems and components they describe.
Technical document reading
Recover text and structured content from standards and technical PDFs for controlled ingestion into engineering knowledge. Manuals and drawings are intended uses; reliable extraction of their content still needs validation.
Deployment + technical direction
Keep control of your environment.
Scryer is intended to be vendor-neutral and self-host-first, with on-premises and air-gapped deployment as design goals. SaaS should be an option, not a dependency.
Customers should be able to adopt useful modules without deploying the whole system. Hardware, operating systems, storage, compute, and model providers belong behind product-level interfaces. Deployment modes and integrations still need implementation and validation.
Use the right tools for the job. Geometry, calibration, and repeatable measurements belong in deterministic tools. AI can support interpretation, comparison, explanation, and interaction, with its inferences kept distinct from observations and commands.
Document reading also needs page geometry, text recovery, and checks on symbols and table relationships. A plausible transcription can still change technical meaning. Model output does not replace source review.
Development state
What works. What is in development.
Mobile foundationScryerMVP prototype
Working foundation
Core Android application and basic interactive functionality, providing a foundation for the Scryer Mobile direction.
Mobile visionCapture + overlay
In development
Progressive integration of camera, processing, visualization, measurement, and calibration functions.
Environment modelSEM
System design
Generic organization and state model, with Savogelt as the first reference deployment. Continuous reconciliation and shared search, reasoning, and automation remain development goals.
Core + integrationsConnect, Observe, SDK + API
Product direction
Module boundaries, system connections, change tracking, and controlled execution describe the intended architecture, not a completed integrated platform.
Edge deploymentScryer Edge
Planned
Distributed sensing and local processing on compatible hardware. Broader on-premises and air-gapped deployment remain design goals.
Manufacturing integrationInspection + process observation
Research + prototypes
Research into integration with Savogelt fabrication, inspection, and automated manufacturing systems.
Document readingScryer Document direction
In development
Working OCR and retained source evidence; structured parsing and validation under development. Technical-symbol and table extraction remain unresolved validation work.
Commercial statusAvailability
Pre-commercial
Scryer is an active Savogelt research and development program, not a released production product.
First customer + reference deployment
Built by Savogelt. Used at Savogelt.
We started by looking for an accessible way to use machine vision on non-standard hardware. We couldn't find one that fit, so we started building Scryer.
Those systems need both physical observations and technical references. An inspection records what was found; a standard or drawing may establish what needs to be checked. Software, machines, and workflows supply the rest of the context.
Savogelt is the company building Scryer and its first customer. Our reference deployment brings that work into Savogelt's own environment model as the platform develops.
Our standards, equipment, infrastructure, ontology, workflows, and internal governance belong to that deployment. Other organizations should be able to model their own environments without adopting Savogelt's operating rules.
Research + collaboration
Bring an operational problem.
Savogelt is open to collaboration on environment modeling, system connections, machine vision, technical-document reading, and evidence-backed automation.
If you're working in these areas, tell us what you're trying to observe, connect, understand, or automate.