PayComp STACK Intelligence Platform

What Each Letter Means

STACK In Practice

One framework, two views. See what STACK means for the business — or open the Developer Guide to see exactly where each task belongs.

Signal

Trusted Intake & Auth

Everything that happens before we touch the data — receiving a payroll file, confirming who sent it, and making sure it arrived intact and from a trusted source.

When Automated

Files arrive, get authenticated, and enter the pipeline — no human needed in the loop.

Transform

Normalization & Formatting

Converting raw payroll data into the exact format each carrier requires — a universal translator between payroll systems and insurance carriers. Templates are learned and reused.

When Automated

Any carrier gets data exactly how they want it. No manual reformatting, no spreadsheet work.

Assess

Intelligence & Decision Logic

Where the intelligence lives. Anomaly scoring, routing decisions, eligibility logic, and business rules — the system "thinks" here so your team doesn't have to.

When Automated

Problems are caught before they cause rejections. Smart decisions happen without analyst intervention.

Check

Compliance Validation

Validating everything against carrier-specific rules and SOPs before anything goes out the door. Smart rules learn from every exception to prevent future errors.

When Automated

A submission either passes or triggers a targeted fix request. No manual review of clean records.

Keys

Delivery & Handoff

Handing over the keys — final delivery of validated reports to carriers, with confirmation receipts and retry logic built in. Human involvement only when something needs attention.

When Automated

Carriers receive submissions directly, on time, with proof of delivery. Your team is notified only on exceptions.

Signal — Trusted Intake & Auth

Tag S if the task's primary output is authenticated, logged data arriving into the system

▼

The Rule

Tag S if the task's primary purpose is receiving, authenticating, or ingesting data from an external source — and the primary output is that data now being inside the system in a trusted, logged state.

Not S if: the task is changing the shape or format of data (→ T), or making a decision about it (→ A). Receiving ≠ reformatting. Authentication is S; if the task's job is confirming a trusted source, tag S regardless of the tech involved.

Real Examples

Parsing Engine

PDF, CSV, XLS, ZIP file intake from payroll provider exports

Receiving the file is the output

Parsing Engine

File format validation on arrival — is it readable and complete?

Confirming a valid signal arrived

ATLAS

User login, JWT auth, SSO token validation

Authentication = trusted intake

Relay

ACH payment instruction receipt + bank auth handshake

Payment signal arrives and is verified

CompConnect

Broker/agency auth + referral intake form submission

Receiving a trusted referral signal

Transform — Normalization & Formatting

Tag T if the task's primary output is data in a new format, structure, or shape

▼

The Rule

Tag T if the task's primary purpose is converting, normalizing, or reshaping data — and the primary output is that same data in a new structure or carrier-specific format.

Not T if: the task is receiving the data (→ S) or making a decision about it (→ A). Converting data ≠ deciding something about it. Mapping fields and building templates → T. Scoring or routing based on what's in those fields → A.

Real Examples

Parsing Engine

Payroll field → carrier format mapping & template engine (14 carriers)

Output is reformatted data

Parsing Engine

Multi-tab XLS normalization into a flat record structure

Reshaping the data structure

ATLAS

Raw platform events → structured KPI metrics for dashboard

Events become formatted display data

Relay

Bank transaction record → normalized ACH payment object

Raw data → standard internal format

CompConnect

Quote data → bind-ready carrier submission packet

Reformatted for carrier requirements

Assess — Intelligence & Decision Logic

Tag A if the task scores, classifies, routes, or applies business logic to data

▼

The Rule

Tag A if the task's primary purpose is making a decision, scoring something, or applying business logic — and the primary output is a score, classification, route, or automated action based on that intelligence.

Not A if: the task is reformatting data without deciding anything (→ T), or checking data against a specific written checklist or ruleset (→ C). The test: is the system exercising judgment? If yes → A. If it's just matching against a known standard → C.

Real Examples

Parsing Engine

AI anomaly detection — flagging unusual or suspicious payroll values

Scoring / classifying data

Parsing Engine

Exception routing — deciding what goes to human review vs. auto-proceed

Routing decision = Assess

ATLAS

STACK score calculation per product and phase

Scoring logic lives in Assess

Relay

Payment rail selection + retry logic (which bank, which timing)

Routing decision = Assess

CompConnect

Carrier eligibility scoring + bind recommendation engine

Scoring + decision = Assess

Check — Compliance Validation

Tag C if the task validates data against a specific rule, standard, or SOP

▼

The Rule

Tag C if the task's primary purpose is validating output against a known rule, standard, SOP, or compliance requirement — and the primary output is a pass/fail result with specific error details.

Not C if: the task is making an AI or business-logic decision (→ A). The test: is the rule written down somewhere? If there's a spec, a checklist, or a carrier SOP — it's C. If the system is exercising judgment about ambiguous data → A.

Real Examples

Parsing Engine

