Verification

Verification is what makes Pulse a record rather than a profile. An event on its own is a claim. An event with a proof — minted from a source Pulse can check, sealed against tampering, and graded at a known trust level — is evidence.

When an event enters the log, the verification engine looks for a source that can confirm it: a linked repository, a CI pipeline, a deployment. If it finds one, it mints a proof — an evidence hash over the event's material facts, plus the method, the source, the engine version, and a timestamp. The proof is attached to the event and graded from L0 to L4.

Nothing in Pulse asks you to be verified. You do not request it, submit for it, or appeal it. It is a property the engine assigns to a record, and the only way to raise it is to give Pulse a stronger source.

Verification exists so that trust does not have to be extended on faith. A hiring manager reading a timeline, an engineer reading a knowledge artifact, or a customer reading an organization's record should be able to tell, at a glance, which claims are backed by a machine-checkable source and which are somebody's word.

The obvious design is binary: verified or not. We built it and threw it away, because it forces a lie in both directions. A self-recorded PIVOT is not fraudulent — it is a real engineering decision that no machine can confirm — and marking it 'unverified' next to a fabricated one treats them identically. Meanwhile a deployment confirmed by a signed CI pipeline is enormously stronger evidence than a webhook event, and a single checkmark flattens that distinction away.

So verification is a ladder. It states not just whether something is proved but how strongly, and by what. This is what lets Build Cred be weighted honestly: a hundred self-attested events cannot outrank a body of pipeline-verified execution, and nobody has to pretend that judgment is unverifiable noise.

• Source registry — the systems Pulse is allowed to verify against. A source must be connected before it can attest anything.
• Proof — the record of an attestation: an evidence hash, a method, a source, an engine version, and a verification time.
• Evidence hash — a digest over the event's material facts. If the event were altered, the hash would no longer match, which is what makes the proof tamper-evident.
• Method — how the proof was obtained: github_webhook, ci_pipeline, deployment, or manual.
• Versioning — every proof records the engine version that minted it, so a change in verification logic never silently rewrites the meaning of old proofs.
• Adjudication — the process that resolves conflicting or contested evidence and assigns the final level.

Verification logic will improve. When it does, every proof minted under the old logic still says exactly what it said when it was minted, because it records the engine that produced it. We do not retroactively re-grade history: a proof is a statement about what was checkable at a point in time, and quietly upgrading old proofs under new rules would make the whole ladder unfalsifiable.

1. An event is appended to the log.
2. The engine identifies the strongest source in the registry that can speak to it.
3. It checks the event's claims against that source.
4. It computes an evidence hash over the material facts of the event.
5. It mints a proof — hash, method, source, engine version, timestamp — and attaches it.
6. It assigns a trust level from L0 to L4, based on the strength of the source that confirmed it.
7. Build Cred is recomputed, weighting the event by its level.

  EVENT                SOURCE REGISTRY            PROOF

  evt_atlas_pool  ──▶  Which source can        ──▶  evidenceHash  sha256:41ab7c…
  _unlock              speak to this?               method        ci_pipeline
                            │                       engineVersion verification-engine@1.0.0
                            │                       verifiedAt    2026-07-04T02:16:08Z
                            ▼                             │
                    no source      ──▶ L0                 ▼
                    the author     ──▶ L1            TRUST LEVEL: L3
                    repository     ──▶ L2
                    pipeline       ──▶ L3   ◀── the strongest source available wins
                    + independent  ──▶ L4

  Verification is applied at capture time, against the sources present then. Proofs record the
  engine that minted them, and are never re-graded under later rules.

1. Link a repository — this alone moves execution events from L0/L1 to L2.
2. Wire pulse deploy into the deployment pipeline — deployments now attest at L3.
3. Record judgment events (BLOCK, UNLOCK, PIVOT) normally. They sit at L1 unless a fix ships that a pipeline can confirm.
4. Inspect any proof from the event page or with pulse status.
5. If something is unverified when you expected it not to be, the source is the thing to check — never the event.

The deployment that resolved the atlas-gateway pooling incident was confirmed by the CI pipeline, so its proof was minted at L3.

{
  "proofId": "proof_2a77b410",
  "event": "evt_atlas_pool_unlock",
  "status": "verified",
  "level": "L3",
  "method": "ci_pipeline",
  "methodLabel": "GitHub Actions · northwind/atlas-gateway",
  "evidenceHash": "sha256:41ab7c…d0192f",
  "verificationVersion": "v1.4.2",
  "engineVersion": "verification-engine@1.0.0",
  "verifiedAt": "2026-07-04T02:16:08Z",
  "masked": false
}

# Inspect what has been verified, and at what level
pulse status --verbose

Project       atlas-gateway (northwind)
Repository    github.com/northwind/atlas-gateway   ✓ linked      (source: github)
Pipeline      GitHub Actions                       ✓ reporting   (source: ci)

Recent events
  UNLOCK  Resolved connection-pool exhaustion   verified · L3   proof_2a77b410
  BLOCK   Connection-pool exhaustion            verified · L2   proof_9f10c3d2
  PUSH    Deployed v2.4.0 to production         verified · L3   proof_5c8ea114
  PIVOT   Moved edge cache to W-TinyLFU         verified · L1   proof_1b47f009

• Connect sources before you need them. Verification is applied at capture time, so an event recorded before the repository was linked stays at the level it was minted at.
• Wire pulse deploy into the pipeline rather than running it from a laptop. A deployment reported by CI attests at L3; the same deployment announced from a developer machine cannot.
• Do not chase levels on judgment events. An L1 PIVOT is not a failure — it is the correct level for that kind of claim.
• Read the method, not just the level, when you are evaluating someone's record. It tells you what was actually checked.

• Assuming verification can be requested. There is no submission and no appeal — you add a source, or the level stands.
• Expecting old events to be re-graded after linking a repository. They are not. Proofs are minted once, against the sources available at the time.
• Reading L1 as 'suspicious'. It means self-attested, which is the honest and expected level for a decision.
• Treating a masked event as unverified. Masking hides the detail from a viewer; the proof is intact and the level is unchanged.

• Proofs are tamper-evident, not encrypted. Anyone can check that an event matches its evidence hash — that is the point.
• Verification is independent of visibility. Private and masked events are verified exactly like public ones.
• L4 requires an independent attesting party in addition to a source, which is why it is uncommon and meaningful.
• If the verification engine cannot reach a source, the event is recorded as pending rather than failed, and is attested when the source responds.