Pelagram

The Rules

The standard, published.

A classification society doesn't earn its authority by describing its rigour — it publishes its rules, and anyone can judge whether they're worth anything. This is ours: what we ask of a delivery, how we check it, and what we will not accept as proof.

Publishing has a cost. A delivery team can read this and prepare for it. We think that's a feature — a build that was tightened up because someone read these is a build that holds, which is the outcome the owner is paying for.

Edition 2026.1 · effective 2026-07-27 · 34 rules

How to read a rule.

A rule is met, met with findings, or not met. There's no “in progress” — an obligation that hasn't been demonstrated is not met, and it's recorded that way, on the date it was assessed.

Obligation
What the delivery has to achieve. Written so it can be tested, not admired.
Verification
What Pelagram does, independently, to check it.
Evidence we accept
The artifact that closes the rule.
Evidence we don't accept
The near-miss that usually gets offered instead.

The same rule shouldn't carry the same force everywhere.

We set the level at Chart, from the consequence of failure — not from the size of the budget or the team. Scoping a level down is a decision the owner makes on the record, and it goes in the report, so the choice is still visible later when it matters.

Level 1

A failure would inconvenience internal users; work is recoverable by hand.

Rules met by declaration and spot check

Level 2

A failure would reach customers, breach a contract, or lose data that matters.

Rules verified against artifacts, sampled at each gate

Level 3

A failure would trigger regulatory exposure, material financial loss, or public harm.

Rules verified by independent test, re-verified in production

Six gates. Evidence is due at each.

G0 is not a formality. An assurance engagement that can't compel access to repositories, environments, telemetry, and test results is a reading of documents. If G0 can't be passed, we say so in writing before the engagement starts, and the owner decides whether to fix it or proceed knowing the limit.

  1. G0

    Mandate & access

    Can Pelagram actually see what it needs to see, and does the contract say so?

  2. G1

    Requirements & contract baseline

    Is there a written standard of care with acceptance criteria that can be enforced?

  3. G2

    Design sign-off

    Does the proposed design plausibly meet the obligations, before money is spent building it?

  4. G3

    Build assurance

    Is the thing being built the thing that was designed, to the standard agreed?

  5. G4

    Acceptance & go-live

    Has it been independently demonstrated, not just demonstrated?

  6. G5

    Operational assurance

    Does it still hold, now that it's real and drifting?

SEC

Security, compliance & data sovereignty

SEC-01

The data is inventoried and classified.

Levels 1–3 · G1 · G2 · G5

Obligation. Every category of data the system holds is written down, with its sensitivity, its lawful basis, and its owner.

Verification. We reconcile the declared inventory against the actual schema, object storage, log sinks, and third-party destinations.

Evidence we accept
A data inventory that matches what we find in the system.
Evidence we don't accept
An inventory that omits logs, backups, analytics pipelines, or support tooling — which is where sensitive data usually ends up unannounced.

SEC-02

Access is least-privilege and reviewed.

Levels 1–3 · G3 · G4 · G5

Obligation. Every human and machine identity has the narrowest access that lets it work, and that access is reviewed on a stated cycle.

Verification. We pull the actual role and permission assignments from production and check them against the roster, including leavers and contractors.

Evidence we accept
An export of live entitlements, with a dated review record and evidence that revocations happened.
Evidence we don't accept
An access policy document, or a statement that access “follows least privilege.”

SEC-03

Secrets are managed, not committed.

Levels 1–3 · G3 · G4

Obligation. Credentials, keys, and tokens live in a managed secret store, are rotated, and have never been committed to source control.

Verification. We scan the full repository history, not the current tree, and inspect the secret store's rotation record.

Evidence we accept
A clean history scan plus rotation timestamps.
Evidence we don't accept
“We removed it in a later commit.” A secret in git history is a secret that leaked and must be rotated.

SEC-04

Authentication and session handling are sound.

Levels 2–3 · G2 · G4

Obligation. Authentication resists the common attacks, sessions expire, privilege changes take effect immediately, and administrative access requires a second factor.

Verification. We test the flows ourselves — login, reset, session fixation, privilege change, admin path.

Evidence we accept
Our own test results against a production-equivalent environment.
Evidence we don't accept
A description of the auth library in use.

SEC-05

Data is protected in transit and at rest.

Levels 1–3 · G2 · G4 · G5

Obligation. Transport is encrypted with current protocols, data at rest is encrypted, and key custody is defined.

Verification. We probe live endpoints and confirm storage-layer encryption and key ownership directly.

Evidence we accept
Endpoint scan output and storage configuration read from the platform.
Evidence we don't accept
An architecture diagram with a padlock on it.

SEC-06

Data lives where law and contract require.

