Projects and the record model

Every job in os.construction is a project, and everything that happens on that job is a record attached to it. Records are linked to each other, so you can follow a hidden condition from the super’s phone all the way to a pay app line and a change in the margin forecast. This page explains that structure.

The project

A project is the job: Riverside Medical Center, Job #24-118, Phase 2 in our sample data. It carries the things that are true for the whole job:

• Identity: job number, name, phase, address, owner, architect, key dates.
• Prime contract: the agreement with the owner, its contract sum and its schedule of values (SOV).
• Cost structure: the cost codes and cost types used to budget and track cost on this job.
• Team: who works on the job, from the project executive to the field, and which outside companies are involved.

Projects can be grouped (by region, by division, by project executive) so portfolio views like “14 active jobs, 3 fading margin” are just filters over the same projects, not a separate report.

What a record is

A record is one thing that happened or one thing that exists on the job. Each record type has its own fields and workflow, but every record shares a common spine:

Field	What it means
Project	The job it belongs to. Always set.
Type and number	RFI-212, CO #14, PO-118, INV-4471, Pay App #9.
Status	Where it is in its workflow: draft, submitted, approved, closed.
Cost code	Where it lands in job cost, when it touches money.
Links	The other records it came from or affects.
History	Who created and changed it, and when. Includes agent actions.

Common record types:

• Field and project records: daily logs, photos, RFIs, submittals, punch items, meeting minutes, drawings.
• Contract records: prime contract, change orders, schedule of values.
• Cost records: budgets and budget revisions, commitments (subcontracts and purchase orders), commitment change orders.
• Financial records: AP invoices, AR billings and pay apps, retainage, journal entries.

Links are the point

A record on its own is a form. Linked records are a story. On Riverside Medical, the chain looks like this:

Each arrow is a real link stored in the data core, not a reference typed into a notes field. That gives you three things:

1. Traceability. Open the pay app line and you can walk back to the change order, the RFI and the photos that justified it. Useful when an owner’s rep asks why a line exists.
2. No re-keying. When a record moves forward (RFI becomes CO), the next record starts with the facts already filled in: project, cost code, scope description, attachments.
3. Impact views. From any record you can see what it affects. An open RFI with a likely cost impact shows up as exposure before it becomes a change order.

Records and money

Records that touch money always carry a cost code, and often a cost type (labor, material, subcontract, equipment, other). That is what lets a change order, an AP invoice and a pay app line roll up into the same job cost report without anyone mapping them by hand. See Cost codes and budgets.

History and audit

Every record keeps its own history: who created it, who changed which field, who approved it and when. Agent actions are recorded the same way, with the agent named and the human who approved the action alongside it. See Approvals and audit trail.

Statuses and closeout

Each record type has a workflow, and the project rolls those statuses up: open RFIs (23 on Riverside, 4 overdue), pending change orders, unbilled approved changes, missing lien waivers. At closeout those rollups become a checklist: everything open is visible in one place, instead of being discovered in the last pay app.