SolarNorth
Plumbline · The ongoing discipline

Know the moment your system drifts.

Plumbline is continuous read-only monitoring of a deployed system against a declared scope. When the system deviates, in behavior, structure, or intent, you know immediately, you know how far, and you have an artifact you can hand to counsel.

The architectural commitment

The instrument cannot become the vector.

SolarNorth agents have no write access to any customer system. Not under any credential. Not in any escalation path. Not in any "emergency" override. The architecture makes write access structurally impossible, not merely disallowed. Most observability and security tooling asks for write permissions to be useful. We made the opposite bet.

A monitoring system with write access is itself a risk surface. It can be weaponized. It can be the vector for a supply-chain attack. It can cause the incident it was hired to prevent.

A system with structurally read-only architecture cannot do any of those things. The answer to the question "what if Plumbline is compromised?" is the architectural answer.

For procurement review, for audit, for any conversation with a regulator, the claim simplifies. We observe. We do not touch. That is the architectural commitment, and it is the same commitment on day one as it is in year five.

Continuous conformance, not periodic scans.

01

Scope declaration

The explicit specification of what the system is supposed to be doing, derived from an Illuminate baseline or declared directly. This is the north the system is measured against.

02

Always-on analysis

A six-month audit finds the sum of six months of change with no attribution. Plumbline sees deviation at the moment it appears.

03

Three layers of deviation

Behavioral (doing something different), structural (architecture has changed), intent (responsibilities outside declared scope). All three evaluated continuously.

04

Alerting with context

Not 'something changed' but 'this specific deviation, against this specific scope reference, owned by this specific team, at this severity.' Actionable, attributable, defensible.

Every drift event is an artifact.

Plumbline produces more than alerts. Every detected deviation is captured as an evidentiary artifact: what drifted, when, against which scope reference, with what severity, owned by which team, and what was done about it. The audit trail is continuous and immutable.

For a regulated organization, this is the difference between having observability and having a defensible record. If a regulator or opposing counsel asks when you knew, the answer is in the artifact.

Supported evidentiary formats

  • · SOC 2 audit artifacts
  • · HIPAA security incident records
  • · SOX change-management evidence
  • · Generic audit-trail export
Drift event · 2026-04-14T09:14Z
Severity 2
Behavioral excursion · payments-svc
Against scope
scope/payments-v3.4 · §2.1
Layer
Behavioral · external call
Owner
team/payments
Detected
T+11s after deploy
Status
Awaiting acknowledgment
artifact://drift/2026-04-14/payments-svc-3a7f

Architecture and scale.

Tenancy

Single-tenant by default. Observation data, scope references, and drift artifacts never cross customer boundaries, even in memory. Enterprise tier supports customer-deployed installation.

Integration surface

Read-only access to source control, CI/CD telemetry, runtime observability, and existing audit / identity systems. No production write scope. No agent injection.

Scale parameters

Calibrated for systems between 500k and 50M lines of code with 20 to 2,000 services. Systems outside these bands supported through custom enterprise scoping.

The moment your system drifts is the moment you need to know. Not six months later. Not at the next audit. Now.