Job Postings & Applications

Part of the Anaya Care Handbook — the source of truth for how the product must behave. When the product needs to change, change this document first, then make the system match it.

What this covers

This page governs the hiring marketplace. An agency publishes generic job postings or a client-linked coverage bundle containing several uncovered generated shifts. A published posting is visible both to the agency's existing staff and to the ARMI Marketplace of vetted independent care providers. Applicants choose the bundle shifts they can cover. Agency staff review applications on the web dashboard, approve some or all requested shifts, and accept or reject the applicant. Acceptance can bring an unaffiliated care provider into the agency, add them to the client's care team, and stage exclusive coverage; final assignment remains a separate Care Operations step.

The ARMI Marketplace page owns the full marketplace spec — ARMI validation, profiles, availability calendars, booking flow, and labour-compliance controls. This page covers only how a job posting reaches that marketplace, how its availability filter reads ARMI calendars, and how a marketplace booking lines up with the application workflow. Declining a shift returns it to the care team for pickup, which is covered under Scheduling & Shifts — that is a different flow from the posting-and-application one described here.

Key terms

• Job posting — An agency's advertised care job: title, description, required skills, location, pay range, urgency, when the work is needed, and optionally a client and coverage bundle.
• Coverage bundle — the unassigned generated shifts an agency selects from one client's active generation batch, advertised together in one posting.
• Shift pattern — when the work is needed, written as weekday plus clock times in one timezone — the same vocabulary a care provider declares availability in. Derived from the selected shifts on a coverage bundle; entered by staff on a generic posting.
• Application — A care provider's response to a published posting, optionally with a cover message and, for a coverage bundle, the shift IDs they can cover.
• Approved shifts — the requested shifts the decision-maker accepts for one applicant.
• Staged coverage — exclusive reservations created for approved shifts; the caregiver is not written onto the shifts until final assignment.
• Featured feed — The highlighted marketplace list: published postings that are flagged as featured or marked urgent.
• Job alerts opt-out — A care provider's setting that removes them from the marketplace entirely: no listings, no alerts, no applying.
• Reviewer notes — Free-text notes a reviewer attaches to an application; the applicant can see them.
• Availability indicator — The signal reviewers see next to each applicant showing, per requested shift, whether it fits their declared availability and whether it would clash with existing work or push them over the daily hour limit.
• ARMI availability filter — The real-time cross-reference between a posting's shift pattern and every ARMI's availability calendar, run when an agency creates or browses a posting; it decides which ARMIs appear and how they are flagged. Defined on the ARMI Marketplace page.
• Marketplace booking — Hiring an ARMI for a posting through the ARMI Marketplace flow (discover, contact in-platform, decide, both parties confirm), as opposed to the in-app application flow described here. The two overlap at discovery and at the resulting calendar entry.
• Separation of duties — Triaging applications and making the final accept/reject decision are two different permissions.

How it works

Posting lifecycle

A posting is always owned by one agency and moves through three statuses: Draft (being prepared, invisible to providers), Published (live on the marketplace), and Closed (hiring finished).

Agency staff create generic postings by hand — stating the weekday-and-hours pattern the role needs — or create a coverage bundle by selecting uncovered shifts from the same client and active generation batch, which is where the pattern comes from instead. Publishing puts the posting on the marketplace and, unless the publisher declines, alerts eligible care providers in the app, by push, and by email. Unpublishing pulls it back to Draft for editing. A bundle remains open while at least one shift lacks staged coverage and closes automatically when all included shifts are staged. Staff may close it earlier; closing additionally rejects every undecided application and notifies each applicant. A deleted posting disappears from every view, but the record is kept.

Applying

Care providers browse published postings in a list, in the ARMI Marketplace, and in the featured feed. A coverage bundle shows every shift and evaluates it independently against the provider's declared weekly availability, date overrides, committed shifts, staged coverage, overlap rules, and daily-hour limits. Eligible shifts are selectable; ineligible shifts remain visible with the exact reason. A partially available provider may apply for any non-empty eligible subset. A provider with an incomplete availability profile is directed to finish it before applying and then returned to the posting.

