Workhuman Contract and Fixture CI

Overview

Turn customer-authorized Workhuman behavior into deterministic, secret-free merge gates and isolate any live tenant probe behind trusted approval.

Prerequisites

• A pinned contract or mapping digest, typed adapter, and sanitized synthetic fixtures
• CI threat model covering forks, artifacts, logs, caches, and secret exposure
• Named owners for tenant access, contract updates, failures, and live-test approval

Tool Discipline

Use Read, Glob, and Grep to inspect workflows and test assets, WebFetch to re-check authoritative context, and Write or Edit for CI, tests, fixtures, and redacted receipts.

Current Contract

Workhuman publicly confirms open-API and managed-integration capabilities without publishing universal routes or schemas. CI must pin the customer's authorized artifacts and fail on drift rather than embedding assumptions from the former pack.

Authentication

Default pull-request jobs receive no Workhuman secrets. A live check may use only an approved non-production principal in a protected environment with host allowlisting and no untrusted code execution.

Instructions

1. Pin contract, mapping, fixture, and adapter digests and document their owners and review dates.
2. Add secretless gates for schema validity, generated-code drift, type checks, unit tests, contract tests, Unicode, and secret scanning.
3. Cover read, valid-empty, invalid, duplicate, timeout, throttling, partial, drift, and ambiguous-write behavior with synthetic fixtures.
4. Assert that tests deny network by default and that fixtures contain no workforce, recognition, reward, financial, or credential data.
5. Separate required deterministic checks from an optional trusted live lane.
6. Gate the live lane on explicit approval, non-production tenant, synthetic identity, allowlisted host, bounded read-only operation, and cleanup.
7. Redact logs and artifacts; retain only version, digest, safe status, timing, counts, and correlation evidence.
8. Make contract or fixture drift fail with an owner and regeneration instruction.

Approval Boundaries

Do not expose secrets to forks, run customer writes, upload private contracts as public artifacts, or make provider-dependent live tests required without a governed exception.

Output

Return the gate graph, pinned digests, fixture safety proof, required test result, live-lane controls, redaction evidence, failure ownership, and CI receipt.

Error Handling

Workhuman Failure Triage

Overview

Classify failures by evidence and authoritative system before changing configuration or retrying potentially consequential recognition and award operations.

Prerequisites

• Failure time, tenant, actor or principal class, operation, environment, and safe correlation identifier
• Current tenant contract, program rules, field authority map, and recent change history
• Owners for identity, HCM, recognition, payroll, security, and vendor support

Tool Discipline

Use Read, Glob, and Grep for sanitized logs and configuration, WebFetch for current first-party context, and Write or Edit only for redacted timelines, hypotheses, fixtures, and approved repairs.

Current Contract

Workhuman spans customer identity, workforce data, recognition policy, award approval and spend, Store redemption, reporting, and managed integrations. A visible symptom can originate in another authority; public pages do not define a universal HTTP error map.

Authentication

Confirm which principal failed and whether its authorization applies to the tenant, environment, data direction, and operation. Never test by borrowing a more privileged user session.

Instructions

1. Freeze the timeline, impact, last known success, recent changes, and whether any write may have partially applied.
2. Sanitize evidence while preserving status, safe error class, correlation identifier, timestamps, and contract version.
3. Classify the failure as identity, entitlement, worker authority, eligibility, approval, spend, financial handling, schema, capacity, delivery, reporting, redemption, or vendor service.
4. Compare actual behavior with the current authorized contract and customer program configuration.
5. Reproduce with a synthetic fixture in the smallest non-production scope; do not replay an ambiguous write.
6. Test one hypothesis at a time and name the system and owner authorized to resolve it.
7. Present the repair, affected records, risk, verification, rollback, and approval boundary.
8. After approval, apply the narrow repair and reconcile both expected and actual state.

Approval Boundaries

Do not change SSO, privileges, workers, recognition policy, awards, balances, payroll mappings, integrations, or production records during diagnosis.

Output

Return the sanitized timeline, classification, contract evidence, reproduction result, root cause or ranked hypotheses, repair preview, approver, and reconciliation receipt.

Error Handling

Governed Workhuman Recognition Workflow

Overview

Turn approved recognition policy into a controlled nomination or program change with eligibility, award, privacy, spend, and reconciliation evidence.

Prerequisites

• Program rules, eligible population, company values, award policy, approvers, and budget owner
• Current tenant documentation for the supported user or integration path
• A synthetic pilot cohort, communication owner, support path, and rollback plan

Tool Discipline

Use Read, Glob, and Grep to inspect policy and rosters, WebFetch to verify current Workhuman and tenant contracts, and Write or Edit for plans, fixtures, previews, and redacted receipts.

