# ASHR.work certification tracks Contract item **A3** of `docs/b2b/PRODUCT-INTEGRATION-PACK.md`: for each persona in the A1 manifest, the learning track(s) as **`role_track` × `level`** rows. Levels are `foundations | associate | professional | specialist`. Personas below use the six stable ids from `docs/strategy/ICP.md` (C5-08). Those ids are machine-referenceable and append-only — a track never invents a persona. ## The map | role_track | level | title | target personas | headline use-cases | |---|---|---|---|---| | `ashr-ops` | foundations | ASHR.work Operations — Foundations | `hr-admin`, `payroll-operator` | employee-records-and-leave, payroll-run, hiring-and-onboarding, tenancy-roles-and-audit | | `ashr-posh` | foundations | ASHR.work POSH Compliance — Annual Certification | `hr-admin`, `people-manager`, `employee`, `founder-approver` | posh-compliance | ### Personas with no track, and why | persona | why no track | |---|---| | `candidate` | No ASHR.work login exists for a candidate — the careers board, the job page and the status page are public, token-addressed surfaces. There is no ongoing relationship to certify and no account to enrol. Listed in the manifest for ICP completeness only. | | `founder-approver` (as an `ashr-ops` target) | The founder-approver's ASHR.work job is *approving* — a payroll run, a band exception — not operating the product day to day. They are a target of `ashr-posh` (which is mandatory for everyone) and an optional sitter of `ashr-ops`, not its primary persona. | | `people-manager`, `employee` (as `ashr-ops` targets) | Same reasoning: `ashr-ops` certifies the person who *runs* the org's people operations. A manager-level or employee-level track is a real future track (`ashr-manager` at `foundations`), not a level of this one. | --- ## `ashr-ops` — Foundations **Track id:** `ashr-ops` · **Level:** `foundations` · **Primary personas:** `hr-admin`, `payroll-operator`. Certifies the day-to-day operating skills for ASHR.work itself: keeping employee records and leave balances accurate, driving the monthly payroll run from draft through approval to locked payslips, running hiring from job opening to onboarded employee, and keeping roles, tenant isolation and the audit trail defensible under scrutiny. Blueprint: `assessment/ashr-ops/blueprint.json`. | Domain | Weight | Exam count | Seed items | |---|---|---|---| | `employee-records-and-leave` | 0.30 | 2 | 6 | | `payroll-run` | 0.35 | 2 | 6 | | `hiring-and-onboarding` | 0.20 | 2 | 6 | | `tenancy-roles-and-audit` | 0.15 | 1 | 3 | | **Total** | **1.00** | **7** | **21** | Credential: `assessment/ashr-ops/credential.json` — `validity_days` 365, renewal window 30 days, assurance level A1. ### What the items test Product knowledge, not HR theory. A candidate who has read the ASHR.work docs and driven the product passes; a candidate who knows people operations in the abstract does not. Every item carries a `cites` array of ASHR.work URLs, and `tests/api/miatz-pack.test.ts` asserts every cited URL resolves to a real page in this repo — so an item can never cite a guide that was renamed or deleted. --- ## `ashr-posh` — POSH Compliance, Annual Certification **Track id:** `ashr-posh` · **Level:** `foundations` · **Personas:** every persona with a login — `hr-admin`, `people-manager`, `employee`, `founder-approver`. This is a **compliance track**, and it has a different shape from `ashr-ops`. Passing it once is not the point; being current is. ### The compliance shape | Element | How this track expresses it | |---|---| | **Mandatory** | `mandatory: true` on the track in the manifest, and `compliance.mandatory: true` in the credential. Every person with a login is in scope — the source policy §2 applies to permanent and fixed-term employees, founders and directors, interns, trainees, consultants, contractors and visitors, irrespective of gender, role or employment status. | | **Due dates** | First completion is due **within 30 days of joining** (`compliance.due_within_days_of_joining`), because the policy §12 commits the company to communicating the policy to every person *at induction*. Recertification is due on the credential's expiry date. | | **Attestation** | Passing the assessment is not sufficient. The credential requires the **Annexure A acknowledgement** — the signed "I have received, read, and understood" statement from the policy itself — recorded per person per policy version (`compliance.attestation`). A pass without an attestation is an incomplete record. | | **Audit trail** | `compliance.audit_evidence` lists exactly what must survive an audit or a Board's-Report declaration: who was in scope, who completed, who attested, against which policy version, and when. The policy's own Compliance Declaration asks for complaint counts received / resolved / pending, which is a *separate* record kept in ASHR.work, not a certification artifact. | | **Recertification** | Annual (`validity_days` 365, renewal window 45 days), **plus** two event triggers that reset the clock regardless of the calendar: a new version of the policy, and the constitution of an Internal Committee when headcount reaches 10. Both are listed in `compliance.recertification_triggers`. | ### Grounding — this is ASHR's policy, not POSH boilerplate Content is grounded in **`docs/POSH_POLICY.md`** in this repo, and in the ASHR.work product surfaces that actually carry a POSH case. Specifically: - The **Local Committee (LC)** route, not an Internal Committee. The policy §2 is explicit that the company currently employs fewer than 10 persons and is therefore not required to constitute an IC; complaints go to the district Local Committee constituted by the District Officer under §6 of the Act. A generic POSH course would teach the IC and be **wrong for this company**. - The real statutory numbers from the policy: **3 months** to complain (extendable by a further 3), **90 days** for the inquiry, **60 days** for the company to act on the recommendations, and up to **3 months' leave** as interim relief. - The policy's §3 definition of "workplace", which explicitly includes work-from-home and *all digital and virtual interactions* — Slack, email, video calls, chat. This is the definition most generic material gets wrong. - The product path a complaint actually takes: **Raise a Concern** (`/concerns`) with a one-time tracking token for anonymous reporters, and the committee-only workspace (`/concerns/committee`) with confidential notes, an SLA sweep on the statutory deadlines, an access log on every case open, and a recorded outcome. ### Honest limits on this track `docs/POSH_POLICY.md` is, at the time of writing, marked **"Template / draft for small teams (fewer than 10 employees)"** with an explicit instruction to obtain legal review before formal adoption, and it still carries bracketed placeholders for the company legal name, the effective date, the designated Point of Contact and the district Local Committee's contact details. That is a real constraint, and this pack states it rather than papering over it: 1. Items are written against the policy's **substance** — the Act's definitions, the LC route, the statutory clocks, the confidentiality and anti-retaliation rules — never against a bracketed placeholder. No item asks a candidate to recall a name or an address that has not been filled in. 2. When the policy is adopted after legal review, the credential's `policy_version` changes, which is itself a recertification trigger, and the named SMEs must re-review the item bank (contract A5, drift review). 3. `credential.json` records the exact source and its status in `compliance.policy_source`, so nobody downstream mistakes a template for an adopted policy. Blueprint: `assessment/ashr-posh/blueprint.json`. | Domain | Weight | Exam count | Seed items | |---|---|---|---| | `policy-scope-and-definitions` | 0.35 | 2 | 6 | | `raising-and-redressal` | 0.40 | 2 | 6 | | `committee-records-and-recertification` | 0.25 | 1 | 3 | | **Total** | **1.00** | **5** | **15** | --- ## What is deliberately absent - **No cut score.** The Angoff panel sets it on-platform (contract A4/A5). A number proposed here would be a guess wearing a rating's clothes. - **No `ashr-developer` track yet.** The manifest now carries a real `openapi_url`, so the track has become possible — but a developer blueprint is its own authoring job with its own SMEs, not a rider on this one. - **No enrolment, no cohorts, no exam windows.** Those are platform-side and live entirely with Miatz (TRACKER M6-01, M6-05).