← Back
Home › Systems › Industry and field operations

construction-project-management

construction project management

Procore, Autodesk Construction Cloud, Oracle Aconex

Open the construction-project-management pageconstruction-project… Object storagecloud: S3-compatible blob storage at cents per GB-month with 11 nines durability; pick by egress price, request price and latency, not by storage price alone.›Hdr histogramdata-structures: Log-linear bucketed histograms with bounded relative error for latency percentilesDeterministic simulationtestingdistributed: Run the whole system in one thread under a seeded scheduler with simulated network, disk and clock, so every failure replays from its seed.›Durable workflow executiondistributed: Ordinary code made crash-proof by logging every side-effect result and replaying the code from that log; activities run at least once, workflow logic must be deterministic.›Incremental sync cursorsdistributed: The client keeps one opaque token; each pull returns only the changes after it plus the next token, so sync cost scales with what changed, not with the dataset.›Offline mutation queuedistributed: Apply actions locally at once and queue them durably; on reconnect replay the queue idempotently, then re-apply unconfirmed ones on the server state.›Primary-backup replicationdistributed: One node orders all writes and ships them to standbys; the acknowledgement rule (none, one, all) sets what a crash loses, and an external arbiter decides who takes over.›Money representationfinance: Store money as integer minor units with an explicit currency exponent, compute in wider integers, and round once with a named rounding mode.›Image pyramidsgraphics: Gaussian/Laplacian pyramids and tiled multi-resolution images for zoom and blendingCritical path analysisgraphs: Longest dependency chain in a DAG of timed spans or build actionsTopological sortgraphs: Order the vertices of a DAG so every edge points forward; the core of build systems, schedulers and dependency resolution, with cycle detection for free.›Process supervisionhardware-os: A parent process starts services, reaps their exits and restarts them under a delay and burst-limit policy, then stops them with SIGTERM before SIGKILL.›Optical character recognition(text recognition)machine-learning: Find text lines in an image, read each crop with a CTC or attention model, then correct with a lexicon and score confidence for review routing.›Image codecsmedia: JPEG (DCT, Huffman), PNG, HEIF/AVIF decoding and encoding fundamentalsEmail delivery smtpnetworking: Outbound SMTP: queues, MX lookup, retries, bounces, feedback loops and IP warm-upMobile push deliverynetworking: Sending notifications through APNs and FCM: HTTP/2 requests, token hygiene, collapse keys, TTL and priority, and the retry rules that keep you un-throttled.›Webhook deliverynetworking: Reliable server-to-server HTTP callbacks: signed POSTs, 2xx-means-done, retries over days with jitter, endpoint disabling, SSRF guards and idempotent receivers.›Authorization models (RBAC,ABAC, ReBAC)security: How to decide who may do what to which object; roles for coarse rules, relationships for sharing, and checks on every object.›Coverage-guided fuzzingsecurity: Mutate inputs, run an instrumented target, and keep any input that reaches a new code edge; feedback turns blind guessing into incremental search.›Mutual TLSsecurity: TLS where the client also proves a certificate key, so every connection carries a verified, rotatable machine identity.›Inverted indexstorage: Map each term to a sorted, compressed list of the documents containing it; the core of full-text search and other fast set queries.›Optimistic concurrency controlstorage: Run transactions without locks, record what they read, and validate at commit that nothing changed; fastest when conflicts are rare.›Pdf object model parsingstorage: PDF xref tables, object streams, content stream operators and incremental updatesPoint-in-time recoverystorage: Periodic base backups plus a continuously archived change log let you rebuild the state as of any instant, then branch from there.›Business day calendarssystems: Holiday calendars, business-day adjustment rules (following, modified following) and settlement cyclesCalendar date arithmeticsystems: Civil dates, time zones (tzdb), DST gaps, month-end anchoring and duration mathEvent condition action rulessystems: Event-condition-action rule engines for automations, edit checks and alertsGraceful drainingsystems: On a termination signal, stop taking new work, finish in-flight work until a deadline, tell clients to reconnect elsewhere, then exit; clients resume from a token.›Recurrence rule expansionsystems: Expand an RFC 5545 RRULE lazily, in local wall-clock time, into concrete instants; store the rule, materialise only a bounded horizon.›Cooperative schedulingconcurrency: Green threads/coroutines yielding at await points on a user-space schedulerFault injectiondistributed: Inject latency, errors, kills and partitions via proxies, netem or hooksRecord replaydistributed: Record every nondeterministic input (time, randomness, I/O, model and tool outputs, per-tick player input) and re-execute deterministically for debugging, replays and state rebuildEvent sourcingfinance: Persist state changes as an append-only stream of immutable events per entity; current state is a fold over them, guarded by expected-version appends.›Message sequence numbersdistributed: A per-stream counter on every message lets the receiver detect loss, duplicates and reordering, ack cheaply and resume after reconnect with "send from N".›Cursor paginationnetworking: Keyset/opaque-cursor pagination for stable incremental reads from APIs and tablesLeasesdistributed: A lock that expires on its own: bounded-time ownership that survives crashes and partitions, given bounded clock drift and fencing tokens on writes.›Health checkingsystems: Decide per backend whether to route to it using probes and real-traffic errors, with consecutive-count hysteresis, capped ejection and a panic fallback.›Largest remainder roundingfinance: Splitting an amount into parts that sum exactly (largest remainder / Hamilton) for allocations, splits and prorationsBFS and DFSgraphs: The two basic graph traversals; BFS gives hop distances and levels, DFS gives discovery/finish order for cycles, components and topological order.›PRNGs (PCG, xoshiro)numerics: Small, fast, statistically strong non-cryptographic generators: PCG32 and xoshiro256**, with seeding, parallel streams and unbiased ranges.›Idempotency keysfinance: Client-chosen unique key per logical operation, stored with a request fingerprint and the final response, so retries replay the first result instead of acting twice.›+ 33 moreTransparent interceptionnetworking: Redirect traffic to a local proxy (iptables TPROXY/REDIRECT, eBPF) without app changesSyscall interceptionsecurity: Intercept syscalls via ptrace, seccomp user notify or a user-space kernelFencing tokensdistributed: A number that grows with every lock grant and is checked by the protected resource, so a paused ex-holder's late write is rejected.›Sparse matrices (CSR)numerics: Compressed sparse row stores only nonzeros as row pointers, column indices and values; SpMV streams them once, so it is memory-bandwidth bound.›Cryptographic hashes (SHA-2,BLAKE3)security: Collision-resistant fingerprints of data; SHA-256 for interoperability, BLAKE3 for speed, HMAC/HKDF for keyed uses.›+ 17 moreEbpfhardware-os: Verified in-kernel programs on hooks (kprobes, XDP, tc) with mapsPtrace process controlhardware-os: Ptrace: attach, read and write registers and memory, single-step, intercept signalsSeccomp bpfsecurity: Syscall filtering with seccomp BPF programs+ 9 more