Levels 2–3 · G1 · G2 · G5

Obligation. The residency of every data category is known and enforced, including backups, replicas, logs, and any processing by third parties or model providers.

Verification. We trace each category to its physical region and check the sub-processor chain.

Evidence we accept
Region configuration read from the platform, plus sub-processor agreements carrying the same constraint.
Evidence we don't accept
The primary database's region as a proxy for the whole system. Backups and telemetry are where sovereignty quietly breaks.

SEC-07

Third-party and dependency risk is managed.

Levels 2–3 · G3 · G4 · G5

Obligation. Dependencies are inventoried, known vulnerabilities are tracked with a remediation clock, and third-party services holding data are under contract.

Verification. We generate our own dependency inventory from the build and compare it to what was declared.

Evidence we accept
A current bill of materials with dated remediation decisions for what is outstanding.
Evidence we don't accept
A scanner that is configured to pass.

SEC-08

The system has been tested by someone trying to break it.

Levels 3 · G4 · annually at G5

Obligation. An independent penetration test has been performed against the production configuration, and the findings have been closed or formally accepted.

Verification. We read the full report, check the scope wasn't narrowed to the safe parts, and re-test a sample of the closed findings.

Evidence we accept
The report with its scope statement, plus our own re-test of the fixes.
Evidence we don't accept
An automated vulnerability scan described as a penetration test, or a report whose scope excludes authenticated functionality.

SEC-09

Security-relevant events are logged and tamper-evident.

Levels 2–3 · G3 · G5

Obligation. Authentication, authorisation changes, privileged actions, and data exports are logged with actor, time, and target — and the people who could cause a problem cannot edit the record of it.

Verification. We perform a privileged action in a test environment and find it in the log ourselves.

Evidence we accept
The log line we generated, plus the retention and write-access configuration.
Evidence we don't accept
Application logs that can be deleted by an application administrator.

SEC-10

Retention and deletion actually happen.

Levels 2–3 · G1 · G5

Obligation. Each data category has a retention period, deletion is implemented, and a deletion request removes the data from backups and downstream systems within the stated window.

Verification. We run a deletion through the real path and look for the residue.

Evidence we accept
A demonstrated deletion with before-and-after evidence across primary, replica, backup, and analytics stores.
Evidence we don't accept
A retention policy with no implementation behind it.

REL

Reliability, resilience & recovery

REL-01

There is an availability target, and it is measured.

Levels 2–3 · G1 · G5

Obligation. The availability the business requires is written down as a number, with a definition of what counts as down, measured from where the customer sits.

Verification. We check the measurement is external to the system being measured, and reconcile reported uptime against incident records.

Evidence we accept
A stated objective plus measurement from an independent vantage point.
Evidence we don't accept
“Highly available,” or uptime measured by the server reporting on itself.

REL-02

Everything that matters is backed up.

Levels 1–3 · G3 · G4 · G5

Obligation. Backup coverage is complete across databases, object storage, and configuration, at a frequency consistent with the agreed recovery point.

Verification. We compare the backup inventory against the data inventory from SEC-01 and look for what is missing.

Evidence we accept
The backup configuration read from the platform, mapped to every data store we found.
Evidence we don't accept
Coverage of the main database while file storage, secrets, and infrastructure configuration are unprotected.

REL-03

A restore has actually been performed. Recently.

Levels 1–3 · G4 · G5

Obligation. A restore from backup has been completed into a clean environment, and the restored data has been verified as correct and complete.

Verification. We witness or independently repeat the restore, and run our own queries against the result.

Evidence we accept
A restore performed within the last 90 days, with the date, the operator, the volume restored, the elapsed time, and the verification queries run against the restored data.
Evidence we don't accept
A backup job success log, a screenshot of a backup console, or a statement that restores are tested. This is the rule most deliveries fail. A recovery path that has never been exercised is a claim, not a control.

REL-04

Recovery targets have been proven, not assumed.

Levels 2–3 · G4 · G5

Obligation. The agreed recovery time and recovery point objectives have been demonstrated in an exercise involving the loss of a primary component.

Verification. We observe the exercise, or specify one and review the results against the stated targets.

Evidence we accept
A dated exercise report with the measured recovery time next to the target, including what went wrong during it.
Evidence we don't accept
A disaster-recovery plan that has never been run. A plan that reports no problems during its first exercise usually means the exercise was too gentle.

REL-05

Single points of failure are known and accepted deliberately.

Levels 2–3 · G2 · G5

Obligation. The components whose failure takes the system down are identified, and each one is either removed or accepted in writing by the owner.

Verification. We trace the request path and the data path and find the chokepoints ourselves.

