Privacy & Accessibility

What is stored locally

Prior Work uses your browser's localStorage to persist session state between page navigations within a single browser session. This includes:

• •The active model
• •Report context fields you have entered (organisation name, scope, preparer)
• •Report section content generated during the session
• •Demographic column metadata from CSV uploads (column names and unique value lists - not the underlying rows)

This data never leaves your device. It is not transmitted to Prior Work servers and is cleared when you use the "Clear model" button or clear your browser's local storage.

Claude AI integration and your API key

Prior Work's report generation features use the Anthropic Claude API. If you choose to use these features:

• •You supply your own Anthropic API key. Prior Work does not hold, store, or have access to your key beyond the current session.
• •When report generation is triggered, a prompt containing model output data (factor names, probability distributions, intervention rankings) is sent to Anthropic's API on your behalf. No raw survey response rows are included in the prompt.
• •Your use of the Claude API is governed by Anthropic's usage policies. As the API key holder, you are the contracting party with Anthropic, not Prior Work.
• •If your organisation's data handling policies prohibit sending organisational data to third-party AI services, you should review Anthropic's data processing agreements before using the report generation features.

Backend processing

Model building is performed on a stateless backend server. Uploaded CSV data is sent to this server only for the duration of the model-building computation and is not persisted. The server returns a fitted model which is then stored locally in your browser as described above.

Analytics and tracking

Prior Work does not use third-party analytics, advertising trackers, or session recording tools. No cookies are set beyond those required for application function.

Workforce data and privacy obligations

Survey data about workers is typically sensitive personal information under the Australian Privacy Act 1988 and equivalent State legislation. Prior Work's architecture - local processing, no storage, user-held keys - is designed to minimise Prior Work's role as a data processor. However, the organisation conducting the survey remains responsible for ensuring that collection, use, and disclosure of worker survey data complies with applicable privacy law, enterprise agreements, and any relevant workplace policies.

Group-level by design, never individual

Prior Work's analysis operates on the workforce as a whole, or on groupings within it (a team, a site, a department), but never on named individuals. There is no individual scoring, no per-worker risk profile, and no mechanism for the tool to report on a specific person. This is a deliberate design choice, not a limitation we plan to remove.

The reason is straightforward. Psychosocial conditions are produced by how work is organised, supported, and led. The levers for change sit at that organisational level too. A tool that names individuals invites the wrong response, which is to treat the worker as the problem, and crowds out the response that actually shifts outcomes, which is to redesign the conditions. Designing the tool so it can only see groups keeps the conversation where the leverage is.

Practical consequences:

• •Reports describe the working environment, not specific workers.
• •Recommendations target work design, leadership, resourcing, and policy. They do not target individuals for assessment, screening, or support pathways.
• •Analysis of small groups (under roughly 20 respondents) is blended with sector-level patterns specifically so a small team's results cannot be reverse-engineered to identify individual responses.
• •Decisions about individual workers, including support, performance, or wellbeing conversations, remain a matter for direct conversation, supervisor judgement, and where appropriate clinical or HR support. They are never derived from this analysis.

This stance aligns with ISO 45003's transparency requirements for psychosocial risk management and reflects the broader principle that the leverage to improve psychological safety at work sits in how the work is structured, not in profiling the people doing it.

Target standard

We aim to meet WCAG 2.1 Level AA across all process pages and content pages. This includes:

• •Sufficient colour contrast for all text (minimum 4.5:1 for normal text, 3:1 for large text)
• •Keyboard navigability for all interactive elements
• •Descriptive labels and ARIA attributes on form controls
• •Logical heading hierarchy and landmark regions
• •Meaningful text alternatives for non-decorative images

Known limitations

The following areas have not yet been fully assessed against WCAG 2.1 AA:

• •Model diagram (Data Analytics): The interactive model diagram is navigable by mouse but not yet by keyboard or screen reader. A tabular fallback view is on the roadmap.
• •Report generation output: AI-generated text is presented as prose HTML which is screen-reader accessible, but the generation controls have not been formally tested with assistive technology.
• •Downloadable templates: CSV and Word document templates have not been assessed for document-level accessibility (e.g. tagged PDF, accessible table structure).

Feedback

If you encounter an accessibility barrier or have a specific access need, please contact [email protected]. We aim to respond within five business days.

Assessment approach

Currently assessed via automated tooling (axe-core) and manual review. A formal third-party WCAG audit is planned.