DN Agent Team Cost and Capacity Planner v1.0
Prepared 22 October 2026 (Africa/Johannesburg). Batch 2, article 73.

EVIDENCE AND PURPOSE
This is an authored, deterministic synthetic planning model. No live agent,
company, vendor, customer, payment account or employee was deployed or tested.
There are zero observed deployments and no measured performance, accuracy,
savings, prices, revenue, profit or return on investment. All numerical inputs
are fictional assumptions. CU means fictional cost units, not a currency quote.
Technical sources in assumptions.json support design principles, not the numbers.

WHAT IS COUNTED
An incoming work item is one role-specific internal task. Research, sales,
operations, finance and support items differ in purpose and cannot be treated as
interchangeable client outcomes. The fixed mix per 100 incoming items is
10 research, 20 sales, 20 operations, 10 finance and 40 support. These five roles
are workflow categories, not five employees or five proven autonomous agents.
Fractional counts represent scenario averages under the fixed mix.

LOCKED INPUTS
Role cost CU per attempt: 1.20, 0.25, 0.80, 0.15, 0.10.
Routine human minutes per attempt: 6, 4, 10, 4, 3.
Extra rescue minutes per exception item: 20, 15, 30, 10, 12.
Profiles (rerun share, exception share, final acceptance share, review multiplier):
Lean = (0.10, 0.05, 0.95, 0.75).
Planning = (0.25, 0.10, 0.90, 1.00).
Surge = (0.50, 0.25, 0.75, 1.50).
Grid: each profile x 50/100/200 incoming items x 10/15/25 owner hours = 27 cases.
Fixed owner maintenance = 2 hours per week. Fixed software = 200 CU per month.
Owner hour value = 40 CU/hour. Month conversion = 52/12 weeks, not four weeks.

ATTEMPTS, EXCEPTIONS AND ACCEPTANCE
Every incoming item has one initial attempt. A rerun share r receives exactly
one extra attempt: no item has more than two attempts. This is an authored
rerun scenario, not a geometric retry model or an estimated failure rate.
Routine review occurs on every attempt, including extra attempts. The profile
multiplier applies to routine review only. Rescue is extra time beyond routine
checks, once per exception item. Exceptions may overlap reruns; adding their
incremental minutes does not imply that the populations are disjoint.
Final acceptance a is an independent assumption after attempts and handling.
It is not calculated from r or the exception share and is not a success test.
Planned accepted = N*a. Planned unfinished = N*(1-a). Neither is observed.

FORMULAS
For role i, let n_i = N * mix_i, c_i = CU per attempt, t_i = routine minutes,
z_i = extra rescue minutes, r = rerun share, e = exception share and m = routine
review multiplier. The five mix shares sum to one.
Weekly variable software cost = sum_i(n_i * (1+r) * c_i).
Weekly routine review hours = sum_i(n_i * (1+r) * t_i * m) / 60.
Weekly rescue hours = sum_i(n_i * e * z_i) / 60.
Total weekly owner hours = routine + rescue + 2.
Monthly software = fixed monthly software + weekly variable software * 52/12.
Monthly owner-time value = total weekly owner hours * 52/12 * owner hour value.
Full modeled monthly cost = monthly software + monthly owner-time value.
Monthly planned accepted = N * a * 52/12.
Software cost per planned accepted = monthly software / monthly planned accepted.
Full cost per planned accepted = full modeled monthly cost / monthly planned accepted.
Conditional maximum-two-attempt software amount = fixed monthly software +
  sum_i(n_i * 2 * c_i) * 52/12.
Incoming capacity floor = floor(max(0, owner budget - 2) /
  ((routine hours + rescue hours) / N)).
Overload = total weekly owner hours > owner budget, using unrounded values.

CAPACITY AND COST INTERPRETATION
Capacity holds the mix, review times and exception assumptions constant. It is
an aggregate time-budget planning ceiling, not a scheduling or queuing model.
It does not guarantee arrival timing, external system availability, accepted
quality, profit, or a service-level agreement. An exact budget match passes the
arithmetic check but leaves no modeled time reserve. The comparison does not
automatically reduce volume or reallocate work among roles.
If overloaded, planned acceptance is not realized or achievable throughput;
actual outcomes are unknown. Planned unfinished counts do not include an
estimate of extra backlog from insufficient owner time. Cost-per-accepted
ratios continue to use the labeled planned denominator, never actual output.
Owner time value is noncash opportunity valuation, not a cash expense or saving.
The two-attempt software amount is conditional on fixed per-attempt costs,
fixed workload and fixed scope. It is NOT an actual enforced bill cap. It does
not cap owner time or include unmodeled services, usage, taxes or fees.
No revenue, setup investment, payback, causal savings or profit is modeled.

ZERO INPUT AND VALIDATION
The offline HTML accepts integer N>=0 and finite nonnegative budget, fixed
software and owner hour value. Negative, blank, nonfinite or invalid-profile
inputs are rejected rather than silently replaced by zero.
At N=0, attempt cost, routine review, rescue and planned acceptance are zero;
the fixed software cost and 2 maintenance hours remain. Cost-per-accepted and
capacity outputs are unavailable because their denominators are zero.
At zero budget, required maintenance can still cause overload. Zero fixed
software or zero owner hour value is valid and retains its actual meaning.

REPRODUCTION AND PRECISION
Requires Python 3 standard library only. Run python build_model.py from any
working directory; assumptions.json is read beside the script. Use
python build_model.py --output /path/to/new-directory for an isolated repeat.
The script writes assumptions.json, roles.csv, scenario-results.csv,
scenarios.json, MODEL-METHODOLOGY.txt and summary.json. It does not overwrite
the HTML planner, article or media. No network, randomness or live tests run.
All calculations use exact rational arithmetic. Rounding to 12 decimal places
occurs only when exporting noninteger numerical results. Capacity floors and
overload classification use exact, unrounded values. CSV nulls are blank.
The standalone HTML uses JavaScript numbers and displays rounded outputs;
rounding differences do not establish differences in the underlying model.

LIMITATIONS AND REVIEW
The additive model has no observed calibration, demand distribution, queue,
correlation estimate, measured model quality or evidence of reviewer accuracy.
Approval, access control, idempotency and outcome reconciliation must be
implemented separately. The planner does not connect to or enforce any system.
Calculation review can establish internal consistency only, not real-world
fitness. Independent review status belongs in a separate review report.
