ACCO Engineered SystemsDocument v0.1 · April 30, 2026Confidential · Pre-decisional
Dashboard mockups · aClaimant reporting platform
ACCO safety & risk reporting platform
A design document for the ACCO safety and risk reporting platform — presenting the fifteen Databricks SQL dashboards (seven operational reports plus eight business-unit scorecards) sourced from the acco_safety Unity Catalog gold layer with Risk and Safety access split through column-level masking, and comparing two ingestion patterns for getting source data into the platform.
Reports
7 operational
Scorecards
8 BU views
Ingestion patterns
2 options
Recommended timeline
16 weeks
Two ingestion patterns
Implementation approach
The platform is built on Databricks — medallion architecture under the acco_safety Unity Catalog, dashboards in DBSQL, Risk-Safety access split through column-level masking on the gold layer. The open question is how to ingest source data into Bronze. Two patterns are viable; the right choice depends on what the aClaimant demo confirms about their REST API.
Option 1
Hybrid · JDE direct + aClaimant REST
Two ingestion paths. JDE dimensions stream from Oracle through the existing GoldenGate Replicat directly into Bronze (skipping Copper because GG already produces typed CDC). aClaimant events come via the Snowflake REST API into Copper, then Bronze.
+JDE dims sourced from authoritative system — ACCO master data
+Real-time JDE updates via GG streaming — existing infrastructure
+No round-trip latency — dim changes hit Bronze in seconds
+Independent SLAs — aClaimant outage doesn’t freeze JDE dims
−Two ingestion paths to operate and monitor
−JDE schema changes handled separately from aClaimant entities
−Dimensional drift possible if aClaimant’s view diverges from JDE
−Higher build effort — two extraction patterns to test and operate
Recommended
Option 2
Single source · all via aClaimant REST
One ingestion path. Both events and dimensional mirrors of JDE data come through the aClaimant Snowflake REST API. Watermark-driven incremental pulls land 10 entities (6 events + 4 dim mirrors) into Copper, then Bronze.
+Single ingestion path — one SLA, one set of credentials, one operational story
+Single source of consistency — aClaimant’s view is authoritative
+Simpler joins — all silver keys originate from one system
+Faster to build — one extraction pattern, repeated 10 times
+Easier to extend — new aClaimant entities are additive
−Coupled SLA — aClaimant Snowflake down means all ingestion stops
−aClaimant must accurately mirror JDE — relies on existing Talend SFTP feed
−REST API rate limits and cost are operational concerns
Architecture · Option 1 · Hybrid
Two ingestion paths. JDE Oracle pushes through the existing GoldenGate Replicat directly into Bronze, skipping Copper because GG already produces typed CDC events. aClaimant events come through the DBX Snowflake REST API, landing first in Copper as raw JSON, then parsed into Bronze.
Option 1 · Hybrid · JDE GoldenGate + aClaimant REST
Architecture · Option 2 · Single source
One ingestion path. aClaimant’s Snowflake exposes both event entities and dimensional mirrors of the JDE data ACCO already pushes in via Talend. Watermark-driven incremental pulls bring all ten entities into Copper as raw JSON, then Bronze parses and types them.
Option 2 · Single source · all entities via aClaimant REST
Side-by-side comparison
Dimension
Option 1 · Hybrid
Option 2 · Single source (recommended)
Ingestion paths
Two — GoldenGate for JDE, REST for aClaimant
One — aClaimant Snowflake REST API only
JDE dim freshness
Real-time via GoldenGate streaming
Bound by aClaimant’s Talend sync (typically daily)
Authoritative source for dims
JDE (master)
aClaimant (mirror, fed by ACCO Talend SFTP)
SLA coupling
Independent — one path can fail without the other
Coupled — aClaimant Snowflake is the chokepoint
Operational complexity
Higher — two patterns, two monitoring stacks
Lower — one pattern, one stack
Build effort
Higher — two extraction patterns, dual-source testing
Lower — one pattern repeated across 10 entities
Reuse of existing infra
Yes — GoldenGate already in production for ACCO
Partial — REST is new, but pattern is standard
Incremental adoption
N/A — both paths needed from day one
Easy — can add Option 1’s GG path later if needed
Time to V1
Longer — estimated 18 weeks
Shorter — 16 weeks
Recommendation
Option 2 for V1, with Option 1 as a future addition
Single ingestion path means faster delivery and simpler operations. aClaimant’s dimensional mirrors are populated by ACCO’s existing Talend SFTP feed — the data is already there, and its quality is whatever ACCO is currently pushing. If JDE dim freshness becomes a real-world problem after launch, Option 1’s GoldenGate path is purely additive: keep aClaimant for events, switch dim sourcing to GG. The decision to start single-source is reversible. The decision to start with two ingestion paths is not.
Implementation phases
Sixteen weeks end-to-end for Option 2. Phases run sequentially with overlap on the last two — UAT can begin while distribution is being configured. Option 1 adds approximately two weeks for GoldenGate Replicat configuration in Phase 0 and dual-source reconciliation in Phase 1.
Phase 0
Foundation
Weeks 1 – 2
Unity Catalog set up, schema design signed off, REST API connectivity proven (one entity end-to-end). Watermark pattern locked. aClaimant API rate limits and auth confirmed from demo.
Phase 1
Bronze ingestion
Weeks 3 – 6
All ten aClaimant entities ingested into Copper, parsed into Bronze with schema enforcement and dedup. Daily watermarks running. Delta tables backfilled with history.
Phase 2
Silver conformance
Weeks 5 – 8
Dimensions conformed: employee map (FSM ↔ PT), insurance reference, project / company hierarchy. Cross-entity keys validated. Six facts modelled.
Phase 3
Gold and masking
Weeks 7 – 10
Fifteen Gold views built — seven reports, eight scorecards. Unity Catalog column-mask policies on Report_005 cost columns. Reconciliation against aClaimant native reports.
Phase 4
Dashboards and SSO
Weeks 11 – 14
DBSQL dashboards built. Azure AD federation tested, group-based entitlement (Risk vs Safety) confirmed end-to-end. Scheduled email distribution via DBSQL alerts.
Phase 5
UAT and cutover
Weeks 15 – 16
Risk and Safety sign-off. aClaimant native widgets retired. Documentation handover, runbook for the managed services team.
Part two
Functional requirements coverage
Every requirement in the BRD is mapped to a specific layer and component in the proposed Databricks implementation. Status reflects what the design covers today — Covered means design and source data are confirmed, Partial means design is sound but a scope question is open, Dependency means coverage is contingent on a vendor or business answer at the demo.
BRD ID
Requirement
DBX layer
Implementation approach
Status
Authentication and access
LOGIN_001
Login via Azure SSO
Workspace auth
Databricks workspace federated to ACCO Azure AD tenant. SCIM provisioning of users and groups; existing ACCO IdP unchanged.
Covered
LOGIN_002
Multi-factor authentication
Workspace auth
Inherited from Azure AD conditional access policy — no separate MFA required at the Databricks layer.
Covered
Data pipeline
DP_001
Real-time data availability
Bronze ingestion
GoldenGate streaming for JDE entities; hourly batch for aClaimant via REST or SFTP outbound. “Real-time” scope to be defined operationally at the demo — sub-hour vs. minutes vs. live.
Partial
DP_002
Data retention
All layers
Delta Lake retention policies per layer (Copper 7 yrs, Bronze 7 yrs, Silver/Gold 5 yrs). Time travel for reproducible reporting. Retention policy in Unity Catalog governance.
Covered
DP_003
Source system ingestion
Copper / Bronze
Two ingestion patterns under consideration. Option 1 (Hybrid): JDE via existing GoldenGate Replicat direct to Bronze (4 CDC tables) plus aClaimant events via Snowflake REST API into Copper. Option 2 (Single source, recommended): all 10 entities via aClaimant Snowflake REST API only — dim mirrors fed by ACCO’s existing Talend SFTP push. Decision tied to demo confirmation of REST API rate limits and dim-mirror freshness.
Dependency
Operational reports
REPORT_001
Hours and mileage
Gold
Single Gold view joining ServiceNow HCM Employee_History hours, JDE F570643 odometer, telematics mileage, and aClaimant exposure flags. Calculated TRIR / DART / LTIR.
Covered
REPORT_002
Property damage
Gold
Gold view from aClaimant property-damage entity, joined to project and cost dimensions. Cause taxonomy normalised in Silver.
Covered
REPORT_003
By company / project — injuries, department, audits
Gold
Three-pane Gold view. Injuries and department from aClaimant; audits source unconfirmed — may be a separate ACCO system rather than aClaimant. To resolve at demo.
Dependency
REPORT_004
Reportable injuries (OSHA)
Gold
OSHA classification logic (First Aid / Recordable / Report Only) implemented as Gold-layer SQL with twelve-month rolling TRIR trend. Generates OSHA 300 / 300A / 301 export views.
Covered
REPORT_005
Cost of injuries
Gold + UC
Single Gold view exposing claim, medical, indemnity, reserve, paid. Unity Catalog column-mask policy on cost columns for SAFETY group; RISK group sees full detail. The architectural differentiator.
Covered
REPORT_006
Auto accidents (cost)
Gold
Auto-accident entity from aClaimant joined to dim_insurance_policy reference (productised from existing Talend hard-coded values), vehicle dimension, driver mapping.
Covered
REPORT_007
Department by property damage
Gold
Property-damage entity rolled up to department dimension, segmented by cause taxonomy. Heatmap and stacked-bar views.
Covered
Business unit scorecards
SCORECARD_01..07
BU scorecards (Co rollup, AZ, NR, SR, SBC, Smith MEP, Service)
Gold
Single parameterised Gold view filtered by business-unit code. TRIR, DART, LTIR, severity, auto rate against per-BU targets with traffic-light status.
Covered
SCORECARD_08
Statistics detail
Gold
Same Gold view as the BU scorecards with no aggregation filter — numerator, denominator, formula, result, target, status visible per metric. Auditable trail behind the headline rates.
Covered
Of the twenty BRD requirements, sixteen are Covered outright by the design; one is Partial pending an operational definition of “real-time”; three are Dependency — the aClaimant extraction interface, the audit data source for Report_003, and the source feed catalogue itself. All three open items are demo-day questions, captured below.
7 reports
Operational reports
REPORT_001
Hours and mileage
YTD 2026All companiesAll projects
Hours worked
3,247,102
+4.2% vs prior YTD
Miles driven
14.2M
+1.8% vs prior YTD
TRIR
1.18
−0.14 vs prior
DART
0.84
−0.06 vs prior
Source note · hours from ServiceNow HCM Employee_History; mileage from JDE F570643 odometer plus telematics. Not from aClaimant. Open question for the demo: does aClaimant expect ACCO to feed exposure hours back in, or do they capture them?
REPORT_002
Property damage
YTD 2026All causes
PD events
47
+6 vs prior YTD
Open events
11
23% of total
Total est. cost
$487K
$10.4K avg
Avg days to close
21
−4 vs prior
REPORT_003
By company and project — injuries, department, audits
YTD 2026All companies
Injuries
54
across 28 projects
Departments hit
12
of 14 total
Active audits
43
87 findings open
Critical findings
9
+3 vs prior
Open question · audit data source not yet confirmed — may live outside aClaimant. Mockup assumes a future audits feed into Bronze. Confirm with the aClaimant demo team whether audits are a captured module or a separate ACCO tool.
REPORT_004
Reportable injuries — first aid / recordable / report only
Trailing 12 monthsOSHA 300-aligned
First aid
32
non-recordable
Recordable
14
OSHA 300 entries
Report only
8
no medical / no time
TRIR
1.18
target ≤ 1.00
Why this beats the aClaimant UI · aClaimant cannot cleanly produce the OSHA 300 / 300A / 301 decomposition that feeds TRIR, DART, and LTIR. This view does — with auditable lineage from the gold view back to source incident records.
REPORT_005
Cost of injuries
YTD 2026All companies
Single gold view, two access policies. Unity Catalog column-level masking enforces the Risk-Safety split at the catalog — one pipeline, no duplication. This is the one thing the current aClaimant UI cannot do.
Risk viewfull detail
Claim
Medical
Indemnity
Reserve
CL-26-0142
$48,200
$197,400
$60,000
CL-26-0119
$12,800
$8,400
$15,000
CL-26-0098
$31,500
$0
$25,000
CL-26-0073
$6,200
$0
$5,000
CL-26-0051
$94,100
$142,800
$80,000
Safety viewaggregated
Claim
Medical
Indemnity
Total
CL-26-0142
•••••
•••••
$305,600
CL-26-0119
•••••
•••••
$36,200
CL-26-0098
•••••
•••••
$56,500
CL-26-0073
•••••
•••••
$11,200
CL-26-0051
•••••
•••••
$316,900
REPORT_006
Auto accidents — cost
YTD 2026Fleet
Auto accidents
34
19 at-fault
Total cost
$412K
incl. reserves
Cost / MM miles
$29K
−12% vs prior
Avg / accident
$12.1K
PD + BI combined
Source note · insurance carrier and policy resolved at runtime from a dim_insurance_policy reference table. Today these are hard-coded constants inside the Talend JDE_TO_ACCO_VEHICLE job — when a policy renews, it’s a code change. Productizing this is a small ticket but a real one.
Target ≤ 1.00 · industry median 2.7 · prior year 1.32
DART
0.84
target ≤ 0.90
LTIR
0.43
target ≤ 0.50
Severity rate
12.4
target ≤ 10.0
Auto rate / MM mi
2.39
target ≤ 3.00
Why this matters · the BRD calls out a Statistics detail view as a separate scorecard. It’s the auditable trail behind the headline rates — what Risk and external auditors will ask for first. Same gold view as the BU scorecards, just no aggregation filter.
CROSS-BU VIEW
All business units at a glance — TRIR
Trailing 12 mo
Co rollup
1.18
above
AZ
0.92
below
NR Const
1.34
above
SR Const
1.41
above
SBC
0.87
below
Smith MEP
1.05
near
Service
0.62
below
Mockups · pre-decisional · not actual ACCO dataBuilt by RatnaGlobalTech · April 30, 2026