Current Contract

Workhuman Social Recognition supports recognition connected to company values, while Admin Hub supports award management, delegate assignment, spend control and monitoring, program analysis, alerts, recommendations, and misuse detection. Exact award structures and workflow states are customer-configured.

Authentication

Use the documented end-user, administrator, managed-integration, or API principal for each step. Do not make a service principal impersonate a nominator unless the authorized contract explicitly permits it.

Instructions

1. Freeze purpose, eligible nominators and recipients, exclusions, value taxonomy, award policy, approvals, visibility, locales, and measurement.
2. Reconcile the eligible audience with its authoritative HCM source and quantify duplicates, inactive workers, and unresolved identities.
3. Confirm the current customer configuration and exact supported submission path; never infer award levels or payload fields.
4. Validate message policy, sensitive-data exclusions, accessibility, taxation ownership, spend controls, and misuse rules.
5. Pilot with synthetic or approved users and verify nomination, approval, notification, ledger, reporting, and cancellation behavior.
6. Present exact mutations, counts, spend exposure, approvers, schedule, communications, rollback, and support ownership.
7. After approval, execute through the supported path with idempotency or duplicate controls and bounded concurrency.
8. Reconcile expected nominations, approvals, awards, spend, and exceptions; retain a redacted receipt.

Approval Boundaries

Do not nominate people, approve awards, change eligibility, alter award values, send communications, or spend program funds without named approval.

Output

Return the frozen policy, audience reconciliation, contract evidence, pilot result, mutation preview, approvals, execution receipt, exceptions, and rollback status.

Error Handling

Workhuman and Workday Integration Reconciliation

Overview

Operate the certified bidirectional integration with a field-level authority map, privacy controls, deterministic reconciliation, and owned exception handling.

Prerequisites

• Current Workhuman-Workday implementation documentation and configured integration inventory
• HCM, payroll, security, privacy, and recognition-program owners
• Field mappings, schedules, populations, tax and gross-up rules, and recovery objectives

Tool Discipline

Use Read, Glob, and Grep to inspect mappings and reports, WebFetch to re-check first-party integration claims, and Write or Edit for reconciliation logic, fixtures, and redacted receipts.

Current Contract

Workhuman publicly states that its certified, prebuilt, bidirectional Workday integration treats Workday as the system of record for foundational and organizational worker data and Workhuman as the recognition and rewards system. Public pages also describe award data flowing to Workday compensation, payroll, and talent use cases.

Authentication

Use the customer-approved managed-integration principals and Workday security groups. Keep each direction least-privileged, separately owned, rotated, and observable.

Instructions

1. Freeze each direction, population, field, authority, transformation, cadence, checkpoint, and downstream use.
2. Classify worker, organization, recognition, award, compensation, payroll, and talent fields by privacy and retention.
3. Validate effective dating, worker identifiers, rehires, terminations, contingent workers, locales, currency, taxation, and gross-up ownership.
4. Produce synthetic fixtures for creates, changes, removals, duplicates, late records, partial batches, and rejected values.
5. Run a dry comparison and report additions, updates, exclusions, conflicts, and unknown mappings without applying them.
6. Present the mutation window, exact counts, principals, financial exposure, communications, abort thresholds, and rollback.
7. After all owners approve, canary one bounded cohort and reconcile both systems before broadening.
8. Preserve checkpoint and redacted exception evidence; route payroll or tax mismatches to their owners rather than auto-correcting.

Approval Boundaries

Do not change worker records, award data, compensation, payroll inputs, tax handling, mappings, schedules, or integration principals without the respective owners.

Output

Return the authority map, classified mappings, dry-run counts, approvals, canary receipt, bidirectional reconciliation, held exceptions, and recovery state.

Error Handling

Workhuman Cost and Recognition-Budget Governance

Overview

Build a dated cost and value model that separates contract charges, recognition awards, redemption effects, services, and customer-operated integration costs.

Prerequisites

• Current order form, invoices, program budget, award ledger, redemption reporting, and implementation or support statements
• Eligible population, participation and outcome definitions, finance policy, and program owner
• Data classification and approved aggregation thresholds for workforce analysis

Tool Discipline

Use Read, Glob, and Grep to inspect approved financial and operational evidence, WebFetch for current public context, and Write or Edit for models, scenarios, and redacted decision records.

Current Contract

Workhuman publicly describes active spend monitoring and control in Admin Hub and a points-based global Store. Public pages do not provide universal customer pricing or prove that one API call, award, point, or redemption has a fixed cost; use customer contract and ledger evidence.

Authentication

Use read-only authorized exports or reports for analysis. Separate financial, program, and technical access and never expose individual compensation, award, balance, or redemption details in broad reports.