How it is built

Architecture overview

A construction project management platform is the shared record of one building job that many companies work on at once: owner, designers, general contractor, subcontractors, suppliers. Its objects are the things a job produces every day: drawings and specifications, requests for information, submittals, issues and punch lists, inspections, daily reports, meeting minutes, schedules, change orders and cost. Each object has an accountable person, a due date, a formal status and a history, because on a construction job such records settle who knew what and when. The users are in an office with a large screen, or on site with a phone or tablet and an unreliable connection. Procore, Autodesk Construction Cloud and Oracle Aconex are the large products.

The idea that makes it work is that the project is the unit of sharing. Companies have accounts, but every record lives in a project, and what a user may see or change depends on their company's role in that project. Around that record sit four mechanisms: an offline-first mobile client that captures work on site and synchronises later, a versioned document register whose files go through review workflows, a schedule that is a dependency graph, and an integration layer (API, webhooks, open exchange formats) because no job runs on one vendor's software alone.

Parts:

 phone / tablet (site)                    web (office)                      other systems
 ┌─────────────────────┐                ┌───────────────┐                ┌──────────────┐
 │ local store + queue │                │ review, plan, │                │ ERP, BIM,    │
 │ issue·inspection·   │                │ cost, search  │                │ scheduling   │
 │ photo·daily report  │                └──────┬────────┘                └───────┬──────┘
 └──────┬──────────────┘                       │                                 │ REST + OAuth
        │ push queue / pull since cursor       │                                 │ ▲ webhooks
        ▼                                      ▼                                 ▼ │
 ┌───────────────────────────────────────────────────────────────────────────────────────┐
 │ project record: tenancy (company → project → role) · items with status & history      │
 │  documents ─ versions ─ transmittals │ RFIs·submittals·issues │ schedule │ cost       │
 └───────┬───────────────┬──────────────────────┬──────────────────────┬─────────────────┘
         ▼               ▼                      ▼                      ▼
   object storage    review workflows     rules ─► notifications   search index
   (files, tiles)    (steps, markup)      (push, mail, webhook)    (docs, items)

How the parts fit together

Site capture and sync

