What your manager can never see
Forge sizes engineering work against real human capacity. That only works if the people being measured can check what is and isn’t visible — so here it is, without the reassuring vagueness these pages usually have.
The boundary is architectural, not a setting
Your energy data and your organisation’s work data live in separate services with separate databases. The Forge service — the one your organisation logs into — holds tickets, estimates, sprints, and billing. It has no credentials for the service that holds your ledger.
This matters because it isn’t a permission that an admin could change, a plan that could unlock it, or a checkbox someone could tick by accident. When Forge needs an energy-aware number, it asks that other service at request time, in your own session, and only a de-identified result comes back — an estimate point and a band. The inputs never cross.
Line by line
| What | Visible to your org | Why |
|---|---|---|
| Your energy ledger — what drained or restored you, and your daily check-ins | Never | It lives in a different service with a different database. The Forge worker has no connection string for it, so there is no query an admin could run and no bug that could expose it. |
| Your personal capacity gauge and “a full day” calibration | Never | Read back only into your own gauge. Team capacity is computed from availability (who is in, at what fraction), not from anyone’s felt energy. |
| Your review load — how many pull requests you reviewed | Never per-person | Readable only for your own OAuth-verified source-control login. Your lead sees how review load is SPREAD across the team (“the busiest reviewer absorbs 41%”) and never who that is. |
| Why you were away — sick, vacation, parental | Admins only | The capacity maths reads only how much of a day you were unavailable, never the reason. Teammates see an unlabelled “away”. The audit log records the booking without the reason. |
| That you were away, and for how long | Yes | Scheduling data the team already has. It has to be visible, or a sprint’s capacity number becomes unexplainable. |
| Estimates and graded actuals on tickets you worked | Yes | This is the product. Estimates are de-identified points and bands; the team-level calibration read is an aggregate with no per-person ranking. |
| Your tickets, comments, and pull-request activity | Yes | Ordinary work data your team can already see in your tracker and your repo. Forge doesn’t make it more visible than it was. |
Things Forge deliberately will not build
- A per-person review-load comparison. Not gated behind a plan — absent. Per-person review volume becomes pressure the moment it is comparable across a team, so the aggregate read is keyed on the pull request, never the reviewer.
- A productivity ranking. Estimate accuracy is reported as a team aggregate. There is no per-person leaderboard and no individual score.
- Inferred energy. Forge reads what your tickets show about load. It does not guess how you feel, and it does not invent a decline from your silence.
What is recorded about admins
Membership changes, integration connections, published reports, and settings changes are written to an append-only audit log. It has no edit or delete surface — not for an admin, not for the owner. If someone connects a repository or publishes a report about your team’s work, that is on the record.