Evidence-Driven Proportional Allocation

Time is not measured — it is derived

EDPA v2.11.1 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

Dashboard demo Calculator Presentation

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

cw[P, item] = Σ signal_weights / Σ_persons Σ signal_weights (per-item share, Σ = 1.0) Score[P, item] = JobSize × cw → DerivedHours = (Score / ΣScores) × Capacity Guarantee: Σ DerivedHours = Capacity per person AND Σ cw = 1.0 per item — always.

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?

DerivedHours = (Score / ΣScores) × Capacity Guarantee: Σ = Capacity

Report for audit

Per-Item

How many people and hours did item X cost?

ItemShare = DerivedHours[P] / Σ DerivedHours[*] Guarantee: Σ shares = 100%

Cost allocation per deliverable

Both views are derived from the same data (CW, JobSize, Capacity). No duplication, no conflict.

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.

PI planning / overview (v2.4)

/edpa:pi-planning renders the whole SAFe program picture — program board with dependency arrows, PI objectives, ROAM, portfolio, WSJF, capacity — as a single self-contained, read-only HTML. No server, no Node, no network; it regenerates deterministically from .edpa/. Dependencies are first-class via edpa_item_link_dep (cycle-checked).

Explore EDPA

Dashboard, case study, presentation, methodology and evaluation — all in one place.

Dashboard demo kashealth.cz case study Presentation Methodology Evaluation & tests