Build Cred

Build Cred is a single number derived from your verified engineering execution, broken down across five dimensions, and explainable down to the individual event that moved it. You cannot set it, edit it, or claim it. It is computed, and it is portable.

Every verified event contributes weighted points to one or more dimensions. The weight scales with the event's verification level, so proof — not volume — is what moves the number. The dimensions roll up into one score, and every point of that score can be traced back to the event that produced it.

Build Cred exists so that an engineer's record can be checked instead of believed. It replaces the least reliable artifact in the industry — the self-authored claim of impact — with a derived one, and it makes that derivation legible enough that a skeptical reader can audit it.

Any reputation system with a write path is a reputation system that will be gamed, and the moment it is gamed it stops being information. So Build Cred has no write path. There is no field, no form, no API and no support request that sets a score. The only way to raise it is to do verified engineering.

The second decision follows from the first: trust-weighting. If every event counted the same, the way to a high score would be to record many small unverified events, and the system would reward noise. Weighting by verification level means an L3 deployment confirmed by a pipeline is worth substantially more than an L1 self-attestation, and that a large volume of unverifiable claims converges on nothing. Proof is the currency, not activity.

The third is explainability. A score you cannot interrogate is a score you cannot trust — and an opaque number would make Pulse exactly the kind of black box we built it to replace. So every point traces to an event, every event carries its proof, and the breakdown is visible on the profile that shows the number.

• Derived — computed from the event log. It is a projection, not a stored value someone can edit.
• Trust-weighted — an event's contribution scales with its verification level. L0 contributes nothing at all.
• Explainable — every event shows the points it produced and which dimensions they landed in.
• Portable — it belongs to the identity, not the organization, and it survives job changes.
• Time-aware — sustained execution counts for more than a single strong quarter, and a timeline makes the difference visible.

The score is not a counter that events add to. It is recomputed from the log, which means a proof that is later invalidated — a source that retracts, a deployment that never happened — removes its contribution cleanly, and the reason is visible. A number that could only ever go up would be trivially exploitable.

1. An event is captured and verified. It receives a trust level from L0 to L4.
2. The event contributes points to the dimensions it is evidence for — an UNLOCK feeds Resolution, a deployment feeds Delivery and Reliability.
3. Each contribution is weighted by the event's verification level.
4. The dimensions are recomputed and rolled into a single score.
5. The score, its dimension breakdown, and the events behind it are projected onto your profile and the leaderboard.

There is no workflow for earning Build Cred, and that is the design. You do engineering; it follows. The only thing you actively control is whether your execution is verifiable.

1. Link repositories and pipelines, so what you ship can be confirmed.
2. Ship. Delivery and Reliability accumulate on their own.
3. Resolve real incidents in the open. This is the fastest-moving dimension, and the hardest to fake.
4. Record the decisions you make and reverse. Architecture is built from judgment, not throughput.
5. Check the breakdown on your profile when you want to know why the number moved.

@aria's Build Cred, and the incident that moved it.

{
  "handle": "@aria",
  "score": 912,
  "globalRank": 47,
  "topPercentile": "Top 3%",
  "weeklyGain": 56,
  "dimensions": [
    { "id": "delivery",      "label": "Delivery",      "value": 94 },
    { "id": "reliability",   "label": "Reliability",   "value": 88 },
    { "id": "resolution",    "label": "Resolution",    "value": 96 },
    { "id": "architecture",  "label": "Architecture",  "value": 82 },
    { "id": "collaboration", "label": "Collaboration", "value": 79 }
  ],
  "derivedNote": "Build Cred is derived from verified execution — every point traces to a tamper-evident event, weighted by verification trust level."
}

{
  "event": "evt_atlas_pool_unlock",
  "buildCredEarned": 34,
  "rationale": "Production incident resolved with a pipeline-verified fix (L3). Resolution weighted heavily; Reliability credited for the fix holding across subsequent deploys.",
  "dimensions": [
    { "id": "resolution",    "label": "Resolution",    "delta": 21 },
    { "id": "reliability",   "label": "Reliability",   "delta": 9 },
    { "id": "collaboration", "label": "Collaboration", "delta": 4 }
  ]
}

• Optimize for verifiability, not for the score. They are the same thing, and only one of them is a healthy way to work.
• Link every project you actually work in. Unlinked projects produce L0 and L1 events, and L0 contributes nothing.
• Resolve incidents on the record rather than in a DM. Resolution and Collaboration are the two dimensions that reward working in the open.
• Read the dimension breakdown, not just the number. A high Delivery with a low Reliability is a signal, and it is a useful one.

• Recording many small events to move the number. Volume is not weighted; proof is. Ten L1 events can be worth less than one L3.
• Recording an UNLOCK with no BLOCK, hoping to feed Resolution. Resolution is derived from resolving something, and an unlinked UNLOCK resolves nothing.
• Expecting the score to jump immediately. It is recomputed from verified events, and verification waits for the source to confirm.
• Believing an employer can adjust it. No role, permission or plan in Pulse grants the ability to change another person's Build Cred.
• Comparing scores across career lengths as if they were the same measurement. The dimensions are the comparable part; the total is a summary.

• Masked events count in full. The Privacy Mask hides detail from a viewer, not evidence from the engine — the engine always reads the raw record.
• Organization cred is derived separately and is not a sum of member scores. See Organizations.
• The leaderboard ranks derived scores; it is a view of the same projection, not a separate system.
• A retracted proof removes its contribution, and the retraction is visible. The score can move down, and it should be able to.