Instructions

1. Freeze the review window, population, currencies, budget basis, contract date, and owners.
2. Reconcile invoices and commitments with recognition awards, active spend, redemption or liability reporting, services, taxes, and customer infrastructure.
3. Normalize currencies and time periods while preserving source, effective date, and accounting treatment.
4. Calculate participation, recognition reach, manager and peer distribution, award mix, redemption experience, operational effort, and approved outcome measures.
5. Detect overspend, underspend, concentration, inequity, dormant entitlements, duplicate services, failed jobs, and support-heavy workflows without exposing individuals.
6. Model bounded scenarios with assumptions, confidence, financial impact, cultural or equity risk, and reversibility.
7. Present policy, budget, eligibility, contract, or architecture changes to finance, HR, procurement, privacy, and program owners.
8. After approval, canary reversible changes and compare spend, participation, equity, support, and business outcomes.

Approval Boundaries

Do not change budgets, award values, eligibility, redemption policy, licenses, contracts, or workforce communications without accountable owners.

Output

Return the reconciled baseline, dated sources, allocation and value metrics, anomalies, scenarios, assumptions, approvals, canary result, and review date.

Error Handling

Privacy-Safe Workhuman Support Bundle

Overview

Create the minimum reproducible evidence package needed by customer teams or Workhuman support without exposing workforce data, messages, awards, balances, or credentials.

Prerequisites

• Incident identifier, bounded time window, tenant and environment, symptom, severity, and support owner
• Customer classification, retention, disclosure, and legal requirements
• Current contract or connector documentation and an approved sharing channel

Tool Discipline

Use Read, Glob, and Grep for local evidence discovery, WebFetch to verify current vendor context, and Write or Edit only inside an access-controlled redacted bundle.

Current Contract

Workhuman processes workforce, recognition, reward, and integration data and publishes privacy and security commitments. Support evidence must follow the customer's agreement and support process; public pages do not authorize unrestricted log or payload sharing.

Authentication

Do not collect credentials, authorization headers, session cookies, client secrets, signed URLs, or reusable tokens. Hash or truncate identifiers only when the receiving owner confirms that they remain useful.

Instructions

1. Define the diagnostic question, audience, time window, allowed data classes, retention, and deletion owner.
2. Inventory candidate logs, configuration, contract fingerprints, deployment history, connector runs, reports, and safe correlation fields.
3. Exclude names, recognition messages, employment details, balances, addresses, financial data, secrets, raw payloads, and unrelated tenants.
4. Create a UTC timeline containing expected behavior, actual behavior, last success, first failure, changes, retries, and partial effects.
5. Include secretless topology, environment and version identifiers, schema digests, counts, sanitized statuses, and synthetic reproduction steps.
6. Run pattern and manual redaction review; record excluded classes and the reviewer.
7. Package a manifest with hashes, purpose, audience, expiry, and approved transfer channel.
8. Obtain disclosure approval before sending and record receipt and deletion expectations.

Approval Boundaries

Do not query extra personal data, widen the incident window, decrypt archives, or send the bundle outside approved channels without privacy and support-owner approval.

Output

Return the redacted timeline, safe configuration and topology, reproduction, schema and correlation evidence, manifest hashes, redaction proof, approvers, expiry, and transfer receipt.

Error Handling

Workhuman Integration Deployment

Overview

Release an exact reviewed adapter or managed-connector configuration without confusing code deployment with authorization to change customer data or programs.

Prerequisites

• An immutable release and passing workhuman-prod-checklist decision
• Current tenant contract, secretless configuration, principals, topology, and field authority map
• Canary, observability, reconciliation, abort, rollback, communications, and support plans

Tool Discipline

Use Read, Glob, and Grep to verify release artifacts, WebFetch for current vendor context, and Write or Edit only for deployment configuration, manifests, and redacted receipts.

Current Contract

Workhuman offers managed integrations for workplace and HCM systems plus an open API. The customer contract determines whether the deployable unit is customer code, vendor configuration, or both; no public generic deployment endpoint should be assumed.

Authentication

Bind runtime principals to one tenant, environment, direction, and approved capability. Acquire secrets from the approved store at runtime and verify rotation and revocation before cutover.

Instructions

1. Verify the release identifier, approvals, contract digest, image or package digest, configuration digest, and dependency versions.
2. Diff current and target topology, principals, hosts, mappings, schedules, data classes, observability, and network policy.
3. Produce a mutation preview with exact services, tenant settings, records at risk, financial exposure, and expected downtime.
4. Rehearse deployment, disablement, rollback, checkpoint recovery, and reconciliation in a safe environment.
5. Confirm canary cohort, traffic or schedule, abort thresholds, support coverage, communications, and decision owners.
6. After explicit approval, deploy only the immutable candidate and keep business mutations disabled until separately authorized.
7. Canary the approved flow, observe safe service and business signals, and reconcile authoritative records.
8. Expand only on passing thresholds; otherwise halt and execute rollback, then retain a redacted receipt.