A site has gaps in coverage, and the engineer who finds a defect should not wait for a signal. Oracle Aconex's mobile app states the contract directly: you capture issues on site without a connection, and when the phone is online again it syncs them with the server. An Offline mutation queue is the mechanism: each action (create issue, attach photo, close inspection item) is applied to the local store at once and appended to a durable queue, which is drained in order when a connection returns. Two properties keep it correct. Every queued action carries a client-chosen key, so a request that was received but whose answer was lost is not applied twice (Idempotency keys). And a change to a record that someone else edited meanwhile is detected by a version check instead of overwriting it (Optimistic concurrency control); the conflicts are few because most site records have one owner at a time. Retries after failures wait with growing, randomised delays (Exponential backoff with jitter).

The other direction uses Incremental sync cursors: the client keeps a token for "everything up to here" and asks for what changed since. Aconex's API shows the same pattern for integrations: its document and mail services each have a "last updated" service that takes an everythingsince parameter, with a history flag on documents to return all changes. When each change also carries a per-stream counter (Message sequence numbers), a client can see that it has missed a change and re-pull. CRDTs are the alternative for records that several people edit at the same moment, such as a shared checklist; for single-owner records, queued mutations with version checks are simpler.

Photos and files are the heavy part of a capture. They upload as separate objects, resumably, and the record that references them is created or updated when the upload completes; see Local-first sync and File sync across devices for the general design.

image-codecs (no page yet) sit between the camera and the upload. A phone produces JPEG or HEIF photos, and the app decodes them to show a preview and to read the orientation, re-encodes a smaller copy before sending over a weak connection (the original stays on the device until the upload is acknowledged), and the server decodes to make the thumbnails and tiles the viewer shows. Decoding untrusted images is also a security boundary, so the decoder runs with limits on image size and memory.

Document register

The document register is the legal heart of a project. Aconex describes its Documents module as a filing cabinet with strict version control built in: documents are uploaded or updated (a new revision supersedes the previous one), searched, downloaded, and sent to other organisations as transmittals; the latest documents can be transmitted automatically to other organisations; a document can be made confidential, restricted to a named list of users, and every change is in an audit trail. Metadata is configurable per project (the API exposes a project document schema in which field names can be renamed), and registers are bulk-loaded through spreadsheets and bulk-processing profiles.

Three pieces of machinery sit behind that. Storage and versions: files go to Object storage, and the register row holds metadata, the revision chain and the pointers; a new revision is a new row and file, never an overwrite. Reading: drawings are large PDFs and images, so viewers need a page rendered as a tile pyramid (image-pyramids, no page yet) from a parsed document structure (pdf-object-model-parsing, no page yet); see PDF rendering. Finding: Inverted index gives full-text search over titles, numbers, metadata and extracted text; BM25 ranking orders the results. Scanned drawings and specifications have no text, so Optical character recognition turns the scan into text, after Document image preprocessing, and can read title blocks (sheet number, revision) so that a combined upload can be split and registered with less typing; the general design is on Document OCR and parsing.

Review and approval

A submittal or a drawing review is a multi-step process with several reviewers, deadlines and markup. Aconex Workflows templates a sequence of steps, lets a reviewer mark up in an online viewer or offline and upload the marked-up file, consolidate markups from parallel reviews, delegate or reassign a document, start a sub-workflow, skip a step, or terminate a document in the workflow. That is a long-running process that must survive restarts and outlast the people who started it: a Durable workflow execution engine records each step's result and resumes from the log, and timers (due dates, reminders) are driven by a Hierarchical timing wheel or a persistent timer table. The fixed shape of a review (steps, who, in what order, parallel branches) is a graph, which is why DAG workflow execution is the alternative for batch-like processing; for human steps with weeks-long waits the durable-execution style fits better. See Durable workflow engine for the engine itself.

Schedule

A construction schedule is a graph of activities with durations, dependencies and working calendars. The critical path (critical-path-analysis, no page yet) is the longest chain of dependent activities; Kelley and Walker's 1959 paper describes the method. It needs the graph in dependency order (Topological sort), a forward pass for earliest dates and a backward pass for latest dates; the slack of an activity is the difference. What makes site schedules harder than the textbook is the calendar: holidays and weather days (business-day-calendars, no page yet), and repeating work such as weekly inspections, expanded lazily from a rule with Recurrence rule expansion, whose format is RFC 5545. A change to one activity moves its successors, so the engine recomputes only the affected part of the graph (BFS and DFS from the changed node).

