TDS Copilot — autonomous shift-to-cash orchestration
TDS Copilot is a multi-tenant orchestration layer that carries a security shift request from the moment it lands in an operations inbox to the moment the resulting invoice is paid. This site is the technical specification. It is intended to be read end-to-end by engineers before estimating.
What the system does, in one pass
A shift request arrives as unstructured email. Copilot classifies and extracts it, resolves the customer and site, writes the shift to the platform of record, screens the guard pool against licence and fatigue rules, cascades an offer across WhatsApp/email/push, locks the acceptance, replies to the client on the original thread, raises the purchase order, watches the guard clock on and off, reconciles the timesheet against three independent records, issues the invoice, and reports the whole position on one dashboard.
Three constraints that shape every design decision
Resequencing rationale
The original thirteen-step brief did not flow in six places, and one step could not run as sequenced at all. Every original step is mapped below to its position in the corrected model. Engineers should read this before the workflow map, because several segments will look out of order against the brief they may have seen.
| Orig. | Now | Step | Rationale for the change |
|---|
Workflow map — eleven segments
S0 runs once per tenant at onboarding. S1–S9 are the operational spine and run once per shift. S10 observes continuously. Select any segment to open its full specification: trigger, owning agent, core logic in implementation order, human checkpoint, exit criteria (the acceptance test) and primary failure mode.
Agents & orchestration
One deterministic orchestrator and eleven specialist agents. The Type column is the contract: anything marked deterministic must contain no model inference, and this should be enforced in code review.
| ID | Agent | Type | Responsibility |
|---|
Orchestration principles — non-negotiable
Human checkpoints
Nine checkpoints. Build them as a single approval queue — not notifications scattered across email and chat. Every item must present the decision, the evidence, the recommended action and the dollar impact on one screen.
| ID | Checkpoint | Owner | Frequency | Applies |
|---|
Checkpoint service requirements
- One-click approve; one-click reject with a reason code; and an edit-then-approve path. Reason codes are training data — store them structured.
- Ageing and escalation on a timer that shortens as the shift start approaches.
- Delegation and out-of-hours cover. Shift requests do not respect business hours.
- Full audit: who approved, when, what they saw, and what they changed.
Compliance & fatigue rules engine
Deterministic, versioned, unit-tested to full branch coverage, independent of any language model. It answers one question — may this guard lawfully and profitably work this shift — and must explain its answer in plain English to an operations manager, a client, or a Fair Work inspector.
| ID | Rule | Test | Action | Note |
|---|
Implementation requirements
- Write this component test-first. It is the one place where expected outputs can genuinely be written before the code, because the award states them.
- Rates and hours are never inferred. Every figure comes from a versioned rate card or an encoded award rule with an effective date.
- When the award varies, load a new rule version with a start date. Historical shifts continue to evaluate against the rules that applied when they were worked.
- Licence status is verified same-day against the registry or the platform's compliance module — never read from a cached profile field.
Integration architecture
Every external system sits behind a versioned adapter implementing a common contract. No agent calls a vendor API directly. This is what makes the product multi-platform rather than a Guardhouse add-on, and what allows a file-based integration today to become an API integration later without touching the orchestration layer.
Adapter contract — every platform adapter must implement all of this
| Capability | Operations |
|---|
Platform-by-platform assessment
| System | Role | Documented position | Design response | Risk |
|---|
Integration risk posture
- Contract tests against every adapter run in CI. A vendor silently changing a field is a foreseeable event, not an incident.
- Every adapter degrades explicitly. If a platform is unreachable, the shift is queued and flagged — never silently dropped, never assumed successful.
- Where an integration is file-based, the reconciliation job is mandatory: export, re-import, compare on a schedule, surface every divergence.
- Rate limits and quotas modelled per tenant, so a large tenant's sync cannot starve a small one's.
Core data model
Every entity is tenant-scoped at the data layer, not by application logic. TDS Copilot is sold to firms that compete with one another, so a single missing filter in application code would be a cross-tenant breach.
| Entity | Purpose | Key relationships |
|---|
Accuracy & assurance framework
The business target is 100% accuracy before later stages proceed. To be manageable that has to be measurable per segment and per field, with three distinct outcomes: correct, abstained, and wrong. Abstention is a success. Only the third category is a defect, and it is the only one that should ever be traded against throughput.
| Mechanism | What it does | Why it is non-negotiable |
|---|
Security & multi-tenancy
The security posture is a commercial requirement, not an engineering preference. It will be examined in every enterprise and government-adjacent procurement we enter.
Command dashboard (S10)
Mock-up of the target layout. Every operational number carries its dollar value — a count of unfilled shifts prompts a shrug, the revenue at risk prompts an action. Every metric must drill through to the underlying record and its audit trail. All figures below are illustrative; no live data is used.
Straight-through processing by segment
Guards right now
Timesheet exceptions awaiting resolution (CP7)
| Shift | Site | Reason | Variance | Impact | Age |
|---|
Compliance watch
| Item | Count | Status |
|---|---|---|
| Licences expiring within 30 days | 4 | Action |
| Fatigue breaches prevented this fortnight | 11 | Working |
| Overtime exposure vs budget | +6% | Watch |
| Award overrides (CP8) this month | 1 | Review |
| Site clearances lapsing | 0 | Clear |
Delivery phases & team
Autonomy is never switched on ahead of the accuracy evidence. Shadow mode comes first and every exit gate is measurable. Phase 0 is not paperwork — it removes the two risks that can stop the product.
| Phase | Timing | Focus | Content | Exit gate |
|---|
Team shape — approximately eight FTE at peak
| Role | FTE | Why |
|---|
Risk register
| ID | Risk | Description | Likely | Impact | Mitigation |
|---|
Open questions — answers needed before estimating
These are the unknowns that currently prevent a defensible estimate. Please review and add your own via the review channel rather than assuming an answer.
| ID | Area | Question | What it blocks |
|---|
Documents & sources
Companion artefacts. Place them in the same directory as this file for the links to resolve.
Sources verified 9 August 2026
noindex, nofollow. Because the content is commercially sensitive, it should sit behind authentication (HTTP basic auth at minimum, SSO preferred) on a non-guessable path, served over HTTPS only, and not on a publicly indexed subdomain.