Approval Boundaries

Do not enable production traffic, change a managed connector, alter schedules, migrate workers, create recognition, approve awards, or send notifications without explicit scope-specific approval.

Output

Return release and configuration identities, deployment diff, mutation preview, rehearsal, approvals, canary evidence, reconciliation, final state, and rollback status.

Error Handling

Safe Workhuman Capability Smoke Test

Overview

Prove identity, entitlement, and one read-only capability before proposing any recognition, award, worker, or integration change.

Prerequisites

• An approved access path from workhuman-install-auth
• Current tenant documentation for the exact capability being tested
• A synthetic or explicitly approved test identity and a named program owner

Tool Discipline

Use Read, Glob, and Grep to inspect configuration, WebFetch to verify current first-party and tenant contracts, and Write or Edit only for fixtures and redacted receipts.

Current Contract

Workhuman publicly describes Social Recognition, a points-based Store, administrator controls, an open API, and managed integrations. Public material does not establish the baseline pack's /api/v1/* routes, payload fields, award levels, visibility values, or status sequence.

Authentication

Use only the documented principal and authorization method for the selected tenant capability. Never substitute an SSO cookie or a guessed bearer-token exchange.

Instructions

1. Freeze the test objective, tenant, principal class, expected entitlement, and zero-write boundary.
2. Fetch the current authorized contract and record its date, owner, environment, and exact read-only operation.
3. Validate the host and path against an allowlist; reject placeholders and production if the approval names a test environment.
4. Use synthetic identifiers or an approved test identity and request only the minimum response fields.
5. Execute one documented read-only probe; record status, latency, schema fingerprint, and redacted correlation identifier.
6. Compare the response with the documented contract and distinguish empty success from authorization or eligibility failure.
7. Draft—but do not execute—a recognition or integration mutation preview with approver, idempotency, and rollback.

Approval Boundaries

Do not submit recognition, approve awards, change worker data, redeem points, or enable integrations during this smoke test.

Output

Return the contract reference, identity and entitlement result, sanitized probe receipt, schema observations, mutation preview, and an explicit READY or BLOCKED decision.

Error Handling

Workhuman Tenant Access and Integration Onboarding

Overview

Choose the supported access model, establish ownership, and prove the smallest safe capability without guessing a host, route, grant, or credential format.

Prerequisites

• The customer tenant, subscribed products, program owner, and integration purpose
• Identity, security, data, and support owners for the affected workforce records
• Current customer-authorized Workhuman documentation or an assigned Workhuman implementation contact

Tool Discipline

Use Read, Glob, and Grep to inspect local configuration, WebFetch to re-check first-party public and authorized tenant contracts, and Write or Edit only for secretless configuration and redacted evidence.

Current Contract

Workhuman publicly documents SSO, controlled privileges, an open API, and managed integrations such as Microsoft Teams and Workday. Its public pages do not define one universal API host, OAuth flow, scope set, or verification route; obtain those details from the customer's current contract.

Authentication

Separate interactive SSO, managed-connector authorization, and API credentials. Do not reuse browser sessions, infer client_credentials, copy administrator cookies, or put secrets in files, commands, prompts, logs, or receipts.

Instructions

1. Record tenant, products, data classes, intended reads and writes, environments, and accountable owners.
2. Classify the path as interactive SSO, a Workhuman-managed integration, or a customer-issued API contract.
3. Re-fetch the applicable first-party product page and the customer's current implementation documentation.
4. Build an access matrix covering principal, roles or scopes, expiry, rotation, revocation, and break-glass ownership.
5. Search the repository for guessed hosts, undocumented routes, hard-coded secrets, and mixed-tenant configuration.
6. Present every tenant setting, connector enablement, consent, and credential request for explicit approval.
7. After authorized provisioning, run the smallest documented read-only check and retain only redacted status and correlation evidence.

Approval Boundaries

Do not change SSO, assign privileges, enable an integration, issue credentials, or test production writes without the relevant customer and vendor owners.

Output

Return the selected access path, contract evidence, access matrix, secretless configuration, verification receipt, rotation and revocation owners, and unresolved vendor questions.

Error Handling

Workhuman Contract-First Local Development Loop

Overview

Develop against sanitized fixtures by default, with the customer contract as authority and live Workhuman access isolated behind a deliberate gate.

Prerequisites

