- Documentation
- /
- Csim
- /
Application Overview
What CSIM models, and the ideas behind it
The Core Chain
The pack's stated emphasis, and the reason the app exists:
WorkPackage
→ InterfaceRegister (this work interacts with that work, here, then)
→ InterfaceHazard (what could go wrong at the interaction)
→ InterfaceControl (what manages it, who owns it, how it is verified)
→ FieldAssuranceEvent (someone went and looked)
→ AssuranceFinding (what they found)
→ CorrectiveAction (what changed as a result)
Read left to right it is a plan. Read right to left it is evidence. The point of putting both on one chain is that a control can be compared against what the field actually shows — a planned control with no verification, or a finding with no linked control, are both visible as gaps.
Supporting Chains
Organisation → ContractorProfile (prequalification)
Organisation → Contract → ContractRequirement / WorkPackage
WorkPackage → SubcontractorEngagement (disclosure, not concealment)
WorkPackage → Mobilisation → MobilisationChecklistItem
Person → PersonCompetency / SiteInduction / SiteAccessAuthorisation
Organisation → ContractorPlant → PlantSiteApproval
CoordinationMeeting → MeetingAttendance / InterfaceDecision
AssuranceFinding → StopWorkEvent
Incident / AssuranceFinding / ContractorPerformanceReview → CorrectiveAction
WorkPackage → Demobilisation
Key Concepts
Contract and work package are deliberately separate. A Contract is the
commercial engagement — who is engaged, by whom, for how long, under what
terms. A WorkPackage is a bounded operational scope: this work, in this
area, over this period, with a named site representative and contractor
supervisor. One contract carries many packages; the interface risk lives at
package level, because that is where the work physically is.
The interface register is not a task risk assessment. It deliberately does
not duplicate the contractor's own JSA or SWMS. It records the interaction
between parties, activities, equipment and areas — the shared stairway, the
load path over someone else's walkway, the isolation boundary two crews depend
on. other_work_package_id names the counterpart explicitly, so the
relationship is a fact in the data rather than an assumption in someone's head.
Controls carry a performance requirement and a verification schedule.
An InterfaceControl is not a sentence of intent. It has an owner, a
performance_requirement stating what "working" means, a
verification_method and verification_frequency, and a
next_verification_due_at. A control that is never verified is as visible as
one that fails.
Access is decomposed. Competency evidence (PersonCompetency), induction
(SiteInduction) and authorisation to be on site
(SiteAccessAuthorisation) are three separate records, because they expire
independently and are granted by different people. Someone can hold a current
licence, a valid induction, and still have access suspended — the demo data
carries exactly that case.
Contractor plant is separate from its approval to operate. A
ContractorPlant row is the contractor's asset; a PlantSiteApproval is this
site's decision about it, for a period, in named areas, with restrictions. The
same crane can be approved for one area and not another.
Findings do not require an incident. An AssuranceFinding stands on its
own — including POSITIVE_OBSERVATION, so the record is not purely a fault
log. A CRITICAL finding may issue a StopWorkEvent, which carries an
escalation_level and, importantly, explicit conditions_for_restart rather
than an implicit "when someone says so".
Corrective actions have three possible origins. A finding, an incident, or
a performance review. All three point at the same CorrectiveAction table, so
"what are we actually fixing" is one question with one answer, not three
disconnected lists.
Decisions supersede rather than mutate. InterfaceDecision carries
supersedes_decision_id, so a change of position at an interface leaves a
trail. The demo shows a lifting decision being tightened after a stop-work,
with the original preserved.