Organizations

An organization groups projects and members. It is a coordination container — a company, a team, an open-source foundation — and it is the layer where shared projects, shared visibility rules and shared execution history live. What it is not, under any circumstances, is the owner of a developer's identity.

Organizations have a slug, a profile, a set of projects, and members. A member is joined to an organization by a membership edge that carries a role and a period. The edge is the whole model: it can be created, it can end, and when it ends, everything the developer earned while it existed stays with the developer.

Organizations exist so that teams can see their execution in one place — every project's timeline, every open BLOCK, every deployment, aggregated — and so that a company can prove its engineering record to the outside world without any of that requiring it to hold its engineers' reputations hostage.

Consider what happens on the day an engineer resigns. In most systems that model contribution, the account is provisioned by the employer, and it is deprovisioned by the employer. Whatever record of work existed, disappears with the account. The engineer walks out with a resume and a request that people take their word for it.

We treated that as the defining failure to avoid. So in Pulse, identity is rooted in the developer, and organizations attach to it — never the reverse. Membership is an edge with a start and an end. When it ends, the edge closes; it does not delete. The developer's events, proofs and Build Cred were never inside the organization to begin with. This is also why an organization can be deleted entirely and its former members lose nothing: survivability is a property of the model, not a policy we promise to honor.

• Membership edge — a typed link between a developer and an organization, with a role and a period. Historical memberships remain visible as history.
• Projects — an organization owns projects, and owning them means holding the container, not the credit inside it.
• Organization cred — derived separately from member reputation. It is an aggregate of the organization's verified execution, not a sum of its engineers' scores.
• Visibility policy — an organization can require that private work be recorded under the Privacy Mask, so it is provable without being disclosed.
• Survivability — deleting an organization removes the container. Member records, events and Build Cred are untouched.

It would be easy, and wrong, to score an organization by adding up its engineers. That would mean hiring a high-cred engineer instantly raises the company's standing, and that an engineer leaving lowers it — neither of which says anything about how the organization executes. Organization cred is derived from the organization's own verified execution: what shipped, what broke, how fast it was resolved, and how much of it is proved.

1. An organization is created, in the Engineering Workspace or during onboarding.
2. Developers join, each through a membership edge carrying a role.
3. Projects are created under the organization, or transferred to it.
4. Execution inside those projects is captured and verified as normal, attributed to the individual engineers.
5. The organization page projects the aggregate: combined timeline, active BLOCKs, member activity, technologies, and derived organization cred.
6. When a member leaves, the edge closes. Their events remain on the organization's project timelines, still attributed to them.

1. Create the organization once, and give it the projects that belong to it.
2. Invite the engineers who work on them.
3. Set the visibility policy for private work — most companies record internal projects as masked rather than private, so contribution stays provable.
4. Use the organization timeline as the standing account of what engineering shipped and what it resolved.

northwind is the organization behind atlas-gateway. @aria is a member; the project belongs to the organization; the events belong to @aria.

# Bind a project to its organization at init time
pulse init --project atlas-gateway --org northwind

# Or point an existing project at an organization
pulse config set organization northwind

{
  "slug": "northwind",
  "name": "Northwind Labs",
  "projects": ["atlas-gateway", "orbit-sdk", "ledger-core"],
  "members": [
    { "handle": "@aria", "role": "Staff Platform Engineer", "since": "2024-02-11" }
  ],
  "visibilityPolicy": "masked",
  "cred": { "score": 774, "derivedFrom": "verified organization execution" }
}

• Create one organization per real company or team, not one per department. Fragmenting the container fragments the timeline.
• Transfer existing projects into the organization rather than recreating them, so the history comes with them.
• Prefer masked over private for internal work. Both hide the detail; only masked keeps the contribution provable to the outside world.
• Close membership edges when people leave, rather than deleting accounts. The edge is the honest record — someone worked here, from this date to that one.

• Assuming the organization owns its members' reputation. It does not, and no setting exists to make it so.
• Marking all internal work private, then being unable to prove to a customer or a candidate that the team ships. Masked exists exactly for this.
• Reading organization cred as an average of member scores. It is not — it is derived from the organization's own execution.
• Deleting an organization to clean up, expecting the projects to follow. Transfer the projects first; a deleted container leaves them owner-less.

• Membership is not required. Individual developers with no organization are first-class and can earn full Build Cred.
• A developer can belong to several organizations at once. Each is its own edge.
• Enterprise mask policy is an organization-level floor: members cannot disclose below it, but they can always choose to disclose less.
• Historical memberships are part of a developer's public record. That is intentional — where someone worked, and when, is part of the story their timeline tells.