Boxes, Arrows, and the Cycle That Connects Them: How AIMQC Maps Data to Action

Some systems are best understood by reading them. Others are better shown. AIMQC sits in the second category — not because it is too complex to describe in words, but because the relationships between its parts are the point. The boxes matter less than the arrows.

What follows is a visual walkthrough of how the system connects data to documents to information to humans to actions — and back again. The first two diagrams describe the system at the architectural level. The last two were generated directly from the application's schema and workflow gate logic — the actual domain objects, status enums, and enforcement rules as they exist in the codebase.

---

The full system: layers and flows

The outermost view shows the system as a set of layers, each responsible for a specific concern, connected by deliberate flows.

flowchart TD
    subgraph "User Layer"
        U1[Administrator]
        U2[Manager]
        U3[Field Worker]
        U4[Client/External User]
    end

    subgraph "Application Layer"
        WA[Web Application<br/>browser-based]
        MA[Mobile Application<br/>offline-capable]
    end

    subgraph "Processing Layer"
        IE[Ingestion & Extraction<br/>Documents, Specifications, Reference Data]
        WB[Workflow Builder<br/>Documents + Standards → Tasks/Activities/Deliverables]
        AG[AI Agents & Orchestration<br/>Processing • Packaging • Notifications]
    end

    subgraph "Data Layer"
        CDL[Core Data Layer<br/>Organization/Project/Location<br/>Resources/Equipment/Personnel<br/>Processes/Standards/Forms<br/>Tasks/Activities/Results]
    end

    subgraph "Output Layer"
        RP[Reporting & Packaging<br/>Progress/Status/Deliverables/Audit]
    end

    subgraph "External References"
        STD[Standards<br/>Industry/Regulatory/Client]
    end

    subgraph "Cross-Cutting Concerns"
        SEC[Security & Governance<br/>RBAC • Row-level • Audit logs<br/>PII tagging • Export controls]
    end

    U1 --> WA
    U2 --> WA
    U3 --> MA

    WA -->|uploads| IE
    WA -->|configure| WB
    MA -->|submit| WB
    MA -->|sync| RP

    IE --> CDL
    CDL -->|rules & data| WB
    WB -->|results| RP
    AG --> WA
    AG --> WB

    STD -.->|reference| IE

    RP --> U4

    SEC -.->|secures| WA
    SEC -.->|secures| MA
    SEC -.->|governs| CDL

A few things worth noting. The data layer is not an endpoint — it is the centre. Standards enter as references, not hard dependencies. Security and governance sit as a cross-cutting concern across application, mobile, and data layers — not as a gate at the edge.

---

The entity model: what lives in the data layer

Inside the data layer, the domain is made up of typed entities with enforced relationships. This is the model that everything else in the system operates against.

The entity model grounds the architecture in real construction QC concerns: organizations own projects, projects include locations, people hold credentials and are assigned to tasks, standards inform processes, and activities capture results that feed reports and close out workflows. Every relationship here is a constraint — and constraints are what make data verifiable rather than just present.

---

The inspection chain: ITP → IR → ITR → Turnover

The following diagram was generated from the application's Prisma schema — the actual domain models, status enums, and intervention types as defined in the codebase, combined with the workflow gate validation logic that enforces completion criteria at runtime.

This is the core inspection chain as it runs in production. The interventionType values — H (Hold), W (Witness), S (Surveillance), R (Review) — map directly to Alberta QC practice. The workflow gates are not advisory: a TurnoverPackage cannot reach completed status while any gate condition is unmet.

---

The non-conformance lifecycle: NCR → CAPA → RCA

This diagram was also generated from the schema — the NCRStatus, NCRDisposition, CAPAStatus, CAPAEffectiveness, and RootCauseMethod enums, plus the relational structure between NonConformanceReport, CorrectivePreventiveAction, and RootCauseAnalysis models.

The non-conformance lifecycle does not terminate at the NCR. A disposition triggers either a corrective action, a root cause analysis, or both. Root cause informs the corrective action. The corrective action is verified, then reviewed for effectiveness — a feedback loop that feeds back into process improvement, not just record-keeping.

---

Why diagrams matter here

Construction QC is a domain where the relationships between events, records, and obligations are load-bearing. Getting an inspection record to the right state is not enough if it is not linked to the right ITP line item. Closing an NCR is not enough if the corrective action was not verified. Completing a turnover package is not enough if the upstream records have gaps.

Diagrams make those dependencies legible — to engineers designing the system, to coordinators understanding their workflow, and to auditors reviewing what happened. The boxes and arrows are not a summary of the software. They are the specification it is built from.

---

David Olsson is CTO at AIMQC. Contact: dolsson@aimqc.com