EPISODICICCE

System Architecture

ICCE is multi-party operating infrastructure for temporary labour activity. Its system architecture provides the structural discipline through which participation, engagement activity, controlled employment, payroll, payment, evidence and stakeholder reporting remain connected without collapsing their responsibilities into one undifferentiated process.

The architecture is defined for national-scale operating conditions, including the ability to support tens of thousands of transactions per week across workers, agencies, contractors, buyers and other authorised participants. At that scale, reliability depends on more than application performance. It depends on deterministic processing, bounded responsibility, role-scoped access, attributable data lineage, consistent reconciliation and a controlled source of transaction evidence.

The operating philosophy beneath that architecture is deliberately simple: ICCE controls the route through which material activity is processed, captures the activity and outcomes produced inside that route as they occur, and preserves them as attributable evidence. In practical terms, the system controls the pipe, captures what passes through it and turns the resulting activity into evidence that authorised parties can inspect, reconcile and reuse.

This is the bridge between market requirements and market outcomes. Policy objectives, regulatory duties, commercial expectations and worker requirements enter ICCE as conditions to be respected; the system converts them into controlled behaviour, captures the resulting transaction and produces the evidence through which the outcome becomes visible, testable and reusable across the labour chain.

Control. Capture. Evidence.

Control the operating route. Capture the activity. Evidence the resulting transaction.

Three Levels of the ICCE System

ICCE is represented publicly through three connected architectural levels. They describe the same system at different resolutions: the underlying operations that perform control, the operating environments in which those controls are applied, and the stakeholder-facing capabilities produced by their combined operation.

Mechanics power → Components
Components combine to create → Cubes
Cubes generate → Market Outcomes

01

Mechanics

Reusable programmatic and rule-based operations validate, control, calculate, reconcile and preserve important activity across the system.

Explore Mechanics
02

Components

Distinct operating environments assemble Mechanics around defined responsibilities and create structured, attributable outputs for the wider system.

Explore Components
03

ICCE Cubes

Recognisable stakeholder-facing capabilities are produced when Mechanics and Components operate together across the same controlled transaction environment.

Explore Cubes

Market Outcomes

Transactional activity becomes visible as dependable worker outcomes, commercial utility, reusable transaction evidence, assurance and market-level insight.

System Mechanics

System Mechanics are the underlying control fabric of ICCE. They are the repeatable programmatic and rule-based operations through which information is received, checked, processed, calculated, transferred, reconciled and preserved. Their purpose is to make controlled activity behave consistently wherever the same requirement appears across the system.

Mechanics answer the lowest-level architectural question: how is controlled activity performed? Identity and permissions are tested before access is relied upon; engagement and time information is checked before downstream processing uses it; payroll is calculated from authoritative records through defined rules; payment activity follows verified outcomes; and evidence remains attributable to the source and operation that produced it.

The principal result is consistent behaviour, traceable outcomes and dependable inputs for the wider system. This is how policy, regulatory and operating requirements become repeatable system behaviour rather than participant-managed administration or local interpretation.

View System Mechanics
input → validation

External or system-created information is tested before dependent activity relies on it.

rules → outcome

Defined operations and calculations transform accepted information consistently.

outcome → evidence

The resulting record preserves attribution, context and the operation that produced it.

System Components

System Components are the operating environments in which principal responsibilities are separated and controlled. They take reusable Mechanics and organise them around distinct system responsibilities so that participation, financial readiness, engagement activity, payroll, payment and reporting do not become one shared pool of authority.

Components answer the architectural question where is responsibility applied? Each Component receives information relevant to its role, applies the controls required for that responsibility and produces structured outputs that remain connected to the wider engagement record. Receiving a record does not give the receiving environment authority to rewrite the source responsibility that created it.

The principal result is controlled progression, bounded processing and reliable outputs for downstream use. Components are where separation of concerns becomes operational across a multi-party system rather than remaining a design principle on paper.

View System Components
Receive

The Component accepts the information and context relevant to its defined responsibility.

Control

Relevant Mechanics apply permissions, readiness, processing or other system rules.

Produce

A structured and attributable result becomes available to the next permitted use of the record.

ICCE Cubes

ICCE Cubes are the stakeholder-facing capabilities created by the system beneath them. They translate the architecture into defined areas of value that workers, agencies, contractors, buyers and other authorised stakeholders can understand, discuss and use without needing to understand every underlying control operation or responsibility boundary.

Cubes answer the market-facing architectural question what usable capability does the system provide? A Cube may be driven primarily by one Component or depend on several Components and Mechanics working together. Its purpose is to expose a recognisable outcome - controlled participation, participant connectivity, employment, engagement control, payroll, payment, transaction evidence or intelligence - while leaving technical authority with the underlying system.

The principal result is visible stakeholder value and reusable assurance from the same controlled activity. This is where technical discipline becomes commercially legible: the system remains governed and separated internally while the resulting capability becomes understandable as something workers and organisations can rely upon.

Trusted participation