Coverage bundles use concrete shifts already produced by the retained 45-day generation batch, so application analysis never predicts ungenerated occurrences. A generic posting has no bookable shifts, so nothing can clash with it; the only check that means anything there is whether its shift pattern falls inside the provider's declared availability.

Reaching the ARMI Marketplace

Publishing a posting puts it in front of two audiences at once: the agency's existing staff and the ARMI Marketplace of vetted independent care providers. Because every posting states its shift pattern in the same weekday-and-clock-times vocabulary ARMIs declare availability in, the marketplace's availability filter cross-references every ARMI's availability calendar in real time — not a cached snapshot — and decides who appears:

• Confirmed available for the full window — appears in results.
• Available for only part of the window — appears, but flagged as partially available rather than hidden.
• Holds a conflicting committed shift — auto-excluded from results.
• Availability not kept up to date — appears, but flagged with a not-updated warning.

The same location, care-provider type, certification, star-rating, language, specialization, and Caregiver Level Badge filters from the marketplace apply alongside the availability filter.

Marketplace booking vs. applying

A posting can also lead to a marketplace booking, which overlaps with — but is not the same as — the in-app application flow. In a marketplace booking the agency discovers an ARMI by posting the job or browsing the filtered results, contacts them through secure in-platform messaging, and makes the hiring decision itself. That hiring decision — including any background checks — is the agency's responsibility, not Anaya's. When both parties confirm the booking, the slot is automatically blocked in the ARMI's availability calendar and a matching entry is created in the Anaya Calendar for the agency, the ARMI, and the assigned client. The full booking lifecycle lives on the ARMI Marketplace page.

Reviewing and deciding

When a provider applies, the posting agency's management staff are notified. Reviewers triage applications (mark them Reviewed, add notes, see the availability indicator); only staff with decision authority can accept or reject. For a coverage bundle, the applicant drawer uses the same live per-shift analysis as the provider screen and acceptance gate. It shows requested shifts, current eligibility, the reason for each conflict, workload before and after, and remaining bundle coverage. A decision-maker may approve any currently eligible subset of the requested shifts. The applicant is notified only of the final accept/reject outcome. Every status change records who acted and when.

What acceptance does

The acceptance contract is one operation with the following sequence:

1. Approve shifts — the decision-maker chooses a non-empty subset of the applicant's requested shifts.
2. Re-check availability — every approved shift is re-evaluated before the application status changes.
3. Agency onboarding — an unaffiliated provider joins the posting agency as an active care provider.
4. Care-team membership — the provider is added to or reactivated on the client care team.
5. Stage coverage — one exclusive reservation is created per approved shift. The shifts remain unassigned.
6. Recompute coverage — the posting closes automatically only when every bundled shift is staged; otherwise it stays Published for more applicants.

Final Shift Assignment re-checks the reservations and commits providers to shifts. Acceptance never creates schedules or shifts and never bypasses that assignment step.

The sequence and live checks ship today, but its database writes are not yet wrapped in one transaction. JOB-31 retains atomic rollback as an explicit remaining requirement.

Rules