• Customer-authorized schemas or connector mappings with secrets removed
• Synthetic worker, recognition, award, approval, redemption, and failure fixtures
• Separate local, test, and production configuration with named owners

Tool Discipline

Use Read, Glob, and Grep to inspect adapters and fixtures, WebFetch to re-check authoritative contracts, and Write or Edit for local code, tests, fixtures, and redacted evidence.

Current Contract

Workhuman's public site confirms product and integration capabilities but not universal endpoint schemas. Local mocks must therefore be derived from the customer's current approved artifacts and labeled with provenance, not invented from examples.

Authentication

The default local lane has no live credential. Load a test credential only through the approved secret provider, deny production hosts, and fail closed when environment or tenant identity is ambiguous.

Instructions

1. Snapshot the authorized contract with source, date, tenant, environment, and schema fingerprint.
2. Remove names, messages, employment details, balances, addresses, tokens, and correlation identifiers from fixtures.
3. Cover success, valid-empty, unauthorized, forbidden, invalid input, throttling, timeout, duplicate, partial, and schema-drift cases.
4. Put transport behind one adapter that accepts an injected fake and normalizes errors without discarding vendor evidence.
5. Add contract tests for required fields, nullable fields, pagination or checkpoints, idempotency, and unknown-field tolerance.
6. Make the default test command network-denied and deterministic.
7. Gate an optional live test on explicit opt-in, approved non-production tenant, allowlisted host, synthetic record, and cleanup plan.
8. Redact outputs and retain only contract version, test counts, result, and safe correlation evidence.

Approval Boundaries

Do not capture real workforce payloads, contact production, create awards, or change integration configuration from the local lane without approval.

Output

Return the contract snapshot, fixture inventory, adapter boundary, deterministic test result, live-lane safeguards, redaction proof, and drift findings.

Error Handling

Workhuman Evidence-Based Performance Tuning

Overview

Improve an identified bottleneck while preserving correctness, freshness, privacy, financial integrity, and downstream capacity.

Prerequisites

• A named workflow, current baseline, service-level objective, volume model, and bottleneck hypothesis
• Customer-authorized capacity and behavior contracts for every dependent system
• Synthetic load fixtures, reconciliation, abort thresholds, and rollback ownership

Tool Discipline

Use Read, Glob, and Grep to inspect code and telemetry, WebFetch for current vendor context, and Write or Edit for benchmarks, controls, tests, and redacted receipts.

Current Contract

Workhuman supports global recognition, rewards, reporting, open-API use, and managed integrations, but its public pages do not publish universal performance limits. Optimize against measured customer behavior and current documented boundaries.

Authentication

Keep principals tenant- and environment-scoped during measurement. Do not increase credentials or bypass governance to raise throughput.

Instructions

1. Freeze the workflow, source and destination, record volume, freshness, latency and throughput objectives, and correctness invariants.
2. Measure queue time, service time, retries, throttling, batch duration, payload size, downstream latency, and reconciliation lag.
3. Isolate whether the bottleneck is scheduling, serialization, network, vendor processing, HCM, reporting, Store, or downstream logic.
4. Choose one controlled change: batching, bounded concurrency, connection reuse, field minimization, scheduling, checkpointing, or an approved cache.
5. Define cache authority, key, tenant boundary, TTL, invalidation, sensitive fields, and staleness tolerance before caching.
6. Test steady, burst, empty, duplicate, partial, timeout, throttle, downstream-slow, and recovery cases with synthetic data.
7. Present expected gain, capacity impact, correctness proof, privacy effect, abort threshold, and rollback.
8. Canary after approval and retain before-and-after percentiles, throughput, errors, reconciliation, and cost effects.

Approval Boundaries

Do not load-test production, increase concurrency or schedules, cache workforce or award data, or relax correctness and privacy controls without approval.

Output

Return the baseline, bottleneck evidence, selected change, test matrix, capacity and privacy review, canary comparison, reconciliation, and rollback status.

Error Handling

Workhuman Production Readiness Gate

Overview

Issue a fail-closed production decision from exact evidence, with no deployment or program mutation implied by a READY result.

Prerequisites

• Immutable release or configuration identifier and complete scope
• Current tenant contracts, field authority map, program policy, security review, and support plan
• Synthetic test results, canary design, reconciliation, abort thresholds, and rollback owner

Tool Discipline

Use Read, Glob, and Grep to inspect the candidate and evidence, WebFetch to re-check current vendor context, and Write or Edit only for the readiness record and approved release artifacts.

Current Contract

Workhuman capabilities and managed integrations are customer-configured. Readiness must be evaluated against the subscribed products, current implementation documents, program controls, and dependent HCM or collaboration systems—not a generic public endpoint list.

Authentication

Verify every human, administrator, managed connector, and API principal for least privilege, environment isolation, rotation, revocation, and support ownership.