Evidence we accept
A dependency map that matches the running system, with owner-signed acceptances for what remains.
Evidence we don't accept
A resilience claim resting on a managed service whose failure modes the team hasn't read.

REL-06

The system degrades sensibly when a dependency fails.

Levels 2–3 · G3 · G4

Obligation. When a downstream service is slow or unavailable, the system fails in a bounded, defined way rather than cascading.

Verification. We ask for the failure to be induced, and watch what the user sees.

Evidence we accept
An observed failure injection with the resulting user-facing behaviour and recovery.
Evidence we don't accept
Timeouts configured in code, offered as proof of behaviour.

REL-07

There is headroom for the load that is actually coming.

Levels 2–3 · G2 · G4 · G5

Obligation. Capacity is sized against the forecast peak, with the scaling limits and their cost known before the peak arrives.

Verification. We check the forecast against the business plan and the tested ceiling against the forecast.

Evidence we accept
A capacity model with the tested ceiling, the trigger points, and the cost of scaling.
Evidence we don't accept
“It autoscales.” Everything autoscales until it reaches a quota, a connection limit, or a bill.

REL-08

Data integrity is checked, not trusted.

Levels 2–3 · G3 · G5

Obligation. Where the system moves money, stock, entitlements, or anything else that must reconcile, an independent check confirms that it does — on a schedule, with a defined response when it doesn't.

Verification. We review the reconciliation logic and, where the numbers matter enough, compute the control total ourselves.

Evidence we accept
A scheduled reconciliation with its exception history and evidence that exceptions were worked.
Evidence we don't accept
A reconciliation performed by the same component that created the records, or one whose exceptions are never non-zero.

OBS

Observability & performance

OBS-01

The system can be seen into.

Levels 1–3 · G3 · G4 · G5

Obligation. Logs, metrics, and traces exist for every service on the critical path, are centralised, and are queryable by the people who will operate the system.

Verification. We ask an operational question with a real answer and try to answer it from the telemetry alone.

Evidence we accept
The answer, found in the tooling, in front of us.
Evidence we don't accept
A list of the monitoring products purchased.

OBS-02

Errors are captured and triaged.

Levels 1–3 · G3 · G5

Obligation. Application errors reach a tracker with enough context to diagnose them, and there is a working process for deciding which ones get fixed.

Verification. We look at the tracker's real state — volume, age, assignment, and how many are simply ignored.

Evidence we accept
The live tracker, with its backlog visible.
Evidence we don't accept
A tracker that has been tidied for the review, or one where every error is unassigned.

OBS-03

Alerts fire on what users feel.

Levels 2–3 · G4 · G5

Obligation. Alerting is based on user-visible symptoms, routes to someone who is actually on call, and doesn't fire so often that it's ignored.

Verification. We review alert history and the response record, and check the noise rate.

Evidence we accept
The alert catalogue with acknowledgement times and the last real incident's timeline.
Evidence we don't accept
Alerting on CPU while nothing watches checkout failures.

OBS-04

A single transaction can be followed end to end.

Levels 2–3 · G3 · G4

Obligation. One user action can be traced across every service and queue it touches, using an identifier that survives the boundaries.

Verification. We pick a transaction and follow it ourselves.

Evidence we accept
The trace, reconstructed in front of us.
Evidence we don't accept
Correlation IDs that are generated but not propagated, which is the usual state.

OBS-05

Performance targets exist and describe the real workload.

Levels 2–3 · G1 · G2

Obligation. Response-time and throughput targets are stated for the journeys that matter, at percentiles rather than averages, at a defined data volume.

Verification. We check the targets against what the business actually needs and the volumes it actually expects.

Evidence we accept
Targets expressed as percentile, journey, and data volume.
Evidence we don't accept
An average response-time target, which hides exactly the users who are having a bad time.

OBS-06

Performance has been verified under realistic conditions.

Levels 2–3 · G4 · G5

Obligation. The targets have been demonstrated under a load profile and data volume representative of production, including the concurrency the business expects at peak.

Verification. We review the test's shape and, at Level 3, specify or witness the run.

Evidence we accept
Results with the load profile, the data volume, and the environment stated alongside them.
Evidence we don't accept
A load test against an empty database, or against an environment smaller than production.

OBS-07

The owner can reach the operational record.

Levels 2–3 · G0 · G1 · G5

Obligation. Logs and telemetry are retained for a defined period, and the owner — not only the builder — can access them.

Verification. We exercise the owner's access ourselves.

Evidence we accept
Working access under the owner's own credentials, with the retention period configured.
Evidence we don't accept
Access mediated by the delivery team on request. An owner who has to ask the builder for the evidence doesn't have the evidence.

OBS-08

Someone other than the author can operate it.

Levels 2–3 · G4 · G5