• JOB-1 — A job posting belongs to exactly one agency and is either generic or a client-linked coverage bundle created from uncovered generated shifts. A coverage bundle always starts in Draft.
• JOB-2 — A posting is always in exactly one of three statuses: Draft, Published, or Closed. Only Published postings are visible to care providers and able to receive applications.
• JOB-3 — Every posting must have a title, a location, a list of required skills, a pay range, and a statement of when the work is needed. The minimum hourly rate can never exceed the maximum, and rates must stay between 0 and 1,000 per hour.
• JOB-4 — A coverage bundle contains one or more unassigned generated shifts from the same client and active generation batch, selected by staff and defaulting to every shift still uncovered. Shifts that are already assigned or reserved must be shown with that reason rather than hidden, and cannot be selected. A shift can belong to at most one open bundle.
• JOB-5 — Publishing a posting must alert exactly the care providers of that posting's own agency who are active, identity-verified, and have not opted out of job alerts. The alert reaches each of them in the app, as a push notification, and by email. Who receives it is decided by the posting's agency, never by who happened to press Publish, so a platform administrator publishing on an agency's behalf reaches that agency's providers and no one else. (✅ In code)
• JOB-6 — Once a posting is Closed, it must stay closed. Reopening hiring requires a new posting.
• JOB-7 — "Close & reject remaining" must close the posting, reject every application still in Submitted or Reviewed, and notify each rejected applicant.
• JOB-8 — Only care providers can apply to postings, and each provider can apply at most once per posting. A cover message is optional and limited to 2,000 characters.
• JOB-9 — A provider who has opted out of job alerts is fully outside the marketplace: no postings in their lists, no publish alerts, and any attempt to apply is refused.
• JOB-10 — For a coverage bundle, each shift is independently selectable only when it fits declared availability, date overrides, committed shifts, active reservations, overlap rules, and daily-hour limits. Ineligible shifts stay visible with the reason, and a posting is never hidden from a provider's list for being a poor fit.
• JOB-11 — The marketplace must never schedule a care provider past the daily hour limit (currently 12 hours per day across all clients, with up to 24 hours per day allowed for a single client — see Decisions needed).
• JOB-12 — An unaffiliated care provider can browse and apply to published postings from every agency; agency staff only ever see their own agency's postings and applications.
• JOB-13 — The featured feed shows only published postings that are flagged as featured or marked urgent, with featured ones first.
• JOB-14 — When a new application arrives, only management staff of the posting's agency are notified. (✅ In code)
• JOB-15 — Staff with review permission can triage applications (mark Reviewed, write notes) but must not be able to accept or reject; the final decision requires the separate decide permission.
• JOB-16 — An application follows one path: Submitted → (optionally Reviewed) → Accepted or Rejected. Accepted and Rejected are final; releasing accepted coverage requires a separate supervised reservation-release action. (✅ In code — the release action remains JOB-35)
• JOB-17 — Applications can only be accepted while their posting is open for hiring — never on a Closed posting. (✅ In code)
• JOB-18 — Every application status change records who made it and when. The applicant is notified only when the outcome is Accepted or Rejected. The Accepted notification is sent after agency onboarding and care-team membership are written, never before, so the app a provider opens from that notification already reflects their new client. (✅ In code)
• JOB-19 — Reviewer notes on an application are visible to the applicant, so staff must write them as applicant-facing.
• JOB-20 — Accepting a coverage application must re-run every approved shift through declared-availability, override, commitment, reservation, overlap, and daily-hour checks before changing application status. Accepting a generic posting requires only that the applicant has declared availability at all — a partial pattern match is a hiring judgement, not a block.
• JOB-21 — Accepting an applicant who belongs to no agency must add them to the posting's agency as an active care provider.
• JOB-22 — If the posting names a client, acceptance adds the provider to that client's care team — reactivating a previously removed membership rather than duplicating it — and creates exclusive reservations for the approved shifts; it does not assign the shifts. Acceptance must not be blocked by the Care Operations ordering gate that governs manual care-team additions, and a failure to establish membership must be surfaced rather than silently skipped. (✅ In code — a failed care-team add now notifies everyone in the agency holding the applications-decide permission)
• JOB-23 — Acceptance never creates schedules or shifts. A coverage bundle closes automatically when every bundled shift has staged coverage and otherwise stays Published for additional applicants.
• JOB-24 — Reviewers must see requested shifts, live per-shift eligibility and reasons, workload impact, approved shifts, and remaining bundle coverage; these results must come from the same evaluation as the acceptance gate so the two cannot disagree.
• JOB-25 — Publishing a posting must make it visible to both the agency's existing staff and the ARMI Marketplace of vetted independent care providers. (🚧 Spec only)
• JOB-26 — The ARMI availability filter must cross-reference a posting's shift pattern against every ARMI's availability calendar in real time (not a cached snapshot) and resolve each ARMI as: confirmed available for the whole pattern (appears), available for only part of it (appears, flagged partial), holding a conflicting committed shift (appears, flagged), or with availability not kept up to date (appears, flagged not-updated). Postings are never hidden for being a poor fit. (⚠️ Partial — fit is evaluated and shown per posting and per applicant; directory-wide ARMI search is still planned)
• JOB-27 — When a posting is filled through a marketplace booking, discovery happens via posting or browsing the filtered results and contact happens through secure in-platform messaging; the hiring decision — including any background checks — is the agency's own responsibility, and once both parties confirm, the slot must be auto-blocked in the ARMI's availability calendar and a matching entry created in the Anaya Calendar for the agency, the ARMI, and the assigned client. (🚧 Spec only)
• JOB-28 — Every posting states when the work is needed as a shift pattern: weekday plus clock times in one timezone. On a coverage bundle the pattern is derived from the selected shifts and is not separately editable, so what is advertised can never drift from the work on offer. On a generic posting staff enter it directly. (✅ In code)
• JOB-29 — A coverage application must contain a non-empty, duplicate-free subset of the posting's currently uncovered and eligible shift IDs. (✅ In code)
• JOB-30 — A decision-maker may approve only a non-empty subset of the application's requested shifts that remain eligible at acceptance time. (✅ In code)
• JOB-31 — Accepting an application, onboarding the provider, adding care-team membership, and creating reservations must be atomic. A failure leaves all records unchanged. (🚧 Spec only)
• JOB-32 — At most one active coverage reservation may exist for a shift, including under concurrent acceptance attempts. (✅ In code — enforced by a partial unique index)
• JOB-33 — Multiple applicants may be accepted for one coverage bundle when their approved shifts do not overlap the same shift. (✅ In code)
• JOB-34 — A coverage bundle closes automatically when all included shifts have active staged or committed coverage and rejects remaining undecided applications with notification. (⚠️ Partial — automatic closure ships; automatic rejection and notification of undecided applicants does not)
• JOB-35 — Releasing accepted coverage must release its active reservations, reopen the posting when uncovered bundled shifts remain and the posting is otherwise eligible, and retain an audit record. (🚧 Spec only)
• JOB-36 — Final shift assignment consumes staged reservations only after the Scheduling & Shifts live re-check; application acceptance never directly commits the caregiver to the shift. (✅ In code)
• JOB-37 — Every application in the review list must carry its own screening summary, readable without opening the applicant's profile: which of the posting's required skills the applicant holds and which they lack, how far they live from the work, and how many of the shifts they requested their declared availability actually allows — naming the first blocking reason. Availability figures come from the same evaluation as the acceptance gate (JOB-24), so a card and the fit detail can never disagree. The triage and decision actions must be directly visible on each application, not hidden behind a menu. (✅ In code)
• JOB-38 — Whoever publishes a posting decides whether it announces itself. Publishing offers a choice to alert care providers, set to alert by default, so the quiet path is always deliberate and never the accident of a forgotten setting. Declining suppresses the in-app, push, and email alert for that publish only — it changes nothing about the posting itself, which is published, visible, and open to applications either way. This choice is the agency's and sits on top of each provider's own opt-out (JOB-9): a provider who has opted out is never alerted regardless, and choosing to alert can never override them. Re-publishing a posting that was previously unpublished makes the choice again. (✅ In code)

Who can do what

Decisions needed

1. What is the real daily hour cap? The stated requirement says a provider must not exceed 16 hours of scheduled care per day; the system enforces 12 hours across clients / 24 hours for the same client. Options: keep 12/24, switch to a flat 16, or make the cap configurable per agency.
2. Should unassigned care providers receive new-posting alerts? They are the marketplace's main audience, but today's alerts may only reach providers already inside the agency. Options: alert all eligible providers platform-wide, alert only the agency's own providers, or let providers subscribe by location/filters.
3. Should accepted or rejected decisions ever be reversible? JOB-16 keeps the decision final and JOB-35 defines a separate supervised coverage release. Decide which roles may perform that release and whether the applicant receives a dedicated explanation.