Skip to content
Current-state architecture

LiftIQ is being built as a read-first recommendation layer for live operational judgement.

The current demo is a front-end concept. It uses deterministic seeded data and rule-based logic to show how one overlay can rank options, hard-block unsafe matches, and keep the scoring visible under pressure.

Module status Design partner model Talk to Pressure Systems
Current logic path

What LiftIQ does now, in truthful terms.

LiftIQ currently demonstrates browser-based recommendation logic, seeded scenarios, and visible hard blocks for missing required credentials. It does not yet ingest live data, write back to dispatch systems, or persist operational audit events.

1

Seed the operational context

The governed demo uses fictionalised operator, site, client, and branch records. Every scenario is deterministic, so the output is stable and reviewable.

2

Apply recommendation rules

SmartRank weights fit, experience, readiness, and fairness. FatigueGuard applies monitor and block thresholds. The current credential gate blocks missing mandatory requirements.

3

Show ranked options and reasons

The score breakdown panel remains visible because that is one of the strongest current product behaviours. Dispatchers should be able to review the reasoning, not guess what the system did.

4

Keep actions in preview state

The UI currently uses preview and demo actions only. There is no live dispatch write-back, no live notifications, and no immutable audit export.

Current state

One governed demo. No backend.

  • Seeded front-end data only.
  • Rule-based ranking and hard-block logic inside the browser layer.
  • Preview event log only, not a persisted audit store.
  • White-label overlay positioning across sanitised tenants.

Planned direction

Read-first integration before any write-back claim.

  • Operational source access before deeper workflow automation.
  • Service-layer rule execution if the product progresses beyond the current demo.
  • Explicit override capture and event persistence later, not now.
  • Financial/admin pathways such as Xero and MYOB only if phase-2 discovery supports them.
Workflow fit

LiftIQ is intended to sit beside dispatch, workforce, and planning workflows.

It is not being framed as an isolated scoring toy. The product direction is to connect the operational decision layer to the systems already holding job, crew, site, and later financial context, while keeping the maturity claims disciplined.

Dispatch Ranked crew options, swap logic, late-change triage, and visible reasoning support.
Workforce Credential visibility, fatigue exposure, repeated over-allocation awareness, and clearer planner judgment.
Audit Preview event logic now. Persisted event capture only later if a controlled build path justifies it.
Finance Planned later alignment with systems such as Xero and MYOB for job-cost and labour-cost context, not current support.
Truth boundary: LiftIQ does not currently support live Xero or MYOB integration, payroll logic, invoice automation, or production-grade reporting. Those are possible later architecture pathways only if client system access and field mapping make them worth building.
Next step

Use the workflow story to qualify fit, then move to a controlled conversation.

If your operation already feels the pain of allocation pressure, late checks, and manual scramble, the strongest next move is a Dispatch Blind-Spot Review or a private design-partner briefing.

Dispatch diagnostic Executive briefing