Australia automated-decision transparency readiness

Australia ADM evidence readiness for APP entities

Build a defensible inventory of governed automated actions, decision context, human intervention, outcomes, and evidence before the APP Privacy Policy amendments commence.

APP 1.7 to 1.9 are scheduled law commencing 10 December 2026. This is a technical readiness guide, not legal advice, OAIC approval, certification, or a determination that the amendments apply to a particular system.

Official status Scheduled law
Issuer Australian Parliament and Office of the Australian Information Commissioner
Act registered 13 December 2024
Commencement 10 December 2026
Last verified 27 July 2026
Law and guidance boundary

Start with the enacted APP 1 text; keep developing guidance separate.

From 10 December 2026, APP 1.7 to 1.9 require covered APP entities to add specified information about certain automated decisions and the personal information used to their APP Privacy Policy. The OAIC consultation concerns developing guidance and does not alter the statutory text.

The OAIC is developing more detailed automated-decision transparency guidance. Its consultation is an official source for that process, but the consultation does not create additional statutory requirements.

APP 1.7 scope logic

Three conditions define the automated-decision disclosure trigger.

An APP entity needs its own legal and data assessment. HaltState records can support an inventory only for actions that the customer actually integrates.

  1. 01Program involvement

    A computer program makes a decision, or does a thing that is substantially and directly related to making it.

  2. 02Significant effect

    The decision could reasonably be expected to significantly affect an individual's rights or interests.

  3. 03Personal information

    The condition applies when personal information about the individual is used in the program's operation.

APP 1.8 policy information

The APP Privacy Policy must describe specified categories, not dump runtime logs.

For covered arrangements, the policy must include information about the following kinds. Legal advisers and privacy owners must determine the final wording and level of detail.

Scheduled-law crosswalk

Technical evidence can support the assessment; it cannot replace it.

Each row preserves the APP entity responsibility and the verified limit behind the mapped control. Privacy-policy drafting and disclosure remain an explicit product gap.

Supports evidence

APP 1.7 scope evidence for programs, decisions, and personal information

Record caller-supplied agent attribution and declared action labels for business actions that the customer has routed through an active HaltState integration.

APP entity responsibility
The APP entity owns its system inventory, personal-information data map, decision-impact assessment, legal scope analysis, and proof that every relevant program and action is covered.
Verified limitation
Agent attribution is caller supplied. HaltState sees only customer-integrated actions, does not discover personal information use, and does not determine whether APP 1.7 applies.
Supports evidence

APP 1.8 kinds of decisions and automated steps

Return a policy decision for a declared action and preserve action and decision labels that can support an APP entity's workflow inventory.

APP entity responsibility
The APP entity owns classification of the kinds of decisions, automated steps, personal information, affected individuals, and significant effects that must appear in its APP Privacy Policy.
Verified limitation
Action names and parameters are supplied by the customer. Expired-trial, policy-load, and no-matching-rule paths can default to ALLOW, so HaltState records do not establish a complete statutory decision inventory.
Supports evidence

Human checkpoints and final outcomes as operational context

Record approval-required decisions and best-effort execution outcomes that can help an APP entity explain how an integrated automated workflow operates.

APP entity responsibility
The APP entity owns approval persistence, reviewer authority, reconsideration and correction processes, final outcome reconciliation, and any explanation provided to individuals.
Verified limitation
Human approval is not itself an APP 1.7 to 1.9 statutory requirement. Pending operation persistence is customer owned and execution reporting is best-effort rather than guaranteed durable linkage.
Verified product gap

Privacy-policy content, legal assessment, and disclosure

Expose a reviewed product gap between limited technical evidence and the legal, data-governance, drafting, publication, and individual-rights work required of an APP entity.

Mapped controls
APP entity responsibility
The APP entity and its advisers own legal assessment, privacy-policy drafting and validation, notices, data accuracy, access and correction, complaints, redaction, retention, and publication.
Verified limitation
Current Proof Pack evidence is refund-specific, the verifier does not recompute the embedded action-evidence hash, and public redaction covers a bounded refund projection. HaltState does not draft or validate an APP Privacy Policy.
Separate voluntary guidance

