The cost data model
Construction cost reporting depends on relationships. A labor hour is only useful when it is tied to a project, date, activity, trade, rate, and status. A material quantity is only useful when it connects to a unit, cost, purchase order line, and activity code. A budget line is only useful when actuals can be compared against it.
A construction cost data API should preserve those relationships instead of flattening everything into disconnected exports.
Core cost API resources
- Projects - project-level context and status.
- Activity codes - cost and productivity grouping.
- Budget lines - planned cost by activity, CWP, payment item, and category.
- Committed actuals - labor, equipment, material, and subcontractor cost entries.
- Production quantities - installed quantities for unit-cost reporting.
- Purchase orders - commitments, line items, consumption, and remaining exposure.
- Early signals - cost trajectory, productivity drift, and exception flags.
Useful endpoint pattern
GET /api/v1/projects/{project_id}/budget-lines
GET /api/v1/projects/{project_id}/cost-entries?from=2026-06-01&to=2026-06-30
GET /api/v1/projects/{project_id}/production-entries?from=2026-06-01&to=2026-06-30
GET /api/v1/projects/{project_id}/purchase-orders
GET /api/v1/projects/{project_id}/early-signalsFrom cost report to execution control
A cost data API is not just for month-end reporting. When actuals and production quantities are linked daily, contractors can see unit-cost drift, productivity dips, and PO consumption problems while there is still time to adjust the work.
Where TCC fits
TCC already connects field entries, activity codes, budgets, purchase orders, production quantities, work orders, and early signals. That makes it a strong source system for construction cost dashboards and future API-based cost data access.