Collective operational memory for software vendors

The 500th site should never
rediscover a bug the 1st already fixed.

PROBE is a shared "HIVE" that learns incident → fix patterns across a vendor's entire deployment fleet — without ever moving a customer's raw logs. Sanitized fingerprints go in; ranked, validated remediations come back, straight into Jira.

The problem

One product. Hundreds of isolated deployments.

A vendor ships one product — an HMS, an ERP, a GitLab-style platform — into hundreds of on-prem or regulated customer environments. Each deployment breaks alone. Logs are siloed and often can't leave the customer's boundary for privacy or security reasons. So the same incident gets re-diagnosed from scratch at Site A, then B, then C — and support cost and MTTR grow linearly with fleet size, while hard-won fixes never travel between sites.

Fleet, not single tenant

Healthcare (Bahmni, Aarogya), financial and government vendors run the same software across hundreds of regulated, walled-off environments.

Logs can't travel

Raw logs carry PII — Aadhaar numbers, health IDs, patient records — and privacy/compliance rules mean they usually cannot leave the deployment.

Knowledge doesn't travel either

Without raw logs to compare, nothing carries the fix from one site's incident to the next site's identical one. L2/L3 support relearns it every time.

How it works

Sanitize the incident down to a fingerprint — never the raw logs.

Because every deployment runs the same software, the fields that make cross-deployment matching possible — service names, error classes, versions, fault taxonomy — are exactly the fields that carry no PII. That means the sanitization boundary and the matching boundary are the same line: stripping the private stuff costs almost nothing in match quality.

Raw incident

Logs, traces and errors stay inside the customer's deployment boundary — they never cross out.

→

Elastic ML categorization

Strips variable tokens (IDs, timestamps, hostnames) down to a symptom skeleton — the shape of the error, not its specifics.

→

Amazon Comprehend redaction

Catches residual PII in the skeleton — Aadhaar numbers, health IDs, anything the categorizer missed.

→

Fingerprint crosses in

Only this derived, client-agnostic fingerprint enters the HIVE — a shared Elasticsearch index — nothing else does.

Stays in the deployment
  • Raw log lines and stack traces
  • Patient / customer identifiers
  • Hostnames, IPs, tenant-specific config
  • Anything that identifies who hit the bug
Crosses into the HIVE
  • Service name, error class, fault taxonomy
  • Product version + date window
  • Symptom skeleton (categorized, redacted)
  • Exactly the fields that make matching work
The loop

Jira is the UI and the state machine.

No custom workflow engine. An anomaly becomes a ticket; the ticket carries the fingerprint; the agent does the searching and posts its reasoning as a comment; a human validates; the HIVE gets smarter for the next incident.

01 · Detect

Anomaly detected on a deployment → a Jira ticket is created, carrying the sanitized fingerprint.

02 · Match

The agent searches the HIVE for prior incidents with the same symptom skeleton across the whole fleet.

03 · Suggest

Posts ranked remediations + runbooks + a confidence score + why it matched as a Jira comment.

04 · Validate

The engineer pings back with new info, corrects the agent, or confirms — the ticket moves to COMPLETE.

05 · Learn

The agent creates or updates a runbook, linked to the anomaly, incident, remediation, ticket and author. The hive gets smarter.

Blast radius

Tying an error back to the change that likely caused it.

Jira tickets and GitHub PRs/commits sync in via native Elastic connectors. Each product version carries a date window, so when a deployment on that version errors, the changes shipped in that window become the prime suspects — linking an incident straight back to the PR that likely introduced it.

Version-scoped suspects

Instead of searching the whole commit history, the agent narrows to the commits and PRs that shipped inside the affected version's window.

Native connectors, no scraping

GitHub and Jira sync into Elasticsearch through Elastic's own connectors — one more thing PROBE doesn't have to rebuild.

Two modes, one contract

The HIVE is a store plus a set of MCP tools.

match_incident, get_resolution, blast_radius, fleet_signal, check_version_risk, submit_outcome, upsert_runbook — the same seven tools serve two different SKUs.

Mode 1 · Bring your own agent

Import the HIVE as an MCP tool

  • Vendor brings their own Agent Builder + LLM
  • Best reasoning quality, fits their existing agent stack
  • Best privacy posture — the vendor's own model, the vendor's own policies
  • PROBE is infrastructure they plug into, not a product they adopt wholesale
Mode 2 · Managed agent

One diagnose() call

  • We run the agent; the vendor calls a single turnkey endpoint
  • More generic, faster to adopt, no agent stack required on their side
  • Same seven MCP tools underneath — same HIVE, same fingerprint contract
  • Right fit for a vendor without existing agent infrastructure
ToolWhat it does
match_incidentFind prior HIVE incidents with a matching symptom skeleton
get_resolutionFetch the validated fix/runbook for a matched incident
blast_radiusFind the PRs/commits in a version's date window that likely caused it
fleet_signalCheck whether other deployments are seeing the same symptom right now
check_version_riskScore a version by its known incident history before rollout
submit_outcomeRecord whether a suggested fix actually worked — the feedback loop
upsert_runbookCreate or update the runbook a validated fix gets linked to
Stack

Elastic is the brain. AWS is edge, privacy and reasoning.

The custom build is small and deliberate on purpose: an orchestrator service, two UI screens, and the discipline of never rebuilding what Elastic already does well.

🔍 Elastic

ML anomaly detection, categorization, retrieval and the agent runtime.

ML anomaly detection CATEGORIZE ES|QL ELSER + hybrid RRF Agent Builder Workflows MCP server Kibana

☁️ AWS

Edge transport, privacy redaction, and the reasoning model.

Bedrock (Claude) Comprehend (PII redaction) IoT Core Greengrass AgentCore
~$0.10

per incident

And falling as the hive learns — later matches need less reasoning, not more.

Suggestion

only, human-in-the-loop

The agent proposes with a confidence score and its reasoning. A human validates before anything is marked COMPLETE.

1

line: sanitize = match

The fields PII-free enough to leave the deployment are exactly the fields that make cross-fleet matching work.

In this repository

What's actually built here today

This repo currently implements two concrete stages of the PROBE pipeline end to end — the Detector (finds the anomaly) and the Remediator (files the Jira ticket once a cause is known) — plus the supporting Elastic ML and pipeline work behind the HIVE vision above.