Instructions

1. Freeze release identity, tenant, products, data flows, mutations, excluded scope, deployment window, and owners.
2. Verify contract versions, entitlements, field authority, schemas, configuration, and dependency compatibility.
3. Require passing unit, contract, fixture, security, privacy, duplicate, partial-failure, capacity, and recovery tests.
4. Confirm audience and worker reconciliation, recognition policy, award controls, spend and financial ownership, reporting, and Store implications.
5. Review observability for safe correlation, latency, failures, queue age, reconciliation lag, spend anomalies, and misuse signals.
6. Exercise rollback or disablement and prove checkpoint preservation without losing authoritative records.
7. Present the canary cohort, mutation counts, approvals, abort thresholds, communications, support coverage, and rollback.
8. Return BLOCKED for any missing owner, stale contract, unresolved financial effect, failed gate, or untested recovery.

Approval Boundaries

A readiness decision does not authorize deployment, connector changes, worker mutations, recognition, awards, communications, or spend.

Output

Return the immutable scope, gate matrix, evidence links, principal review, canary and rollback plan, approvals, blockers, and READY or BLOCKED decision.

Error Handling

Workhuman Capacity and Backpressure Governance

Overview

Replace guessed quotas with measured, documented capacity controls that protect recognition, worker-sync, reporting, and downstream systems.

Prerequisites

• Current customer-authorized capacity, retry, batch, and support contract
• Expected records and requests by direction, operation, tenant, and time window
• Service-level objectives, recovery objectives, and authoritative reconciliation method

Tool Discipline

Use Read, Glob, and Grep to inspect traffic and retry configuration, WebFetch for current vendor context, and Write or Edit for models, controls, fixtures, and redacted evidence.

Current Contract

The cited Workhuman public pages do not publish universal request-per-minute limits, retry headers, batch sizes, or concurrency values. Treat all numbers as tenant- and operation-specific until confirmed in current authorized documentation or support evidence.

Authentication

Partition capacity by the documented tenant and principal boundaries. Never rotate credentials, create extra principals, or distribute traffic to evade a limit.

Instructions

1. Inventory every traffic source, operation, direction, schedule, principal, batch size, concurrency, and downstream dependency.
2. Obtain the current documented limits and retry semantics or record a vendor question; do not infer them from a short observation.
3. Establish baselines for latency, throughput, throttling, queue age, error class, batch duration, and reconciliation lag.
4. Implement shared admission control, bounded concurrency, timeout budgets, queue limits, jittered backoff, and retry caps.
5. Retry only operations proven safe by read semantics, idempotency, or authoritative reconciliation.
6. Test burst, sustained load, throttling, timeout, partial batch, downstream slowdown, and recovery with synthetic fixtures.
7. Present schedule or concurrency changes with evidence, projected capacity, abort threshold, owner, and rollback.
8. After approval, canary and compare observed behavior with the model; update the dated contract record.

Approval Boundaries

Do not load-test production, increase schedules or concurrency, split principals, or retry ambiguous recognition and award writes without approval.

Output

Return the documented capacity evidence, traffic inventory, baseline, control policy, retry classification, test result, canary measurements, and unresolved vendor limits.

Error Handling

Governed Workhuman Reference Architecture

Overview

Define explicit authority, trust, data, financial, and recovery boundaries so Workhuman complements rather than silently replaces HCM and customer systems.

Prerequisites

• Tenant products, program goals, systems inventory, data classes, regions, and owners
• Current Workhuman and customer implementation contracts
• Service levels, retention, financial-control, incident, continuity, and audit requirements

Tool Discipline

Use Read, Glob, and Grep to inspect system topology and contracts, WebFetch for current first-party context, and Write or Edit for diagrams, decision records, mappings, and redacted evidence.

Current Contract

Workhuman publicly positions Workday as authority for foundational and organizational worker data in its certified integration, with Workhuman managing recognition and rewards. It also provides workplace integrations and an open API. Exact customer boundaries, routes, fields, schedules, and capabilities remain contract-specific.

Authentication

Model human SSO, administrators, managed integrations, customer adapters, HCM principals, and downstream consumers as distinct trust zones with least privilege and explicit tenant binding.

Instructions