calendar-date-arithmetic (no page yet) turns durations into dates correctly: a duration in working days is added on the project's calendar, a milestone anchored to the end of a month stays at month end, a daylight-saving change does not move an inspection by an hour, and a site in another time zone sees the same civil date as the planner. The scheduler computes with dates and calendars only, and renders them in the viewer's zone.

Rules and notifications

Teams want "when X happens, do Y": an RFI is overdue, an inspection fails, a document is superseded. These are event-condition-action rules (event-condition-action-rules, no page yet): a stream of record changes is matched against per-project rules, and a matching rule creates a task, sends a notification or calls a webhook. For a handful of rules per project a direct matcher is enough; a Rete rules engine pays off only when many conditions share patterns.

Delivery fans out three ways. Phones receive pushes through the platform gateways (Mobile push delivery); the push only says "something changed", and the app pulls the details by cursor. Email carries formal notices and reply-by-mail flows (email-delivery-smtp, no page yet; see Email delivery system, SPF, DKIM and DMARC sender authentication). Servers receive Webhook delivery for integrations. All three use a Durable job queue so a failed send is retried and a permanently failing one lands in a Dead-letter queue.

Access and tenancy

A project spans competing companies: a subcontractor must see its own packages and the drawings issued to it, but not the general contractor's budget or another subcontractor's bid. The access model is therefore company, project and role (Authorization models), with per-item overrides such as the confidential documents above. The Aconex API list shows the shape: separate Projects, Directory, User Role, Packages and Lobby services. Procore's API makes the company explicit: its SDK sends a Procore-Company-Id header on requests; API access is delegated by OAuth; Aconex offers OAuth and basic authentication and says volume and frequency of requests are limited, which is typically implemented as a Token bucket per client.

Models and drawings in context

Building models are part of the project record, not a separate system. IFC is the open schema for building models; IfcOpenShell is a library that parses IFC2x3, IFC4 and IFC4x3 and can convert models to other formats. BCF (BIM Collaboration Format) is the open format for model-based issues: a topic with comments and viewpoints, where a viewpoint stores a camera (perspective or orthogonal) and a snapshot and, per the BCF API specification, viewpoints are immutable (a new view is a new viewpoint). The BCF API defines project, topic, comment, viewpoint and file services, filtering by OData expressions such as modified_date, and authorisation as per-entity permissions that the server reports to the client. Aconex Models supports BCF 1.0 and 2.0 and keeps each model as a "stack" holding the current version and earlier versions. For the modelling side, see BIM authoring and coordination.

Cost

Budgets, commitments, change orders and pay applications are money. Amounts are held as integer minor units with a named currency (Money representation); allocating a lump sum across cost codes so that the parts sum exactly to the whole needs largest-remainder rounding (largest-remainder-rounding, no page yet). The workflows around cost are those of Procurement and purchase approvals and Invoicing and accounts receivable.

Operations and assurance

Process supervision restarts the sync API, the document processors and the notification senders when they exit; queued mutations from phones are idempotent, so a restart replays them safely. Graceful draining lets a sync node finish the batch of site mutations it is applying and tell phones to reconnect elsewhere before a deploy, so an inspector's photo upload is resumed, not repeated or lost.

Mutual TLS is the identity between the internal services (sync API, document store, search, notification sender), so only the sync service can write records and only the sender can reach the push gateways; phones and integrations use their own tokens at the edge. Primary-backup replication keeps a standby of the project database, and Point-in-time recovery rebuilds it as of an instant, for example before a bulk change that superseded a set of drawing revisions; drawings and photos are immutable objects and only their records need restoring.

hdr-histogram (no page yet) records sync latency (a mutation accepted to visible on another phone) and document-open time as percentiles, because a site team on a poor connection feels the tail. Deterministic simulation testing replays sync with dropped connections, duplicate and reordered mutations and concurrent edits under a seeded scheduler, to show that no record is applied twice or silently overwritten. Coverage-guided fuzzing targets the parsers of untrusted files: uploaded drawings and PDFs, images, and imported schedule and model files.

Data and control flow

A defect found on site, to a closed issue:

  1. The inspector opens the checklist on the phone, records a failed item with a photo and a location (scanning a QR code at the place is one way Aconex Mobile selects the location). Everything is written to the local store and the mutation queue.
  2. When a connection returns, the queue drains in order. Each mutation carries its key; the server applies it once and returns the new version.
  3. The server stores the photo as an object and the issue as a record with status, assignee and due date, and appends the change to the project's change stream.
  4. A rule matches "failed inspection item" and creates a task for the responsible subcontractor. A notification job queues a push and an email; the push wakes the subcontractor's app.
  5. The app pulls changes since its cursor, shows the issue, and the subcontractor fixes and updates it, again possibly offline.
  6. The inspector re-inspects and closes the issue. The history shows every step. Webhook subscribers receive the update and a connected system (for example a quality dashboard) re-reads the record.