Controlled entry, participant identity, authorised supply activity and attributable engagement become visible to the market.

Worker-facing outcomes

Employment, engagement, pay and payment outcomes remain connected to the activity and evidence from which they were formed.

Commercial utility

The same architecture supports flexibility, project attribution, payroll operation and payment visibility without fragmenting the transaction.

Reusable market evidence

Stakeholder-specific views originate from connected controlled activity, strengthening assurance, reporting and decision-making.

View ICCE Cubes

Cube set

ICCE Onboarding
ICCE Playpit
ICCE Frameworks
ICCE Controlled Employment
ICCE Engagement Controls
ICCE Integrated Payroll
ICCE Trusted Payments
ICCE Transaction Evidence
ICCE Reporting & Intelligence

Transactional Truth & Market Outcomes

The most important output of the ICCE architecture is not any individual Mechanic, Component, Cube or report. It is transactional evidence created through controlled activity. ICCE controls the route through which the engagement is processed, captures the material participant and system activity produced inside that route, and preserves the resulting facts as one connected record.

Control, Capture and Evidence are therefore not separate reporting exercises. They are one operating principle. Control establishes the permitted route and the conditions applied to activity; capture records the actions, values, confirmations and outcomes created as that activity occurs; evidence preserves those captured facts with enough attribution and context for authorised parties to understand what happened and rely on the result.

The consequence is a shared factual position for activity processed through ICCE. Instead of workers, agencies, contractors, buyers and other authorised stakeholders depending on separate records assembled at different points in time, their relevant views are produced from the same controlled and captured transaction while preserving who created the information, how it was processed and what outcome followed.

A fully processed engagement produces more than 1,000 captured, calculated, derived and evidential data points. The value of that depth is the context it preserves: the system connects the people involved, the work performed, the employment and payroll treatment, payment outcomes, project context and evidence history within one attributable record. The transactional evidence is therefore an output of the operating model itself, capable of supporting employment, payroll, payment, compliance, procurement, worker-treatment and social-value views without creating separate versions of the underlying activity.

Control.Capture.Evidence.

The route is controlled. The activity is captured. The transaction becomes evidence.

The record is created because the activity itself has been controlled and captured, rather than assembled later for a report. Different authorised parties receive different views, but those views remain connected to the same underlying engagement, payroll, payment and evidence record.

Thousands of engagements.
One connected record.

1,000+

data points per engagement

Transaction Record Domains

Architecture groups the connected transaction record into six structural domains. These are not a second outcome taxonomy: they describe what kinds of information are formed and preserved. The standard evidence-led outcome areas are defined through the Transaction Core and are mapped back to the relevant record domains below.

Record domain Representative information formed Evidence-led outcomes supported
Participation & Identity Who is participating, in what capacity, and under which validated permissions.
Participation & Identity datapoints
01participant_identity02organisation03role04onboarding_evidence05access_position06permissions07attributable_actions
Fair Work, Good Jobs & Social ValueRegulatory & Audit AssuranceResponsible Procurement & Contract Performance
Engagement, Employment & Time The work context, employment record, working activity, challenge, correction and conclusion.
Engagement, Employment & Time datapoints
01engagement_context02work_information03employment_records04time_attendance05participant_interactions06worker_challenges07corrections08completion_evidence
Fair Work, Good Jobs & Social ValuePayroll & Tax ComplianceRegulatory & Audit AssuranceResponsible Procurement & Contract PerformanceCommercial & Operational Performance
Payroll & Statutory The financial and statutory consequence derived from verified engagement and time information.
Payroll & Statutory datapoints
01gross_pay02net_pay03PAYE04national_insurance05pensions06deductions_liabilities07payroll_artefacts08HMRC_records
Payroll & Tax ComplianceFair Work, Good Jobs & Social ValuePayment & Financial ClaimsRegulatory & Audit Assurance
Payment & Financial The obligation, payment activity, execution state and reconciliation evidence that follow payroll.
Payment & Financial datapoints
01payroll_linked_payment02execution_status03reconciliation_outcomes04payment_obligations05payment_evidence
Payment & Financial ClaimsFunding & Insurance EvidenceRegulatory & Audit AssuranceCommercial & Operational Performance
Project, Contract & Supply-Line Attribution The wider commercial, project and delivery context to which worker-level activity belongs.
Project, Contract & Supply-Line Attribution datapoints
01agency_context02engager_context03buyer_client_context04project_framework05contract_attribution06supply_line_context07location_context
Responsible Procurement & Contract PerformanceCommercial & Operational PerformanceAggregated Reporting & Market Insight
Evidence, Lineage & Exceptions The source, history, corrections, exceptions and reporting context needed to reuse and defend the record.
Evidence, Lineage & Exceptions datapoints
01source_attribution02timestamps03evidence_lineage04exception_records05correction_history06reporting_measures07worker_treatment08social_value_governance
Regulatory & Audit AssuranceFunding & Insurance EvidenceResponsible Procurement & Contract PerformancePayment & Financial ClaimsAggregated Reporting & Market Insight