target-revenue/history/260730-EffortCalculator-CandidateApplication.md

Development Effort Calculator Applied to Real Pilot Candidates

Document status: Dated execution record, non-normative, append-only (workplans/TREV-WP-0010-development-effort-calculator.md T03). Not a Phase declaration. Updates draft, non-binding examples/pilot-candidates/*/manifest.json figures from hand-picked illustrative placeholders to calculator-derived ones — nothing here authorizes a real Phase (workplans/TREV-WP-0008-governance-and-pilot-rollout.md T05 still gates that).

---

1. Method

Ran target_revenue.effort_calculator.calculate_target_basis (WP-0010-T02) against each candidate's real local repository, daily_rate=1000 (EUR, consistent with the earlier hand-picked drafts and the Licensor's own jurisdiction), tokens_in=tokens_out=0 (no get_token_summary data was available for these repos at the time of this run — approved_direct_costs is therefore 0 for all three, not a claim that no AI cost was actually incurred, just that none is currently on record).

Scoping decision, made explicit per candidate: two of the four candidates repos are the whole repo's history (the repo's entire purpose is the candidate); two are one bounded workplan inside a much larger, longer-lived repo, and were date-scoped accordingly (since/ until) — running whole-repo history against a single narrow workplan would badly overstate that workplan's own effort.

Candidate	Repo	Scope used	Why
net-kingdom-local-identity	net-kingdom	2026-03-01 .. 2026-03-06	NK-WP-0002 is one bounded workplan; net-kingdom has since grown into a much larger, multi-year security platform with dozens of unrelated workplans
railiance-vergabe-teilnahme	vergabe-teilnahme (primary) + railiance-apps (secondary, scoped)	whole repo (primary); 2026-05-18 .. 2026-07-12 (secondary)	See §3 — the actual application code lives in vergabe-teilnahme, a separate repo from railiance-apps, which only holds the Helm/deployment wiring
info-tech-canon-service-surface	info-tech-canon	whole repo	The candidate is the repo's cumulative service surface (ITC-WP-0001–0012); no narrower scope applies

2. net-kingdom-local-identity

{
  "estimated_effort_days": 1.0,
  "daily_rate": 1000,
  "approved_direct_costs": 0.0,
  "warnings": [
    "Raw commit-clustered estimate was 0.804 day(s), below the 1.0-day floor. Floored to 1.0 day(s)... very likely a measurement gap... manual override... recommended.",
    "1 finished workplan(s) and 21 finished task(s) on record suggest more real effort than the 0.80-day raw time estimate reflects — treat the time estimate as under-counted and consider a manual override."
  ],
  "derivation": {
    "raw_commit_clustered_hours": 6.435, "sessions": 4, "commits": 19,
    "finished_workplans": 1, "finished_tasks": 21,
    "file_count": 274, "line_count": 44359
  }
}

Both warnings fired. The raw 0.8-day estimate hit the 1-day floor (§1's date-scoping correctly isolated NK-WP-0002's own 19 commits across 4 sessions), and the sanity-check independently flagged that 21 finished tasks across one workplan implies more real effort than 0.8 raw days suggests. This is exactly the situation the maintainer's requested floor-and-warning design exists for: the manifest below uses the 1.0-day floored value, not a manually-adjusted "better" number — a human reviewing this candidate before any real Phase declaration should treat estimated_effort_days: 1.0 as a flagged, likely-too-low placeholder, not a settled figure.

Manifest updated: estimated_effort_days: 1.0, approved_direct_costs: 0, target_multiple: 10 (unchanged, Incremental) → Initial Target: 10,000 EUR (previously a hand-picked 200,000 EUR — the calculator's own honest, warning-flagged output is materially lower, not a refinement of the old guess).

3. railiance-vergabe-teilnahme

Two repos exist for this candidate, discovered during the earlier architecture work: railiance-apps holds the Helm/deployment wiring; vergabe-teilnahme holds the actual Django application source code. RAILIANCE-WP-0002/-0014 (the workplans naming this Milestone Release) live in railiance-apps, but the real development effort producing the application itself happened in vergabe-teilnahme.

Primary figure used — vergabe-teilnahme, whole-repo history (no scoping; the repo's entire purpose is this one application):

{
  "estimated_effort_days": 6.488,
  "daily_rate": 1000,
  "approved_direct_costs": 0.0,
  "warnings": [],
  "derivation": {
    "raw_commit_clustered_hours": 51.904, "sessions": 42, "commits": 223,
    "finished_workplans": 1, "finished_tasks": 123,
    "file_count": 322, "line_count": 26773
  }
}

Secondary figure, not used in the manifest — railiance-apps, date-scoped to 2026-05-18..2026-07-12:

{
  "estimated_effort_days": 4.146,
  "derivation": {
    "raw_commit_clustered_hours": 33.168, "sessions": 36, "commits": 127,
    "finished_workplans": 12, "finished_tasks": 71,
    "file_count": 140, "line_count": 11118
  }
}

Judgment call, made explicit rather than silently picked: this document uses vergabe-teilnahme's figure as the candidate's target_basis, since that repo is where the substantive product development happened; railiance-apps's deployment effort (4.146 days) is real work but comparatively thin infrastructure glue, not the Milestone Release's own value creation. A different, equally defensible call would sum or otherwise combine both — flagged here so a human reviewing this later can see both numbers and the reasoning, not just the one that was picked.

Manifest updated: estimated_effort_days: 6.488, approved_direct_costs: 0 (the hand-picked draft's 5000 placeholder removed — no real token-cost or other direct-cost data exists yet), target_multiple: 100 (unchanged, Product-defining) → Initial Target: 648,800 EUR (previously a hand-picked 3,500,000 EUR).

4. info-tech-canon-service-surface

{
  "estimated_effort_days": 1.418,
  "daily_rate": 1000,
  "approved_direct_costs": 0.0,
  "warnings": [
    "12 finished workplan(s) and 51 finished task(s) on record suggest more real effort than the 1.42-day raw time estimate reflects — treat the time estimate as under-counted and consider a manual override."
  ],
  "derivation": {
    "raw_commit_clustered_hours": 11.348, "sessions": 12, "commits": 48,
    "finished_workplans": 12, "finished_tasks": 51,
    "file_count": 235, "line_count": 93663
  }
}

Above the 1-day floor (no floor warning), but the sanity-check warning still fired — 12 finished workplans and 51 finished tasks against only 1.42 raw days is a clear under-count signal in its own right, independent of the floor. Same treatment as net-kingdom: the flagged, warning- carrying value is used as-is, not manually adjusted.

Manifest updated: estimated_effort_days: 1.418, approved_direct_costs: 0, target_multiple: 100 (unchanged, Product-defining) → Initial Target: 141,800 EUR (previously a hand-picked 2,500,000 EUR).

5. A bug found and fixed along the way

Applying the calculator to net-kingdom surfaced a real defect in workplan_task_counts(): it originally scanned only the top level of <repo>/workplans/, non-recursively — and NK-WP-0002 lives in net-kingdom/workplans/archived/, a convention several repos in this ecosystem use for finished workplans instead of deleting them. The initial scoped run silently reported zero finished workplans/tasks for a candidate that has exactly one, cleanly finished workplan. Fixed to scan recursively (rglob instead of glob); a regression test (test_workplan_task_counts_scans_archived_subdirectory) now guards this.

6. Summary table

Candidate	Old (hand-picked) Initial Target	New (calculator-derived) Initial Target	Warnings fired
net-kingdom-local-identity	200,000 EUR	10,000 EUR	Floor + sanity-check (both)
railiance-vergabe-teilnahme	3,500,000 EUR	648,800 EUR	None
info-tech-canon-service-surface	2,500,000 EUR	141,800 EUR	Sanity-check only

Every calculator-derived figure is materially lower than the earlier hand-picked illustrative placeholder — expected, since those placeholders were invented for shape-checking the schema, not reasoned from any real measurement. Two of the three carry explicit warnings recommending a manual override before this could ever inform a real Phase declaration; the third (vergabe-teilnahme) has no warnings, but is itself the product of a judgment call (§3) about which of two repos to measure.

7. Non-goals

• Declaring any real Phase — workplans/TREV-WP-0008-governance-and-pilot-rollout.md T05 is unaffected by this document.
• Resolving the railiance-apps/vergabe-teilnahme scoping judgment call with finality — flagged, not settled, in §3.
• Sourcing real get_token_summary data for these three repos — not attempted in this pass; approved_direct_costs: 0 reflects absence of data, not a claim that no AI cost was incurred.