Obligation. Runbooks exist for the failures that are actually expected, and they work when followed by someone who didn't write them.

Verification. We walk a runbook with an operator who wasn't its author.

Evidence we accept
A runbook that survives that walkthrough.
Evidence we don't accept
Documentation that assumes knowledge only the original engineers have.

ENG

Delivery & engineering quality

ENG-01

The architecture is written down and has been challenged.

Levels 1–3 · G2 · G5

Obligation. There is a current description of the system's structure, its significant decisions, and why the alternatives were rejected — and it has had an independent review.

Verification. We review it against the running system and against the obligations it's supposed to satisfy.

Evidence we accept
Documentation that matches what is deployed, with decision records that show the trade-offs.
Evidence we don't accept
A diagram produced for the review, describing a system that no longer exists.

ENG-02

The owner owns the source, and can get to it.

Levels 1–3 · G0 · confirmed at G4

Obligation. Intellectual property ownership is unambiguous, and the owner holds — or can obtain within a stated window — the full source, infrastructure definitions, and pipeline configuration.

Verification. We exercise the owner's access, or verify the escrow arrangement actually contains a working build.

Evidence we accept
The owner's own working access to a complete repository, verified by us.
Evidence we don't accept
A contractual clause with no tested mechanism behind it. This is the rule that decides whether an owner can change builders.

ENG-03

Code is reviewed by someone other than its author.

Levels 2–3 · G3

Obligation. Changes reaching production have been reviewed, and the review is a real check rather than a procedural approval.

Verification. We sample merged changes and read the reviews.

Evidence we accept
A sample showing substantive review, including changes that were sent back.
Evidence we don't accept
Approvals issued in under a minute on large changes, or self-merges by the same author.

ENG-04

Tests cover the things that would hurt.

Levels 2–3 · G3 · G4

Obligation. Automated tests cover the critical business logic, the money paths, and the failure paths — and they run on every change.

Verification. We look at what is covered rather than how much, run the suite ourselves, and check whether failures block a release.

Evidence we accept
A suite that runs clean in front of us, with coverage of the paths that carry the risk.
Evidence we don't accept
A coverage percentage. High coverage of trivial code alongside untested payment logic is a worse signal than no tests at all.

ENG-05

Releases are repeatable and reversible.

Levels 2–3 · G3 · G4

Obligation. Deployment is automated and repeatable, and there is a rollback that has been used.

Verification. We review the deployment history and ask when rollback was last exercised.

Evidence we accept
The pipeline definition plus a real instance of a rollback being performed.
Evidence we don't accept
A rollback procedure that exists only as a document, or a release process with manual steps that aren't written down.

ENG-06

What was tested resembles what runs.

Levels 2–3 · G3 · G4

Obligation. The environment where acceptance happens matches production in configuration, integration, and data shape, and the differences are documented.

Verification. We compare the two configurations directly.

Evidence we accept
A stated, justified difference list that we have checked.
Evidence we don't accept
Acceptance testing against mocked integrations, then go-live against the real ones.

ENG-07

Requirements can be traced to what shipped.

Levels 2–3 · G1 · G3 · G4

Obligation. Each agreed requirement and acceptance criterion can be traced to the change that implemented it and the test that demonstrates it.

Verification. We sample requirements from the baseline and follow them through to production.

Evidence we accept
A traceability record that survives our sample.
Evidence we don't accept
A requirements document that stopped being maintained after the contract was signed.

ENG-08

The delivery can be handed over.

Levels 1–3 · G4

Obligation. At go-live the owner has everything needed to run, change, and if necessary replace the delivery team: source, credentials, infrastructure definitions, dependencies and their contracts, runbooks, and the known-defect list.

Verification. We work the handover checklist item by item and confirm each one is real.

Evidence we accept
A completed handover against a checklist we have verified, including the honest defect list.
Evidence we don't accept
A handover in which the known-defect list is empty. Every delivery has one; a blank list means it wasn't written down, not that it doesn't exist.

Amending these Rules

The Rules change as the work teaches us things. Each edition is dated and kept available, so an engagement can name the edition it was assessed against and that assessment stays meaningful later.

We add rules when a delivery fails in a way these didn't anticipate. We remove one when it stops earning its place — a rule every delivery passes on the first attempt is measuring something that's no longer at risk, and keeping it in makes the whole document look like theatre.

What we don't do is quietly relax a rule for a particular engagement. The level can be scoped down, on the record, by the owner. The evidence standard doesn't move.

What we won't do on any engagement is assure work we have a stake in — that boundary is set out in our independence policy.

Read the standard. Then ask what your build would score.

A Pelagram Sounding assesses your delivery against these rules and reports what's met, what isn't, and what the evidence actually shows.

Book an intro call