# 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 | | `ashr-partner-l1` | foundations | ASHR.work Partner — L1 Foundations and Sales | none — audience `partner` (partner staff) | explaining and selling ASHR.work accurately | | `ashr-partner-l2` | associate | ASHR.work Partner — L2 Implementation and Migration | none — audience `partner` (partner implementers) | implementing ASHR.work for a customer | ### 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** | --- ## `ashr-partner-l1` — Partner L1, Foundations and Sales **Track id:** `ashr-partner-l1` · **Level:** `foundations` · **Audience:** `partner` · **Academy code:** ASHR-L1. The first rung of the Demystify Partner Academy ladder for ASHR.work. It certifies a person at a partner firm — a reseller, an affiliate, a CA practice — who explains and sells ASHR.work: what the product covers, how the tiers are bundled, what the India payroll statutory scope is **and where it stops**, how the trial and the partner NFR workspace work, and which claims a partner may make. **Why no persona.** The six persona ids are ICP *customer* personas and are append-only. A partner's staff member is not one of them, so the track names the `partner` audience (Miatz `member_kind`) instead of borrowing or inventing a persona id. Blueprint: `assessment/ashr-partner-l1/blueprint.json`. | Domain | Weight | Quiz count | Practice items | Secured drafts | |---|---|---|---|---| | `modules-and-plans` | 0.30 | 3 | 9 | 6 | | `india-statutory-scope-and-limits` | 0.30 | 3 | 9 | 6 | | `nfr-trials-and-partner-mechanics` | 0.20 | 2 | 6 | 4 | | `positioning-claims` | 0.20 | 2 | 6 | 4 | | **Total** | **1.00** | **10** | **30** | **20** | Credential: `assessment/ashr-partner-l1/credential.json` — a **Badge** that does not expire (`validity_days` is an explicit `null` with its reason: the academy gives L1 no expiry and tracks a quarterly release-update module that never expires the badge). The gate quiz passes at 0.70, the academy's existing L1 rule; it is not a cut score this pack sets. Assurance level A1. ### Two pools, kept apart - **Practice items** (`items/`) are published, listed in the manifest, and may feed lesson quizzes, study guides and agent corpora. - **Secured drafts** (`secured/`) are the gate-quiz pool. They are never served: `lib/miatz/pack.ts` excludes every `secured/` directory, and `tests/api/miatz-pack-secured.test.ts` proves no route, sitemap entry or static param reaches them. They are drafts for the SME panel to review and import into the Miatz secured item bank, and they must never be copied into an agent corpus, an eval or a practice quiz. ### What the items hold to - **Grounded in this repo.** Every item cites the ASHR.work pages it rests on (`cites`, checked to resolve) and the repo files its facts were read from (`sources`, checked to exist) — the pricing and billing help, the module catalogue, the payroll engine model, `lib/payroll/pt-defaults.ts`, decision D-10 (exports only), the NFR plan and partner attribution code. - **No prices.** Partners link the live pricing page and never quote a rate; a test fails any partner-track item that carries a rupee amount. - **No customer data.** Items describe a synthetic organisation by its shape. A test scans every item for the shapes of real identifiers (email, PAN, GSTIN, IFSC, Aadhaar or UAN, mobile number, row ids). - **Claims by id.** Positioning items carry `claims` ids from the partner positioning table (C-01 to C-16) and test the allowed wording against the forbidden one: records stored in India, not "all AI runs in India"; "built to support DPDP obligations", not "compliant"; no SOC 2 or ISO certification today; an English-only interface; the AI-workers records not sold as a module until they are catalogued and priced. ## `ashr-partner-l2` — Partner L2, Implementation and Migration **Track id:** `ashr-partner-l2` · **Level:** `associate` · **Audience:** `partner` · **Academy code:** ASHR-L2 · **Prerequisite:** an active ASHR-L1. The Practitioner rung of the Demystify Partner Academy ladder for ASHR.work. It certifies an implementer at a partner firm who takes a customer from an empty workspace to a handed-over one: tenant setup and roles, leave and attendance policy, payroll statutory configuration up to a first run in review, migration of the six importable entity types, Slack and single sign-on where enabled, and a written handover. Like every partner track it names the `partner` audience rather than an ICP customer persona. Blueprint: `assessment/ashr-partner-l2/blueprint.json`. | Domain | Weight | Theory count | Practice items | |---|---|---|---| | `tenant-setup-and-roles` | 0.15 | 2 | 6 | | `leave-and-attendance-policy` | 0.15 | 2 | 6 | | `payroll-statutory-configuration` | 0.25 | 3 | 9 | | `data-imports` | 0.30 | 3 | 9 | | `slack-sso-and-handover` | 0.15 | 2 | 6 | | **Total** | **1.00** | **12** | **36** | ### Two halves - **Theory.** A secured exam drawn on the platform at the cut score the Angoff panel sets. The published `items/` are practice only. - **Practical — ASHR-L2-P.** `assessment/ashr-partner-l2/practical.md` is the task sheet. Its check ids A1 to A7 and their weights (A2, A3 and A4 must pass) are what the ASHR-L2 check spec grades. Read-only checks write a report; a human checker confirms it. Pass: every must-pass check met and a weighted score of 80% or more. ### Credential validity — pending PD-09 Credential: `assessment/ashr-partner-l2/credential.json` — a **Certification**, `validity_days` 730 with a 60-day renewal window. That is the academy rule and it is **assumed, not decided**: owner decision PD-09 asks whether partner credentials follow the academy rule or the customer tracks' 365/30. The credential's `validity_basis` block records PD-09 as pending with option A assumed, and the values option B would set. --- ## 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).