Evidence-Driven Proportional Allocation
Time is not measured — it is derived
EDPA v2.22.0 replaces manual timesheets with automatic hour derivation
from local git evidence — commits, yaml edits, status
transitions. The .edpa/backlog/ YAML in git is the single
source of truth; git is the audit trail. No GitHub required.
Mathematical guarantee, zero administration.
Timesheets
Zero
No manual logging
Guarantee
Sum = Capacity
Mathematically guaranteed
Analytics
Dual-view
Per-person & per-item
Calibration
Monte Carlo
68,000+ records, p<0.001
What's new
What's new in EDPA this wave
PI planning / overview
/edpa:pi-planning renders the whole SAFe program board
(teams × iterations, dependency arrows), PI objectives, ROAM,
portfolio, WSJF and capacity into one self-contained
HTML — no server, no Node, no network. A read-only
projection of .edpa/, deterministically regenerable.
Dependencies via edpa_item_link_dep (cycle-checked).
Gates mode (default)
The engine credits every Initiative/Epic/Feature status transition as a mini-deliverable. Architects and PMs get credit for LBC, design and refinement work across gates — not just for the final Done. Validated on a 4 PI × 2 iteration simulation.
In-flight Story credit
Stories in the iteration that have not reached Done yet get credit
based on yaml_edit activity in the window (refinement, AC, DoD).
story_activity_events[] in edpa_results.json
shows which Stories were credited and with what credit_factor.
Production ready
975 unit tests, 6 E2E against real GitHub, 100 Monte Carlo runs
(avg MAD 7.8 % vs ground truth, spread 0.35 pp under ±20 %
perturbation). Full operational runbook in
docs/RUNBOOK.md.
Context
Why do we need EDPA?
Inaccuracy
Manual timesheets are subjective. People estimate, round, forget. Data does not reflect reality.
Audit nightmare
During audits it is impossible to prove retroactively who worked on what. Evidence is missing, provability is lacking.
Administrative burden
Filling out reports takes time that could go into development. Nobody likes timesheets.
No per-item view
Traditional systems show only personal reports. How much did a specific deliverable cost? Impossible to determine.
Solution
How EDPA works
The system consists of three separate layers that collaborate to automatically derive working hours.
Operational Metadata
.edpa/backlog/ YAML · Git
Hierarchy, status, Job Size, WSJF as YAML frontmatter in the repo — the single source of truth. Git is the audit trail; no GitHub required.
Capacity Registry
YAML config in repo
Capacity, roles, FTE. Confirmed at Iteration Planning. The only manual input to the system.
Evidence & Reporting
/snapshots · /reports · /signed
Frozen snapshots, reports, BankID signatures. Immutable and auditable.
Evidence detection
Signals from git (and optionally GitHub)
EDPA reads evidence primarily from local git: a post-commit hook
(and the idempotent /edpa:materialize) writes commit_author,
yaml_edit and state_transition straight into evidence[]
in the YAML. The engine is a pure reader — it consumes the materialized
evidence and no longer scans git at compute time. An optional CI workflow can additionally
emit pr_reviewer and issue_comment from GitHub. Each signal adds weight to contribution_score per (person, item);
the resulting CW is a per-item normalized share: cw = score / Σ_persons score (Σ per item = 1.0).
| Signal | Weight | Source | Description |
|---|---|---|---|
commit_author | 4.00 | local hook | Commit with S-XXX/F-XXX/E-XXX/I-XXX — post-commit emit |
manual:commit_message | explicit | local hook | /contribute @person weight:X in commit body |
yaml_edit:* | 0.5–5.0 | local hook / materialize | block_add, list_grow, scalar_change, create — structural backlog edits (revert −0.5) |
gate_event | js × weight | local hook / materialize | F/E/I status transition (LBC → design → refinement → Done) |
story_activity | js × 0.40 | engine | In-flight Story with yaml_edit signals in the window |
state_transition | 0 | local hook / materialize | Status transition (person/at/from→to) — analytics + delivery lead-time, does not feed CW |
pr_reviewer | 2.17 | optional CI | Approved PR review (optional GitHub Actions workflow) |
issue_comment | 1.46 | optional CI | Comment on issue/PR (optional workflow, bots excluded) |
Signals aggregate additively; there is no "highest wins". Default weights above are calibrated by Monte Carlo simulation (1000 synthetic scenarios). The local git hook + engine cover the normal delivery flow; the CI workflow is a purely opt-in add-on, not a dependency.
Dual-View analytics
Two views, one dataset
Per-Person
How is a person's capacity distributed across items?
Report for audit
Per-Item
How many people and hours did item X cost?
Cost allocation per deliverable
Key features
Why EDPA works
Zero manual input
No timesheets. The report is a byproduct of delivery. The team works, the system calculates.
Mathematical guarantee
Σ DerivedHours = Capacity. Always. Proportional allocation ensures consistency.
Dual-view analytics
Per-person reports for reporting. Per-item cost cards for management. One dataset.
Audit-grade (BankID)
Frozen snapshots + BankID signatures. Legally stronger than paper reports.
Self-tuning
Karpathy loop: compare → adjust → repeat. The system automatically calibrates to real data. Calibrated by Monte Carlo simulation (68,000+ records).
Git-native, GitHub-friendly
Evidence from local git (no cloud lock-in). GitHub is
optional: the only integration is PR-signal contribution-sync
(--with-ci), which materializes PR reviews and comments
into evidence[]. For a board, use the local
/edpa:board HTML — no Projects sync.
Explore EDPA
Dashboard, case study, presentation, methodology and evaluation — all in one place.