Frequently asked questions

Any organisation with operational data spread across systems that were never designed to talk to each other — ERP, ticketing, infrastructure metrics, sensor telemetry, and more. SCRAPE is especially valuable when events in one system have invisible ripple effects across others and answering "what caused what?" requires manual cross-referencing that does not scale.

Yes. SCRAPE discovers your data schema at runtime — it never hardcodes column names or data structures. If your systems produce structured or semi-structured operational data, the platform can ingest and correlate it. Every deployment is custom-built for your specific ecosystem during a discovery phase.

Incident root cause: "Which upstream event triggered this alert?" Operational impact: "What processes were affected by this system event?" Process correlation: "How do changes in one system ripple across teams and tools?" Historical patterns: "What sequences of events consistently precede the outcomes we care about?"

SCRAPE uses pluggable source interfaces. It can connect to ticketing systems (Jira, ServiceNow, and others), ERP platforms, infrastructure metrics databases, CSV exports, and custom APIs. Adding a new source is an engineering task during deployment — the correlation engine is source-agnostic.

A change is only flagged when SCRAPE can show two things at once: that the change is real and not just noise, and that it is large enough to matter at an operational scale. Borderline results are filtered out before they reach your team. The bar is set high on purpose so the events you see are the ones worth acting on.

The model is grounded in your actual systems, not generic patterns. It is given the real entity names and structure of your live data so it maps extractions to things that exist rather than hallucinating. Low-confidence extractions are filtered out before they enter your results. The extraction is tuned to your domain during the discovery phase.

It gets skipped with a reason logged. Skipped records appear in the results table with their skip reason. Nothing is silently dropped, so you can audit anything SCRAPE chose not to act on.

Pre-built Grafana dashboards are auto-provisioned on deployment. These include fleet and asset overviews, per-asset operational history, metric deep-dives with cross-system event overlays, correlation detail, event tables with measured impact, component lifecycle timelines, and cumulative operational hours. All use template variables for filtering by asset, category, date range, or individual event.

Every time a component is replaced on an asset, that creates a generation boundary. Gen 1 is from the asset's first operational session to the first replacement. Gen 2 is from the first replacement to the second. And so on. Each generation records install and replacement timestamps, total operational hours within that window, session/cycle count, and current status (in-service or replaced). This is rebuilt automatically at the end of each pipeline run.

Yes, that is the intended next step. The structured output is a labeled dataset derived from unstructured records. With enough history, you can quantify how often issues recur, surface assets or services that behave unusually, track reliability and longevity trends, or feed the data into your own predictive pipelines. No manual labeling required: the LLM did it.

SCRAPE compares behavior around each event against a relevant comparison period. If operational patterns shift for reasons unrelated to the event in question, results can be affected. The high bar SCRAPE applies before flagging anything helps filter out borderline cases, and the discovery phase scopes deployment-specific tuning for environments where seasonality or known external drivers are strong.

The results live in a standard relational database. You can query them directly with any SQL client, connect BI tools (Tableau, Metabase, Looker), or build custom dashboards on top of the API. The backend exposes paginated, filterable endpoints for all result data.

Yes, as long as they are PostgreSQL-compatible. SCRAPE discovers your schema at runtime — you need tables with timestamps, entity identifiers, and the data columns relevant to your use case. The mapping is configured during the discovery phase.

Only if you choose a cloud-hosted LLM provider — in that case, only the text needed for extraction is sent. Raw operational data never leaves your infrastructure. For fully air-gapped operation, deploy a local LLM model and nothing leaves your network at all. In all cases, your data is read-only — SCRAPE never modifies your source systems.

SCRAPE is not a SaaS product. Every deployment is custom-built for your ecosystem by Oberth Systems engineers. Engagements begin with a discovery phase to map your data sources, understand the relationships between your systems, and define the cause-and-effect correlations that matter to your business. From there, we build and deploy a SCRAPE instance tailored to your environment.