Guidance for AI Adoption adds a broader operating checklist.

The voluntary official guidance presents six essential practices for safe and responsible AI adoption, including accountability, risk management, data governance, testing and monitoring, human control, and stakeholder transparency.

Published 21 October 2025, this is voluntary official guidance built around six essential practices. It is not law and does not change APP 1.7 to 1.9.

Supports integration

AI register, records, monitoring, and human control

Provide selected pre-execution decisions, approval checkpoints, action records, outcome reports, and an external stop integration for actions routed through active governance.

APP entity responsibility
The organisation owns its complete AI register, accountability structure, risk assessment, data governance, testing, monitoring, human oversight, stakeholder communication, incident response, and decommissioning processes.
Verified limitation
The Guidance for AI Adoption is voluntary official guidance, not law. HaltState does not provide a complete AI register, organisation-wide risk-management system, redress process, monitoring programme, or decommissioning workflow.
Reviewed control detail

Inspect the exact capability boundary behind every Australia mapping.

These catalogue records are reused without broadening their enforcement point, evidence, capability status, customer responsibility, or limitation.

HS-IDENT-001 Native control

Attribute a proposed action to a declared agent

Bind each guard request and evidence record to a stable agent label within the authenticated tenant context.

Enforcement point
Guard request ingestion and decision recording.
Customer responsibility
Provide a trustworthy agent label and protect the tenant credentials that establish request scope.
Control limitation
The agent label is caller-supplied attribution metadata, not cryptographic workload identity or proof of the human principal.
HS-ACTION-001 Native control

Declare the business action before its side effect

Submit the intended action and bounded context to HaltState before the protected system is changed.

Enforcement point
Immediately before the customer-owned tool or business action executes.
Customer responsibility
Wrap every protected side effect and remove unguarded execution paths.
Control limitation
The customer must place the guard call before every protected side effect and must not provide an unguarded bypass.
HS-DECIDE-001 Native control

Return a policy result under active governance

When the trial is active and policy loading succeeds, evaluate a declared action and return ALLOW, APPROVAL_REQUIRED, or DENY before execution.

Enforcement point
Between action declaration and the protected side effect.
Customer responsibility
Treat the returned decision as authority, execute only an allowed or later-approved action, and monitor trial state and policy availability.
Control limitation
Expired trials bypass governance and return allowed with governance inactive. A policy-load failure returns an empty policy set, and no matching policy defaults to ALLOW. Customers must not treat this control as fail-closed.
HS-APPROVAL-001 Native control

Hold a guarded action for human approval

Prevent execution while a selected action awaits an authorised decision.

Enforcement point
After an approval-required decision and before any customer-side execution.
Customer responsibility
Persist the pending operation and prevent execution until an authorised approval is returned.
Control limitation
The customer worker must persist the pending business operation and retry only after an approved decision.
HS-REPORT-001 Native control

Receive and best-effort record an execution report

Accept an authenticated guard report, attempt to update a matching approval context, write an action-log entry, and emit a runtime event.

Enforcement point
After allowed execution succeeds or fails.
Evidence link
/live/
Customer responsibility
Report the final execution result accurately, retain the operation-to-report binding in the customer ledger, and verify durable receipt when that matters.
Control limitation
This is report receipt and best-effort recording, not proof that a guarded action was durably linked. Immediate ALLOW can have no approval row; the endpoint does not check whether its UPDATE matched a row; the idempotency key is not written to the action log; and event emission failures are ignored.
HS-EVID-001 Demonstrated integration

Hash a redacted refund evidence document before proof storage

The refund worker computes SHA-256 over the canonicalized redacted in-memory evidence document and stores that digest beside a logical haltstate:// artifact URI in a Proof Pack.

