Architecture
How the operating system is built.
The architectural choices that make Joblogic an operating system, not a platform with features bolted on top.
The claim
The word matters because the architecture matters.
Operating system is a strong claim. Most software vendors using the term don't earn it — and the imprecision makes the language harder to take seriously. So we want to draw the line here, in plain terms.
An operating system isn't a feature, a module, or a marketing label. It's the foundation everything else runs on. The layer beneath the workflows. The thing that decides what the system organises itself around, what counts as a first-class input, and what the system can act on without forcing humans to translate, reconcile, or remember.
Most field service software is a workflow engine. The contract sits somewhere else — in a folder, a spreadsheet, the contract manager's head. An operating system is built so the contract is the foundation. That single architectural choice changes what the rest of the system can do.
Pillar 01 of 03
The contract is what the system runs against — not documentation alongside it.
In job-led software, the contract is documentation. Engineers don't read it. The dispatch system doesn't read it. The invoicing module doesn't read it. The contract gets stored, referenced when something goes wrong, and otherwise ignored. The system runs on the assumption that whoever's awake at the helpdesk knows what the contract said.
Joblogic reads the contract as data. The terms aren't notes attached to a record — they're the rules the system runs against, every time a request comes in, every time a job is dispatched, every time work is signed off, every time an invoice is raised. SLA tiers, scope boundaries, rate cards, chargeability rules, escalation paths, certificate requirements, customer-specific protocols: first-class inputs the platform acts on at the moment of decision.
The practical consequence: the system can run forty contracts each on their own terms, in parallel, without the team holding the difference between them in their heads. The contract isn't documentation alongside the operation. It is the operation.
Pillar 02 of 03
Compliance is in the architecture, not in a module.
The standard pattern in field service software treats compliance as a separate concern. There's a job module and there's a compliance module. Certificates are uploaded after the fact. Audit trails are reconstructed at audit time. The two systems are connected by humans who know they should be connected — and who carry the risk when they aren't.
Joblogic treats compliance as an architectural property of the platform. Engineer credentials are checked against the job before dispatch — not after the engineer has driven across town. Job sign-off is blocked when the regulation requires evidence the engineer hasn't captured. The audit trail is generated as a byproduct of the work itself, not assembled from spreadsheets and PDFs the night before an inspection.
This applies across the regulatory regimes UK service contractors actually operate inside: Building Safety Act, Gas Safe, F-Gas, NICEIC, Part P, ACOP L8, CAR, RRFSO, SFG20. The system reads each regime's evidence requirements and enforces them at the moments where breaches usually happen — at dispatch, at sign-off, at invoice. Accountability still sits with the operator. The architecture removes the gaps that human reconciliation can't reliably close.
Pillar 03 of 03
The system runs the systematic. Your team commands the judgement.
There are two kinds of work inside any service contracting operation. There's the systematic work — applying contract terms, checking credentials, dispatching against SLA tiers, capturing evidence, raising invoices when the rules say it's time. And there's the judgement work — handling the customer who's unhappy, deciding whether something is in scope, mentoring a new engineer, choosing which contract renewal to prioritise this month.
The systematic work is what every operator currently does with humans because the software couldn't. The judgement work is what every operator says they'd do more of if they had the time. Joblogic is built around that division: the architecture takes the systematic work, your team keeps the judgement work, and the boundary between them is something the operator controls.
That boundary is configurable, observable, and accountable. Confidence thresholds determine when the system acts and when it surfaces the decision to a human. Audit trails record every decision the system made and the rule it followed. Approval gates sit at the points the operator decides matter — chargeability above a threshold, scope variation, customer-impacting changes. Accountability remains where it belongs, with the people who own the work.
More on how the system handles exceptions and edge casesA useful framework
Three questions to ask any operating system.
If a platform claims to be an operating system, three architectural questions reveal whether the claim holds. We use the same three questions to test our own architecture. They're useful for any technical due diligence — including ours.
01
Is the contract a first-class input, or documentation?
Ask whether the platform reads contract terms as rules the system runs against — at the moment of dispatch, sign-off, and invoicing — or whether the contract is stored as a record the team references when something goes wrong. The answer separates operating systems from workflow engines with contract folders attached.
02
Is compliance enforced by the architecture, or sold as a module?
Ask whether engineer credentials are checked at the moment of dispatch and whether sign-off is blocked when the regulation requires evidence that's missing. Compliance modules sold separately are a structural signal — the architecture wasn't built around the regulatory regime, so the compliance has to be added on top.
03
Is the boundary between system and human configurable, observable, and accountable?
Ask whether the operator can set the thresholds at which the system acts versus surfaces a decision, whether every decision the system made is recorded with the rule it followed, and whether human approval sits at the points the operator decided matter. An operating system gives the operator the controls; a platform with autonomous features hands the controls to the vendor.
The boundaries
The boundaries the system doesn't cross.
An operating system that ran every decision unilaterally would be the wrong architecture for service contracting. So the system doesn't run those decisions. The operator does. We built the architecture to make the boundary visible.
Decisions that affect commercial outcomes above a configurable threshold sit with humans — chargeability changes, scope variations, contract-impacting commitments. Decisions that affect customer relationships sit with humans — escalations, complaint handling, contract conversations. Decisions that involve regulatory judgement — interpreting whether a particular situation triggers a compliance obligation — sit with humans, with the system surfacing the question and the relevant evidence.
Behind every decision the system makes, three properties hold. The decision is recorded. The rule it followed is recorded. The threshold that determined whether the system acted or surfaced is set by the operator. That's not a feature added to reassure buyers about AI safety. That's the architecture working as intended.
More on data, security, and AI governance