Key concepts: one data core

Everything in os.construction rests on one idea: each fact about a job is stored once, and every part of the system reads that same fact. We call this the data core. This page explains what it is, why it matters and what it changes for the field, the office and the people reading the reports.

Two databases always drift

In a typical stack, a change order lives in at least three places: the PM tool where it was approved, the accounting system where the budget and contract are updated, and the spreadsheet where someone tracks it for billing and WIP. Each copy is updated at a different time by a different person.

Integrations help, but an integration is still a copy. Sync jobs fail quietly. Field names do not match. Cost codes are mapped by hand. Someone exports, someone imports, and the numbers are right until the next change. Month-end becomes the moment everyone stops and makes the copies agree.

The data core removes the copies. There is one change order record. The field, the office and the forecast are looking at it, not at their own version of it.

One record, many views

Follow CO #14 on the Riverside Medical Center sample job. It starts with RFI-212 (missing fire dampers on L3) and is priced at $86,400. When it is approved, nothing is exported or re-keyed. The same record shows up everywhere it matters:

Each module is a view of the record with its own workflow and permissions. The project manager sees CO #14 as a change with a scope description, an RFI link and approval status. Accounting sees it as a contract adjustment and a budget revision by cost code. The billing view sees a schedule of values line. The WIP view sees a change to contract value and estimated cost.

What lives in the core

The core holds the records construction runs on, and the links between them:

• Projects and contracts: the job, the prime contract, its schedule of values.
• Cost structure: cost codes and cost types, budgets and budget revisions.
• Commitments: subcontracts and purchase orders, with their change orders.
• Project records: RFIs, submittals, daily logs, photos and drawings, each tied to a job and, where it makes sense, a cost code.
• Financial transactions: AP invoices, AR billings, pay apps, retainage, journal entries.
• People and companies: your team, subcontractors, suppliers, owners and architects.

Links matter as much as records. RFI-212 links to CO #14. CO #14 links to the commitment it changes and the SOV line it adds. INV-4471 from Volt Electric links to PO-118. Because those links are real, you can start anywhere and trace the whole chain.

What changes day to day

For the field. A super’s daily log or RFI is not a note the office retypes. It is the first step of the record. If it turns into cost, the cost is already attached to the job and the cost code.

For project managers. Budget, committed cost and cost-to-complete are not a report from accounting that is two weeks old. They are the same numbers accounting sees, right now.

For accounting. AP coding, commitment matching and billing start from records that already carry the job, cost code and contract. Month-end is a review, not a reconstruction.

For leadership. WIP, over/under billing and fade are computed from posted records, not from a spreadsheet someone rebuilt. Every number can be traced back to its source.

What one core does not mean

One data core does not mean one giant screen or everyone seeing everything. Each role gets its own views and its own permissions. A subcontractor sees its own commitments and pay applications, not your margin. A super sees the field records for their jobs. See Roles and permissions.

It also does not mean locking your data in. You own it, and you can export it. See Data ownership and export.

Next

Read Projects and the record model to see how jobs, records and links are structured, then Cost codes and budgets.