Enforcement point
After the governed workflow has a final decision and before the demonstrated refund execution is recorded.
Evidence link
/live/
Customer responsibility
Supply accurate redacted evidence, independently verify exported evidence when integrity assurance is required, and retain records according to policy.
Control limitation
The artifact URI is logical and the verifier does not recompute the embedded action-evidence hash. The live page demonstrates Proof Pack integration only, not evidence integrity. This is not a digital signature, external timestamp, immutable store, or legal certification.
HS-REDACT-001 Demonstrated integration

Expose a bounded sanitized refund projection

For allowlisted refund events, publish a fixed refund parameter and result subset while preserving the event action and status last_action labels.

Enforcement point
Public live-status and feed serialization.
Evidence link
/live/
Customer responsibility
Use controlled non-sensitive action labels and review access control and redaction for private exports and customer-specific fields.
Control limitation
The refund params and result fields use a bounded allowlist, but action and last_action are passed through from caller-controlled event and status data. Integrators must use controlled non-sensitive action labels. This does not establish redaction for private exports or arbitrary non-refund fields.
HS-STOP-001 Customer integration required

Receive an external kill-switch signal

Let a credentialed integrated agent poll for a tenant- or agent-scoped kill signal outside its own reasoning loop.

Enforcement point
Agent heartbeat or customer integration checkpoint.
Customer responsibility
Poll with tenant credentials, obey kill or pause status, and operate a tested pause, rollback, or recovery procedure appropriate to the protected system.
Control limitation
Kill-switch activation uses a 3,600-second (one-hour) TTL. The heartbeat protocol returns OK, PAUSE, or KILL, returns OK on backend-check failure, and gives unauthenticated legacy polling only a status-only OK. The customer agent must poll and obey it; HaltState does not force termination, roll back completed actions, or return customer systems to a safe state.
Public evidence and implementation detail

Inspect one governed business workflow and the integration contract.

APP entity implementation checklist

Turn technical records into an owned privacy-readiness workstream.

  1. Inventory programs and decisions.Name each program, decision, automated step, owner, integration, affected person, and business outcome.
  2. Map personal information.Identify the kinds of personal information used by each program and verify the data flow outside HaltState.
  3. Assess significant effects.Have privacy and legal owners determine which decisions can significantly affect rights or interests.
  4. Close integration gaps.Route every selected action through an active guard and remove unguarded side-effect paths.
  5. Reconcile outcomes.Bind decisions, approvals, execution results, corrections, complaints, and retention in customer-owned records.
  6. Draft and validate disclosure.Use the verified inventory to support, but never substitute for, legal review and APP Privacy Policy publication.
Responsibility boundary

HaltState supports selected action evidence; the APP entity owns privacy compliance.

  • HaltState does not determine whether APP 1.7 applies and does not discover personal information use, unintegrated programs, or unguarded actions.
  • Agent identity is caller-supplied agent attribution, not cryptographic workload identity or proof of the accountable human principal.
  • Expired trials, policy-load failures, and no matching rule include paths that can default to ALLOW.
  • Human approval is not itself an APP 1.7 to 1.9 statutory requirement; it is optional operational context where a workflow uses it.
  • Outcome reporting is best-effort. The demonstrated proof evidence is refund-specific, not a complete automated-decision record or immutable audit store.
  • HaltState does not draft or validate an APP Privacy Policy, provide privacy notices, or operate access, correction, complaint, retention, and regulator-response processes.
Readiness engagement

Australia ADM Evidence Readiness Sprint

Map one automated-decision workflow across program scope, personal-information use, decision categories, significant effects, guarded actions, human intervention, outcomes, disclosure ownership, and verified evidence gaps.

Primary sources

Enacted APP amendments, OAIC material, and voluntary Australian Government guidance

Last verified 27 July 2026. Reconfirm official text and guidance before making privacy, legal, or deployment decisions.

APP 1 automated-decision transparency amendments

Guidance for AI Adoption