1. Inventory actors, products, HCM, identity, payroll, collaboration surfaces, analytics, support, and customer-owned services.
2. Assign authority for worker identity, organization, eligibility, program policy, recognition, award, spend, redemption, payroll, and analytical derivatives.
3. Draw trust zones, data classes, directions, protocols, principals, secret stores, egress, retention, residency, and audit boundaries.
4. Put customer API access behind one contract-driven adapter with validation, idempotency, backpressure, redaction, and safe correlation.
5. Define managed-connector boundaries separately; do not duplicate vendor-owned behavior in customer code without a justified decision.
6. Specify event, polling, report, or reconciliation modes, checkpoints, duplicates, ordering, partial failure, and recovery.
7. Add approval gates for worker, program, recognition, award, financial, identity, and connector mutations.
8. Test loss of HCM, Workhuman, identity, connector, queue, analytics, and secret-provider dependencies and record degraded modes.

Approval Boundaries

Do not designate a new system of record, duplicate sensitive data, add trust paths, or alter financial and workforce flows without architecture, security, privacy, HCM, payroll, and program approval.

Output

Return the authority matrix, context and trust diagrams, data inventory, adapter and connector boundaries, failure model, reconciliation design, decisions, risks, and review trigger…

Workhuman Contract-Driven Adapter Patterns

Overview

Create a narrow, testable boundary around documented tenant capabilities while keeping vendor transport, business policy, and systems of record separate.

Prerequisites

• A current customer-authorized API schema, managed-connector mapping, or integration specification
• Defined operations, data classifications, owners, and compatibility window
• Synthetic fixtures for all supported results and failures

Tool Discipline

Use Read, Glob, and Grep to inspect contracts and consumers, WebFetch for current first-party context, and Write or Edit for types, adapter code, tests, and redacted receipts.

Current Contract

Workhuman describes an open API but does not publish a universal public SDK or stable route catalogue on the cited public pages. Generate or hand-build only from customer-authorized artifacts and pin the artifact identity.

Authentication

Inject the documented authorization provider at runtime. Keep secret acquisition outside the adapter, prevent cross-tenant reuse, and redact authorization and workforce data from errors.

Instructions

1. Inventory required operations and map each to an exact authorized contract section and owning system.
2. Pin the schema or mapping fingerprint, environment, tenant, acquisition date, and compatibility promise.
3. Generate types when the artifact supports it; otherwise define minimal request and response types without speculative fields.
4. Separate transport, authentication, serialization, retry, idempotency, policy, and business orchestration.
5. Preserve vendor status and safe correlation fields in a normalized error union.
6. Validate response envelopes, tolerate documented optional fields, and reject unsafe type coercion.
7. Test duplicates, partial application, timeouts, throttling, revoked authorization, schema drift, and retry eligibility.
8. Expose only the operations required by the approved workflow and document deprecation ownership.

Approval Boundaries

Do not add undocumented operations, generate from untrusted schemas, publish customer artifacts, or execute tenant writes while building the adapter.

Output

Return the pinned contract identity, operation map, typed boundary, auth injection point, error model, fixture coverage, compatibility policy, and unresolved fields.

Error Handling

Workhuman Security and Privacy Baseline

Overview

Map customer and Workhuman responsibilities and enforce least privilege, data minimization, financial integrity, and evidence-based incident controls.

Prerequisites

• Tenant products, integrations, data flows, environments, owners, and current agreements
• Workforce-data classification, retention, residency, legal, and incident requirements
• Identity, HCM, payroll, recognition, security, privacy, and vendor contacts

Tool Discipline

Use Read, Glob, and Grep to inspect configurations and flows, WebFetch to verify current first-party commitments, and Write or Edit for threat models, control matrices, and redacted evidence.

Current Contract

Workhuman publicly states support for SSO, fraud detection, granular user privileges and grouping, encryption and monitoring practices, GDPR and CCPA compliance, ISO 27001:2022 and ISO 27701:2019 certification, and defined PCI scope. Confirm scope and customer obligations in current agreements rather than treating marketing statements as the entire control contract.

Authentication

Separate human SSO, administrator roles, managed connectors, and API principals. Enforce least privilege, tenant isolation, rotation, revocation, break-glass controls, and non-exportable secrets.

Instructions

1. Diagram identity, worker, recognition, award, redemption, payment-adjacent, reporting, and integration data flows.
2. Classify fields and define purpose, authority, access, retention, residency, export, deletion, and incident ownership.
3. Review SSO, lifecycle, privileges, groups, delegates, separation of duties, dormant access, and emergency access.
4. Threat-model spoofing, cross-tenant access, unsafe messages, approval bypass, award manipulation, fraud, replay, and data exfiltration.
5. Verify encryption, secret storage, egress allowlists, audit evidence, anomaly detection, and redacted observability at each customer-controlled boundary.
6. Reconcile program spend and sensitive administrative actions with independent evidence and named approvers.
7. Test access removal, credential rotation, rejected inputs, duplicate writes, incident containment, and recovery with synthetic fixtures.
8. Present gaps with owner, severity, compensating control, due date, verification, and rollback before changing production.

Approval Boundaries