A drawing revision issued to the team:

  1. The designer uploads the new sheets, possibly splitting a combined PDF into separate documents.
  2. The register creates a new revision per sheet; the previous revision is marked superseded, not deleted.
  3. A transmittal records which organisations received which revisions, and when.
  4. Tiles for the viewer are generated asynchronously; the search index is updated; if the sheets are in a review workflow, the engine starts the first step.
  5. Mobile clients receive a "changed" push and pull the new revision, so site staff do not build from superseded drawings.

Scaling

In the order the limits bite:

  1. Large files, mobile networks. Drawings and photos dominate bytes. Levers: resumable uploads, tiles and thumbnails, caching of the current drawing set on the device, and keeping files in object storage behind a CDN.
  2. Sync volume. A busy project produces many small changes. Levers: cursors that return only changes, per-project change streams, batching of mutations from the client.
  3. Search and OCR. Both are batch work per upload. Levers: asynchronous pipelines, queues with backpressure, one index per tenant or per project.
  4. Schedule size. Large project schedules have a great many activities; the lever is incremental recomputation from the changed node.
  5. API consumers. Integrations poll and bulk-export. Levers: rate limits, "since" endpoints, webhooks instead of polling.
  6. Tenant isolation. Many projects share one platform; keep permission checks in one place and test them hardest.

Failure modes

FailureSymptomCauseFix
Duplicate records after a bad connectionthe same issue or photo appears twicerequest applied but reply lost, client retried without a keyidempotency key per queued mutation
Lost editone person's changes disappearlast-writer-wins on a shared recordversion check on write; show the conflict
Stale drawing in usecrew builds from a superseded sheetoffline cache not refreshed, no "superseded" markerpush on new revision; show revision and status on every sheet
Missing historyno one can say who changed a recordedits overwrite, audit trail optionalappend-only history for every status change
Confidential leaka subcontractor sees a restricted documentproject-wide role without per-item check, or search index ignoring permissionscheck permission at read and filter search results by permission
Review stucka document waits on a person who leftworkflow has no timeout or reassignmentdue dates, reminders, reassign and skip steps
Wrong critical pathschedule shows slack where there is nonemissing calendar, wrong dependency type, lag treated as durationvalidate links; one calendar per resource; recompute and compare
Notification floodusers mute everythinga rule per event with no groupingdigest, per-user settings, dedupe by item
Webhook consumers out of stepexternal system shows old statusmissed or reordered callbackstreat the callback as a hint, re-read the record, use cursors
OCR misreads title blocksheet registered under the wrong numberlow-quality scanshow the reading with a confidence flag and require a check on low confidence

Real implementations

namewhat it isrepolicencenotes
Procoreconstruction management platformdeveloper portalproprietarycompany-scoped REST API with OAuth; open-source JS SDK below
Procore JS SDKNode client for the Procore APIprocore-oss/js-sdkMITsets Procore-Company-Id; OAuth helpers
Autodesk Construction CloudAutodesk's construction platform; APIs via Autodesk Platform ServicesAPS Node SDKApache-2.0SDK modules: authentication, Data Management, Model Derivative, OSS, Webhooks, construction issues, account admin
Oracle Aconexdocument-centric project collaboration: Documents, Mail, Workflows, Models, Field, Costhelp centreproprietaryREST APIs with an API per module; offline capture in the mobile app
OpenProjectopen-source project management with Gantt schedulingopf/openprojectGPL-3.0scheduling and work packages; not construction-specific
IfcOpenShellIFC library and geometry engine, with BCF and IDS supportIfcOpenShell/IfcOpenShellLGPL-3.0includes Bonsai, a Blender-based IFC authoring add-on
BCF APIbuildingSMART web-service specification for BIM issuesbuildingSMART/BCF-APIsee repotopics, comments, viewpoints, files; OData filtering
BIMserveropen-source BIM model serveropensourceBIM/BIMserverAGPL-3.0open-source BIM model server platform
web-ifcread and write IFC in JavaScriptThatOpen/engine_web-ifcMPL-2.0browser-side IFC

Sources

Similar systems

Share the most building blocks with this one.

project-management 59 %calendar 48 %time-tracking 42 %cpm-scheduling 41 %social-benefits 37 %