The Customer Problem: The 4 Operational Telemetry Failures

The point-in-time audit scramble

Screenshots and spreadsheet exports are gathered by hand before each audit and start to decay the day they are filed. Nobody can regenerate them.

The cloud SaaS exfiltration risk

Gigabytes of sensitive production logs and configuration shipped to an external multi-tenant compliance vendor before it can tell you anything.

The unverifiable attestation gap

A self-reported claim that a control works, with no queryable record a reviewer can check against the system's actual state.

Fragmented tooling silos

Steampipe, osquery, cnquery and Git each produce their own output, with no shared relational schema to join them in.

The Consequential Solution: Local Evidence Mesh

A point-in-time attestation says a control existed on the day someone signed for it. A digital evidence mesh captures the system's actual state where it runs, as often as you schedule it, into a Resource Surveillance State Database you keep. Netspective engineers are accountable for the parts a tool cannot be.

Local-first execution. The single binary runs inside your secure environment; your evidence stays in your perimeter unless you choose to share the database.
Universal relational schema. Unstructured files, structured CSV and JSON, and the stdout of CLI commands are ingested into normalized uniform_resource tables.
Open SQL and SQLPage. Dashboards and queries are served directly from the SQLite database by surveilr web-ui --port <PORT>.

We build the ingestion harness

The collection scripts, JSONL task bundles and capturable executables for your systems, tested against your environment.

We maintain the crosswalk model

The Secure Controls Framework views that map one control set to the frameworks you are assessed against, kept current as the crosswalk changes.

We review the evidence before the auditor does

A named engineer reads the RSSD, flags gaps and writes up what it shows, so judgment rests with a person, not a script.

Component Architecture & Data Flow

Every pathway ends in the same place: a single SQLite file with a universal schema, which SQL views and the built-in SQLPage web UI read.

One Rust binary: Releases for Linux, macOS and Windows (x86_64), with no separate runtime to install. On Linux it uses only the standard system C and C++ libraries.
The RSSD: A local SQLite database built on the universal uniform_resource table (uri, content, nature, with ingestion metadata) and ingestion-session records alongside. The database is append-oriented: new runs add records rather than rewriting old ones. It is not cryptographically sealed.
Query and review: SQL through surveilr shell, and SQLPage dashboards served by surveilr web-ui --port <PORT> on localhost by default.
Structured data as tables: --csv-transform-auto turns each ingested CSV into its own queryable table, uniform_resource_<file>: SCF_2024.2.csv becomes uniform_resource_scf_2024_2.
Local processing: Ingestion and queries run inside your boundary; nothing goes to a multi-tenant service. The database leaves only when you choose to share it.

The flow the engine's public "How it works" page describes, reduced to the stages its public CLI reference documents. The CLI is surveilr.

Interactive Ingestion Pathway Explorer

Four documented ways evidence enters the RSSD. Each shows the command, what it writes and how to inspect the result yourself.

Pathway 1: Local filesystem walk

Walks a directory (policies, procedures, exports) into the RSSD. Default database: resource-surveillance.sqlite.db.

surveilr ingest files -r ./policies --stats-json
surveilr shell --output table --cmd \
  "SELECT uri, nature, length(content) AS bytes FROM uniform_resource LIMIT 10;"

Writes: one row per file in uniform_resource (uri, content, nature). Inspect: sqlite3 resource-surveillance.sqlite.db ".schema uniform_resource".

Before you ingest: a directory walk also runs every capturable executable it finds (Pathway 4). Run surveilr capturable-exec ls on the directory first, ingest only directories you control, and run collection as an unprivileged user.

Pathway 2: Cloud and system tasks (Steampipe, cnquery)

Runs Steampipe, cnquery or osquery queries described in a JSONL bundle and stores each tool's output. Needs those tools and their credentials. Use read-only credentials: for AWS billing evidence, grant aws-portal:ViewBilling, aws-portal:ViewUsage, aws-portal:ViewAccount, ce:Get* and budgets:ViewBudget (or the AWS Billing job-function policy). The root account is used once to activate IAM access to billing, never for collection.

steampipe plugin install aws
cat cloud-steampipe-surveilr.jsonl | surveilr ingest tasks
cat server-evidence-surveilr.jsonl  | surveilr ingest tasks

Writes: each task's output as resources in the RSSD, one database per run. Hand-off: dump, fingerprint and encrypt before the file leaves your machine.

sqlite3 resource-surveillance.sqlite.db .dump | gzip -c > evidence.db.txt.gz
sha256sum evidence.db.txt.gz > evidence.db.txt.gz.sha256
age -r <reviewer-public-key> -o evidence.db.txt.gz.age evidence.db.txt.gz

Send only the .age file and its checksum, by an access-controlled channel, never a public link. The dump holds configuration, logs and cloud metadata.

Pathway 3: Crosswalk mapping (Compliance Explorer SQL)

Loads the Secure Controls Framework crosswalk CSV and builds per-framework control views from it.