Do not alter SSO, roles, groups, retention, exports, fraud controls, integrations, or financial workflows without security, privacy, and business-owner approval.

Output

Return the responsibility and data-flow maps, access review, threat model, control evidence, gaps, approved changes, test receipts, and residual risks.

Error Handling

Workhuman Contract and Integration Migration

Overview

Move from a frozen current state to a frozen target while preserving worker authority, recognition history, award integrity, and a tested rollback path.

Prerequisites

• Current and target customer-authorized contracts, schemas, mappings, entitlements, and configurations
• Complete consumer, producer, principal, schedule, and data-flow inventory
• Business, HCM, payroll, identity, security, privacy, integration, and support owners

Tool Discipline

Use Read, Glob, and Grep to inspect dependencies and artifacts, WebFetch for current vendor context, and Write or Edit for mappings, compatibility code, fixtures, plans, and redacted receipts.

Current Contract

Workhuman's public capability pages do not define one universal versioning or deprecation policy for customer APIs and managed integrations. The customer's notices, implementation artifacts, and support guidance control the migration.

Authentication

Map current and target principals, privileges, environments, rotation, revocation, and overlap. Do not keep legacy access active indefinitely or broaden permissions to simplify migration.

Instructions

1. Freeze source and target artifacts by version or digest and record retrieval date, tenant, owner, and effective window.
2. Inventory changed operations, fields, meanings, identities, schedules, limits, integration behavior, and subscribed capabilities.
3. Build a field-level compatibility matrix covering authority, defaults, nullability, identifiers, effective dates, currencies, and deletion semantics.
4. Classify consumers as compatible, adapter-required, dual-read, dual-write, backfill, or retire; prove each classification with fixtures.
5. Test valid, empty, duplicate, late, partial, rejected, revoked-auth, drift, rollback, and reconciliation scenarios.
6. Present canary population, financial exposure, communications, cutover, abort thresholds, overlap duration, and rollback.
7. After approval, canary the target and compare both authoritative state and downstream effects before expansion.
8. Revoke obsolete access, remove compatibility code on schedule, and preserve a redacted migration receipt.

Approval Boundaries

Do not change tenant configuration, mappings, principals, schedules, worker data, awards, or production traffic without all affected owners.

Output

Return source and target identities, change and compatibility matrices, test evidence, canary plan, approvals, reconciliation, rollback state, and decommission schedule.

Error Handling

Workhuman Change Ingestion and Event Governance

Overview

Choose the least risky supported delivery mode and make authenticity, duplicates, ordering, replay, privacy, reconciliation, and fallback explicit.

Prerequisites

• A defined business transition, source of truth, freshness target, expected volume, and downstream owner
• Current tenant documentation for managed integrations, events, APIs, reports, or exports
• Data classification, retention, capacity, incident, and recovery requirements

Tool Discipline

Use Read, Glob, and Grep to inspect consumers and schemas, WebFetch for current first-party and tenant contracts, and Write or Edit for ingestion code, fixtures, mappings, and redacted receipts.

Current Contract

Workhuman publicly confirms managed integrations and an open API but does not publish a universal webhook registration route, event catalogue, signature header, or retry schedule on the cited pages. Treat webhook delivery as unavailable until customer-authorized documentation defines it.

Authentication

For documented push delivery, use the exact authenticity mechanism and secret lifecycle in the customer contract. For polling, reports, exports, or connectors, use a least-privilege authorized principal. Never invent an HMAC header or accept unauthenticated events.

Instructions

1. Define transition, required fields, allowed delay, source authority, privacy class, and downstream mutation.
2. Inventory supported modes: managed connector, documented event delivery, incremental read, scheduled report or export, and approved manual handoff.
3. Select by supportability, authenticity, freshness, replay, observability, capacity, privacy, and cost—not a preference for webhooks.
4. Freeze schemas and define stable identity, deduplication, ordering assumptions, checkpoints, effective dates, and deletion behavior.
5. Implement validate-before-acknowledge, quarantine, bounded retry, dead-letter handling, and authoritative reconciliation.
6. Test valid, invalid, duplicate, late, out-of-order, missing-field, replay, revoked-auth, outage, and partial cases with synthetic fixtures.
7. Present endpoint, schedule, connector, or subscription changes with exposure, owner, rollback, secret plan, and approval.
8. Canary the approved mode, reconcile it to the authority, and retain only redacted operational evidence.

Approval Boundaries

Do not expose an endpoint, create a subscription, enable a connector, poll production, replay messages, or mutate downstream records without named owners.

Output

Return the selected mode and evidence, frozen schema, auth plan, deduplication and ordering policy, failure tests, mutation preview, canary reconciliation, and fallback.

Erro…