Carrier SOP ruleset validation — field formats, required values, data ranges

Checking against written carrier rules

Parsing Engine

Required field completeness check — are all fields present and non-null?

Validating against a defined standard

ATLAS

Data integrity checks before dashboard render (no nulls, valid ranges)

Checking correctness before output

Relay

Pre-flight NACHA compliance check on ACH file before transmission

Validating against NACHA spec

CompConnect

Carrier bind requirements checklist — all required docs and signatures present?

Checklist = Check

Keys — Delivery & Handoff

Tag K if the task delivers a final output to an external party or crosses the system boundary

▼

The Rule

Tag K if the task's primary purpose is delivering a final output to an external system, carrier, or client — and the primary output is confirmation that delivery happened (a receipt, response, or delivery notification).

Not K if: the task is verifying the output is ready to send (→ C). The test: does this task cross the boundary out of our system? If yes → K. Sending → K. Making sure it's correct before sending → C.

Real Examples

Parsing Engine

Electronic submission to carrier portal + delivery receipt logging

Crosses the system boundary

Parsing Engine

Failed submission retry logic + re-delivery confirmation

Still the delivery step

ATLAS

Client dashboard publish + scheduled report delivery to client

Final output delivered to client

Relay

ACH file transmission to bank + settlement confirmation handling

Crossing the boundary to the bank

CompConnect

Bind confirmation sent to carrier and broker simultaneously

Keys handed to both parties

AUTOMATION MATURITY OVERVIEW

Click any relationship to see who's working on it, bottlenecks, and notes.

View All Relationships →

STACK Automation Score — What Each Level Means

▼

No Automation

Entirely human-controlled

1–20%

Minimal Assistance

Human-driven with small Parsing Engine assistance

21–40%

Assisted Workflow

Parsing Engine performs some structured tasks

41–60%

Guided Automation

Parsing Engine handles most ops with oversight

61–80%

High Automation

Human involvement is rare

81–100%

Full Autonomy

Parsing Engine fully controls the phase

Payroll Provider	Carrier	ETA	Automation
ADP ADP Run	🏦 AmTrust	Jan '27	32%automated↑ trending up	▼
Bottleneck ▼ A · C blocking Keys Who's On It ML Marcus L. Working on Assess (A) phase Est. done Sep 2026 Notes Carrier template requires manual review. A + C phases need automation rules built out before Keys can be unlocked.
AS Asure	🏢 AmTrust	Sep '26	56%automated↑ trending up	▼
Bottleneck ▼ K — final mile gap Who's On It TR Taylor R. Working on Keys (K) phase Est. done Aug 2026 Notes Strong relationship — all phases at 3. Final Keys automation depends on carrier API access confirmation from AmTrust tech team.
AS Asure	🏛️ The Hartford	Jan '27	32%automated→ holding	▼
Bottleneck ▼ A · C blocking Keys Who's On It JK Jordan K. Working on Assess (A) phase Est. done Oct 2026 Notes Hartford requires specific data field ordering. Check phase dependent on Assess completion — both need to move together.
QB QuickBooks Online	🏦 AmTrust	Jan '27	32%automated→ holding	▼
Bottleneck ▼ A · C blocking Keys Who's On It SR Sam R. Working on Check (C) phase Est. done Nov 2026 Notes QB export format is inconsistent month-to-month. Assess rules need training data before Check can be reliably automated.
SE Serendipity	🏦 AmTrust	Jul '27	8%automated→ holding	▼
Bottleneck ▼ T · A · C — no automation Who's On It AL Alex L. Working on Transform (T) phase Est. done Mar 2027 Notes Non-standard payroll format. Requires custom Parsing Engine template build. Priority: T phase first, then A and C can follow.
SR Self-Reporting	🏢 Employers	Nov '27	4%automated→ holding	▼
Bottleneck ▼ S · T · A · C — fully manual Who's On It DW Dana W. Working on Signal (S) phase Est. done May 2027 Notes Fully manual today. Client self-reports directly. First milestone: get data into Parsing Engine intake. Signal phase is the priority unlock.
EB eBacon	🏗️ ICW Group	Jul '27	8%automated↑ trending up	▼
Bottleneck ▼ T · A · C — no automation Who's On It CP Chris P. Working on Transform (T) phase Est. done Feb 2027 Notes eBacon is a prevailing wage platform — data structure is complex. ICW has unique submission requirements. T phase template build in progress.
TO Toast	🏛️ Travelers	Jan '27	32%automated↑ trending up	▼
Bottleneck ▼ A · C blocking Keys Who's On It BN Blake N. Working on Assess (A) phase Est. done Oct 2026 Notes Toast restaurant payroll is high-volume. Travelers template is mapped but Assess rules need refinement for tip-credit pay types.

Explore All 51 Relationships →

Measure.Automate.Scale.

STACK In Practice

AUTOMATION MATURITY OVERVIEW

Measure.
Automate.
Scale.