surveilr ingest files --csv-transform-auto -r ingest   # ingest/SCF_2024.2.csv
surveilr shell ./stateless.sql
surveilr shell --output table --cmd \
  "SELECT scf_control, control_description FROM compliance_regime_control WHERE control_type = 'US HIPAA';"

Writes: table uniform_resource_scf_2024_2, then views such as compliance_regime_control (HIPAA and NIST 800-171A), soc2_control, iso27001_control and cmmc_control. The SCF data is published by the Secure Controls Framework under its own license.

Pathway 4: Capturable executables

Any script whose name marks its output format (for example *.surveilr[json].sh) is run during ingestion and its stdout stored, so a shell, Python or Go script becomes an evidence source.

# ./collectors/fetch-data.surveilr[json].sh prints JSON to stdout
surveilr capturable-exec ls            # list what ingestion will run
surveilr ingest files -r ./collectors   # runs it and stores its stdout

Writes: each script's stdout as a resource in the RSSD, recorded against the ingestion session. The engine runs the script during ingestion; you do not run it yourself. Test one: surveilr capturable-exec test file --fs-path ./collectors/fetch-data.surveilr[json].sh.

Commands and flags from the public evidence-engine CLI reference and evidence-collection guide (docs.opsfolio.com) and the compliance-explorer pattern (github.com/surveilr/patterns). Releases install with brew tap surveilr/tap && brew install surveilr.

Verified Proof Ledger (Engineering Ground Truth)

Proof ledger: each claim, its status and what it rests on
Claim	Status	What it rests on
Single Rust binary for Windows, Linux and macOS (x86_64)	Built and tested	Published releases (3.67.0, October 2026) and the Homebrew tap. The 3.67.0 Linux release was inspected with `file` and `ldd` on 2026-11-04 (`docs/specs/cgrce-surveilr-track-spec.md`): it links the standard system C and C++ libraries; it is not a statically linked file.
JSONL task execution (`ingest tasks`)	Designed and documented	The CLI reference and the evidence-collection guide. No recorded run yet.
Local SQLite RSSD created by ingestion	Designed and documented	The CLI reference (`ingest files`, `ingest tasks`, default `resource-surveillance.sqlite.db`). No recorded run yet.
Embedded SQLPage web UI and SQL shell	Designed and documented	The CLI reference (`web-ui`, binds `localhost` by default; `shell`). No recorded run yet.
SCF crosswalk control views	Designed and documented	The public compliance-explorer pattern. No recorded run yet.
Singer taps and PLM issue ingestion (GitHub, Jira, GitLab)	Designed and documented	Commands listed in the CLI reference; no published worked example. Scoped per engagement.
Push-button, automated legal compliance	Not established	Not offered. People interpret the evidence; auditors decide outcomes.
Continuous replication to cloud databases	Not established	Not in the CLI reference; not offered.
Real-time blocking (EDR)	Not established	The engine collects evidence; it does not block activity.

Real-World Operational Scenarios

Illustrative buyer situations built on documented evidence-engine workflows. They are not named client engagements.

Local-first SOC 2 and HIPAA evidence collection

A healthcare SaaS company that will not install a third-party agent across its fleet.

Steampipe (AWS) and cnquery queries run as ingest tasks on one machine you control; the RSSD is dumped to a compressed .db.txt.gz, fingerprinted with sha256sum, encrypted with age and sent by an access-controlled channel for analyst review. The evidence-collection guide documents this for SOC 2 Type 1; a HIPAA programme uses the same mechanism with its own query bundles, scoped per engagement.

Cross-framework control mapping

A contractor regulated by both CMMC and HIPAA, maintaining two control sets by hand.

The SCF 2024.2 crosswalk, loaded once, gives per-framework views across HIPAA, SOC 2, NIST 800-171 and CMMC, so one control set reports to several frameworks. A mapping is a lookup, not an audit determination.

Zero-exfiltration local verification

Regulated medical device software whose runtime environment has no outbound network path.

Logs and configuration collected offline are ingested into a local RSSD on that machine. Reviewers query the RSSD on the machine where it was built with surveilr shell or the local web UI, so evidence is checked without sending it anywhere. It leaves only when you choose to share the file.

Request a 2-Week Evidence Mesh Pilot

One evidence source, on your infrastructure, in two weeks

Week 1: harness and baseline

Ingestion harness configuration, source mapping (cloud accounts, local files, security tools) and a baseline RSSD.

Week 2: review and hand-over

SQLPage dashboards for your questions, SCF crosswalk integration, and the evidence package reviewed with your compliance stakeholders.

Boundaries

The software collects and indexes evidence; you keep responsibility for your compliance obligations.
We provide engineering review, not legal counsel, and we do not guarantee audit outcomes; your auditor decides those.
The engine has no watch mode or top-level transform command; collection runs when you schedule it.

Automated Evidence Mesh & Sovereign RSSD