Compliance Summary — RFI-15434

One-page executive view of how SABLE meets the ATO’s Statement of Requirements. Reflects Addendum 1 clarifications.

Headline

42 / 55 requirements: Compliant today
13 / 55 requirements: Partially Compliant — all have explicit remediation paths with timelines
0 / 55 requirements: Non-Compliant

By category

Category	Compliant	Partially	Total
LV (Biometric Capture & Liveness Detection)	4	2	6
TV (Technical Verification & Biometric Binding)	1	2	3
S / P / A (Scalability / Performance / Availability)	5	0	5
H / IN (Hosting / Integration)	5	2	7
SC (Security & Confidentiality)	5	3	8
OP / VISM / M (Operations / Vendor Implementation / Maintainability)	15	3	18
RM (Reporting & Monitoring)	4	0	4
UX (User Experience & Accessibility)	3	1	4
Total	42	13	55

Where SABLE wins decisively

SC-2 (APPs), SC-5 (no PI offshore) — biometric data never leaves the device. Privacy is structural, not procedural. No other respondent of statistical-match architecture can match this guarantee.
LV-3 / LV-4 (PAD + single-pipeline) — Halo2 composite proof binds capture, PAD, and proof generation cryptographically. Cannot be decoupled or replayed.
TV-2 (online biometric binding) — single continuous on-device workflow binds biometric, PAD, and credential.
P-1 (10 k verifications/hr @ p95 ≤ 1000 ms) — three orders of magnitude headroom at ~1.8 ms verification.
S-1 / S-2 / H-1 / H-2 / IN-3 / IN-4 — clean stateless SaaS on AWS Sydney with PrivateLink + IaC deployment.
SC-7 (Australian data residency) — AWS ap-southeast-2 only, enforced by SCPs.
UX-1 / UX-2 / UX-4 — mobile-first, customisable, Figma library.

Where SABLE has known gaps (with timelines)

Gap	Effort	Spend (indicative AUD)
ISO/IEC 30107-3 EAL-2 (L) PAD test (LV-5/6)	3-4 months	60-100 k
FMR/FNMR benchmark (TV-3)	4-6 weeks	self-funded
ICAO 9303 ePassport NFC (TV-1)	8-12 weeks	self-funded
MAUI bindings (IN-1)	4-6 weeks	self-funded
WCAG 2.1 AA audit (UX-3)	4-6 weeks	self-funded + audit fee
HACE alternative crypto path (SC-3)	4-8 weeks	self-funded
IRAP PROTECTED certification (SC-1/6)	6-8 months	150-250 k
NV1-cleared Australian support (OP-9)	12+ months for direct / immediate via partner	partner cost
Insider-risk monitoring (OP-6)	partner integration	partner cost
Government track record (IN-5 / VISM-6 / OP-10)	Paid PoC against ATO myID cohort	TBD

Total remediation programme: ~12 months elapsed across the longest dependencies, ~AUD 250-500 k in pass-through certification spend, plus internal engineering.

The four distinctive pillars

Privacy by construction — biometric data never leaves the user’s device; cryptographic guarantee, not policy promise. Structurally fits Digital ID Act 2024 data-minimisation.
Selective disclosure via BBS+ — predicates provable without exposing underlying credential fields.
Offline P2P operation — capture / liveness / proof runs entirely on-device with no internet dependency; addresses inclusivity for low-connectivity / offshore users.
Open-source public good — Apache 2.0 library; investment in maturing SABLE becomes freely available to any other government adopter at zero marginal cost. Candidate future deployment contexts: Anuna’s existing BARMM (Philippines) eGov engagement (natural extension; SABLE not yet deployed there), European public-sector identity (early dialogue with Germany’s BSI), other Pacific / SEA governments, and adjacent use cases (age verification, healthcare, building access). Aligns with Pacific Step-Up, Indo-Pacific Endeavour, ASEAN digital cooperation, and the Quad’s cyber resilience agenda — additional public value the ATO can claim from the procurement spend.

To our knowledge SABLE is the first open-source library to combine all four alongside transparent ZK setup (no trusted ceremony) and no special hardware requirement.

Other strategic value beyond the requirements

Post-quantum roadmap — CRYSTALS-Dilithium / hash-based commitment migration path published
Open-source auditability — full source review available; no vendor lock-in; source-escrow obviated

Recommended next step (suggested to the ATO)

A paid 8-week Proof-of-Concept against the ATO’s existing myID IP3 test cohort, evaluating:

PAD performance against a curated attack corpus (printed photos, phone screen replays, video replays, 3D masks)
FMR/FNMR against a representative Australian population sample
End-to-end UX of the spatial-flash liveness flow (capture time, completion rate, accessibility)
Integration latency to ATO’s existing FVS / DVS infrastructure via PrivateLink
Operational soak test at 10× the current peak-hour verification load

This is the most decisive evidence either party can generate inside the RFI’s question of “what new capabilities exist in the market that could enhance the security, scalability, and inclusivity of myID”.

See sable-fit for the per-requirement detail, gaps-and-risks for the consolidated remediation plan, ato-myid-context for the strategic framing.

Linked Pages

ato-myid-context

ATO myID Context

Context for the RFI: what myID is today, where it’s heading, and how a SABLE-class capability complements rather than replaces the existing stack.

What myID is today

Australia’s national Digital ID Provider under the Digital ID Act 2024 (commenced 1-Dec-2024)
An app installed on the user’s smart device — they prove who they are once and log in to government online services thereafter
14 M+ users; 6 M+ at IP3 (Strong) identity proofing
95 M+ uses across 12 months (Aug 2024 – Aug 2025) across 240+ government online services
Three identity-proofing (IP) levels today:
- IP1 (Basic) — verified email + self-asserted name + DOB
- IP2 (Standard) — verified email + name + DOB via 2 documents through DVS
- IP3 (Strong) — verified email + name + DOB via 2-3 documents through DVS + face biometric against source document (Australian Passport / Driver Licence) via FVS
Future IP levels per Digital ID Act:
- IP1+ — 1 document via DVS
- IP2+ — 2 documents via DVS + face biometric (where Passport not used) via FVS, with a liveness check

What the ATO is looking to evolve

“Since the launch of Strong myID in 2021, the technology landscape for identity verification has evolved significantly… To ensure myID continues to meet the highest standards of security, usability, and inclusivity, the ATO is seeking information from technology providers on their capabilities to support future enhancements.”

Three concrete capability streams:

Liveness detection & facial image capture — refresh of the 2021-procured liveness stack
Biometric matching — enable login / account recovery without manual re-proofing (today’s IP3 users sometimes have to re-prove via call-centre support → high cost, poor UX)
Technical verification of credentials — NFC-enabled verification of electronically readable identity documents (ePassports) so offshore users can verify with foreign Passports (today they can’t, because myID only verifies against Australian-issued documents)

Why this is a strategic moment

gaps-and-risks

Gaps & Risks — Honest Disclosure

Consolidated view of every requirement where SABLE is Partially Compliant today, what remediation is needed, and what timeline.

Certifications & accreditations (largest gap cluster)

ID	Gap	Remediation	Effort
LV-5 / LV-6	No ISO/IEC 30107-3:2023 EAL-2 (Level B) third-party PAD test report yet	Engage an ILAC-accredited PAD testing laboratory; no lab arrangement in place at RFI stage	3-4 months elapsed; ~AUD 60-100 k spend
SC-1	Full ISM / Essential 8 compliance evidence not yet produced for SaaS shell	Build SaaS to ISM controls from day 1; engage IRAP assessor	6-8 months elapsed (overlaps with SC-6)
SC-6	PROTECTED-level IRAP certification not yet held	Engage IRAP assessor; remediate findings; cert at PROTECTED	6-8 months elapsed; ~AUD 150-250 k spend
OP-9	No NV1-cleared Australian support staff today; no subcontractor arrangement in place	Sponsor founder NV1 clearance + subcontract via an Australian Security Vetting Agency–cleared support partner	12+ months for direct NV1; immediate via partner once contracted

All four are standard procurement-stage activities in Australian federal identity tech — none are blockers. The RFI explicitly notes evidence is not required at this stage; we acknowledge the work is needed and commit to completing it inside any second-stage timeline.

Technical gaps with clear remediation

ID	Gap	Remediation	Effort
TV-1	ICAO Doc 9303 ePassport PKI verification (with CRL checking) not in core	Add via existing OSS libs (jMRTD wrapper, Apache Santuario for PKI); design slot exists in `attestation` module	8-12 weeks dev
TV-3	Quantitative FMR / FNMR not measured against ISO/IEC TS 19795-9 protocol	Run formal benchmark against LFW / IJB-C / MS-Celeb-1M corpora; report at 90% CI	4-6 weeks
IN-1	Microsoft MAUI bindings not shipped (Android JNI / iOS Swift exist)	Generate via cbindgen → C ABI → MAUI .NET bindings + sample app	4-6 weeks
UX-3	WCAG 2.1 AA audit not yet performed	Engage an accredited Australian accessibility audit firm; remediate findings	4-6 weeks
SC-3	BLS12-381 not currently on ASD HACE catalogue	Either (a) ASD HACE assessment / acceptance pathway, or (b) provide parallel ASD-approved cryptographic path (e.g. P-256 + SHA-256 classical-only mode) for environments requiring strict HACE compliance	4-8 weeks for parallel path

Track-record gaps

ID	Gap	Compensating evidence
IN-5	SABLE specifically has no prior large-scale government deployments	(a) Anuna’s current BARMM eGov programme — government identity, citizen services, advisory, production go-live July 2026 — is the most directly relevant delivery-capability reference (BARMM does not currently deploy SABLE; future deployment a candidate natural extension); (b) early international dialogue on the SABLE approach with Germany’s BSI; (c) adjacent: GovUK, CSIRO Data61, Microsoft, Autodesk, Suncorp, IAG, Telus, Telefónica, Kellogg, University of Wollongong — references available on request; (d) Tang et al. NDSS 2018 published methodology with academic validations; (e) offer of a paid Proof-of-Concept against ATO’s myID test cohort as the most decisive direct evidence for SABLE specifically
VISM-6	No prior implementation of biometric identity systems in Australian federal government specifically	BARMM is direct government identity / eGov delivery by the same practitioner team (SABLE not yet deployed at BARMM); GovUK + CSIRO Data61 cover OECD public-sector posture; this would be Anuna’s first direct Australian federal identity engagement
OP-10	First direct Australian federal government identity-system delivery	As IN-5; BARMM (in production July 2026) provides the closest delivery-capability analogue — same practitioner team, same delivery shape; ATO would be Anuna’s first Australian federal engagement and SABLE’s first government deployment
OP-6	(Re-reading Addendum 1 Q14: requirement is for organisational controls, not clinical assessment)	Anuna has these — separation of duties, peer review, security-awareness training, privileged-access monitoring, incident-reporting runbooks. Now Compliant — see addenda-clarifications

Strategic risks (for ATO to weigh)

Risk	Mitigation
SABLE is pre-production; bugs / vulnerabilities possible	(a) Open-source, fully auditable; (b) 519 tests passing with 89% coverage; (c) commitment to a security audit (e.g. Trail of Bits, Kudelski) before any production cutover; (d) phased PoC → pilot → rollout deployment model
Halo2 is a 2020-2021 cryptosystem; comparatively new compared to legacy PKI	Halo2 has rigorous academic review; deployed at production scale by Zcash; transparent-setup eliminates the trusted-ceremony class of failures
BLS12-381 quantum-vulnerable by 2030-2035	Post-quantum migration on the published roadmap (CRYSTALS-Dilithium signature path; hash-based commitment alternatives); ATO’s deployment timeline likely aligns with industry-wide PQ rollout
Anuna Research Cooperative is a small Australian company	(a) Open-source codebase removes vendor-lock-in / business-continuity risk; (b) source-escrow agreement available; (c) partnership model with an Australian systems integrator acceptable for delivery scale if procurement warrants it (no such arrangement is in place at the RFI stage)

What this RFI is buying

The ATO is buying market intelligence and option value on innovative biometric solutions. SABLE’s distinctive value isn’t a 99 %-vs-95 % match-rate improvement — it’s privacy by construction, which the existing 2021-procured stack architecturally cannot offer. Even if the ATO ultimately proceeds with an incumbent for the SaaS reverification stack, SABLE’s on-device proof + selective-disclosure model is a strategic capability worth understanding for the next 5-10 years of Digital ID Act evolution.

Linked notes

sable-fit — per-requirement detail
evaluation-criteria — source requirements
ato-myid-context — why the strategic capability matters

sable-fit

SABLE Fit — Per-Requirement Position

Maps every M / D requirement in evaluation-criteria to SABLE’s current capability and the gap (if any). Source: ../sable/README.md, ../sable/IMPLEMENTATION_STATUS.md, ../sable/docs/. Compliance values use Part 3a’s drop-down options: Compliant / Partially Compliant / Non-Compliant.

Biometric Capture & Liveness Detection (LV)

ID	SABLE Position	Compliance	Commentary
LV-1	✅ SABLE captures face embeddings via standard smartphone camera; image-quality controls operate at capture time	Compliant	We extract 1024-dim face embeddings; image-quality scoring against ISO/IEC 29794-5 profile is integrated in the capture pipeline (sable-core `biometric` module). Quality profile output is exposed via the FFI.
LV-2	✅ Automated quality controls + UI guidance for re-capture	Compliant	The capture SDK rejects out-of-spec frames and returns user-facing guidance codes (face-too-close, low-light, off-axis, motion-blur). UI guidance text is configurable per ATO branding.
LV-3	✅ Spatial-flash PAD based on Tang et al., NDSS 2018	Compliant	Active liveness via screen-flash challenge-response. The screen flashes split-screen colours over 3 rounds; the camera captures how light reflects off the face. A real 3D face reflects differently in upper vs lower regions; a flat photo/screen reflects identically.
LV-4	✅ Capture + PAD in a single continuous workflow	Compliant	The Halo2 ZK proof binds capture and PAD into a single composite proof (~250 ms generation). The PAD fingerprints feed directly into the same circuit as the face-match check — they cannot be decoupled or replayed.
LV-5	⚠️ Defensible against current photo/screen replay attacks, but not yet ISO/IEC 30107-3 EAL-2 (Level B) tested	Partially Compliant	The technique (controlled-illumination reflectance analysis) is published peer-reviewed methodology; engagement of an ILAC-accredited testing laboratory for formal EAL-2 (Level B) certification is planned and can be completed inside a typical procurement timeline (3-4 months). No lab arrangement in place at the RFI stage.
LV-6	⚠️ Pending third-party PAD test report (see LV-5)	Partially Compliant	We will provide vendor self-assessment evidence now (NDSS 2018 paper, internal red-team testing against printed photos / phone-screen replays / video replays) and commit to producing an ISO/IEC 30107-3 third-party test report by end of any procurement evaluation phase.

Technical Verification & Biometric Binding (TV)

ID	SABLE Position	Compliance	Commentary
TV-1	⚠️ ICAO Doc 9303 ePassport NFC reading is not yet in SABLE core	Partially Compliant	The SABLE architecture has an `attestation` module designed for X.509-style chain validation; ICAO 9303 PKI verification including CSCA/Master List handling and CRL checking is a planned addition (estimated 8-12 weeks). Existing open-source libraries (e.g. jMRTD, BSI) can be wrapped.
TV-2	✅ Single-continuous-workflow capture + PAD + binding is the SABLE flagship feature	Compliant	The Halo2 composite proof binds biometric capture, PAD, and credential binding in one atomic operation. PAD operates at point of capture; the entire pipeline runs before any proof is submitted for verification. Data-capture-subsystem signals and system-level monitoring (frame timing, sensor metadata, challenge nonce binding) all feed the circuit per ISO/IEC 30107-1.
TV-3	⚠️ Quantitative FMR/FNMR benchmarking against ISO/IEC TS 19795-9:2019 protocol is planned	Partially Compliant	SABLE’s matching uses Pedersen-committed Poseidon-hashed embeddings with a configurable Hamming-distance threshold inside the Halo2 circuit. The underlying face embeddings are based on a 1024-dim feature extractor; matching accuracy depends on the embedding model. We commit to running an ISO/IEC TS 19795-9 evaluation against a standard test corpus and reporting FMR/FNMR at the 90 % confidence interval within the procurement evaluation window.

Scalability, Performance, Availability

ID	SABLE Position	Compliance	Commentary
S-1	✅ Architecturally horizontally scalable — verification is stateless	Compliant	Halo2 verification is ~1.8 ms per proof. The SaaS verification endpoint is stateless (no session affinity, no shared memory) and trivially horizontal — capacity scales linearly with EC2/EKS instances.
S-2	✅ A SaaS verification endpoint is the deployment target	Compliant	The proposed deployment wraps the open-source SABLE library in a hosted SaaS verification service on AWS Sydney. The library itself remains client-side (in the user’s myID app instance) — only the proof reaches the SaaS.
P-1	✅ 10 000 verifications/hour at p95 ≤ 1000 ms is comfortable	Compliant	10 000/hour = ~2.8/sec average; SABLE verification at 1.8 ms means a single t3.medium handles this with >99 % headroom. Proof generation (~250 ms, on-device) is amortised across millions of devices, not on the server. Full performance numbers in P-2 narrative.
P-2	✅ Documented benchmark methodology in `sable/bench/`	Compliant	We provide a Software Capacity Plan with: (i) measured verification latency distributions on Apple Silicon + AWS Graviton3 reference instances; (ii) AWS infrastructure design with EKS auto-scaling group + ALB; (iii) capacity-curve projection at 10×, 100×, 1000× peak.
A-1	✅ 99.95 % uptime achievable on AWS Sydney with multi-AZ design	Compliant	Multi-AZ EKS deployment behind ALB; data plane is stateless (no DB writes per verification); RTO < 5 min, RPO = 0. Bonus: SABLE’s on-device proof generation means the user-facing capture/liveness flow is 100 % available even if the SaaS endpoint is degraded — only final verification needs the SaaS.

Hosting, Integration

ID	SABLE Position	Compliance	Commentary
H-1	✅ SaaS wrapper on AWS Sydney	Compliant	Vendor-managed, secure, scalable. Library is open-source (Apache 2.0); SaaS shell + integration + ops is the commercial scope.
H-2	✅ AWS PrivateLink-ready	Compliant	We propose a VPC Endpoint Service in `ap-southeast-2` so the ATO’s AWS account connects to SABLE Verification API via PrivateLink — no internet egress, no public endpoint. Resources required from ATO: VPC Endpoint creation in their account, IAM cross-account role for telemetry export, DNS resolver entry.
IN-1	⚠️ MAUI bindings not yet shipped; Android JNI + iOS Swift are in core today	Partially Compliant	SABLE has FFI for Android (JNI) and iOS (Swift). Generating .NET/MAUI bindings on top of the C ABI (sable-core exposes via cbindgen) is mechanical and estimated at 4-6 weeks including sample MAUI integration project. We commit to delivering MAUI bindings inside a procurement evaluation phase.
IN-2	✅ Browser support via WASM Halo2	Compliant	The demo web frontend (`demo/web/`) already runs Halo2 proof generation in-browser via WASM, with camera capture via getUserMedia and spatial-flash liveness via the browser canvas. Verified working in Chrome, Safari, Edge, Firefox on desktop and mobile.
IN-3	✅ No server affinity required	Compliant	Stateless verification; any request can hit any pod. No sticky sessions.
IN-4	✅ IaC-driven deployment	Compliant	Deployment is fully IaC (Terraform modules provided); ATO can run `terraform apply` against their AWS account for fully silent deployment. CI pipelines provided (GitHub Actions templates).
IN-5	⚠️ SABLE specifically is pre-production; Anuna Research Cooperative is currently delivering directly-relevant government eGov work	Partially Compliant	SABLE itself is pre-production (519 tests passing; demo deployed; no live government deployments). Anuna is currently delivering eGov services for the Bangsamoro Autonomous Region in Muslim Mindanao (BARMM) — digital identity, citizen-facing services, advisory — production go-live July 2026 (so live well before any plausible ATO post-RFI procurement stage). BARMM does not currently deploy SABLE; future SABLE deployment at BARMM is a candidate natural extension of the existing engagement. Early international dialogue on the SABLE approach is under way with Germany’s Bundesamt für Sicherheit in der Informationstechnik (BSI). Adjacent government-context engagements: UK Government Digital Service (GovUK); CSIRO Data61. Adjacent large-scale enterprise: Microsoft, Autodesk, Suncorp, IAG, Telus, Telefónica, Kellogg, University of Wollongong. PoC against ATO’s myID cohort offered as the most direct evidence for SABLE in the ATO-specific context.

Security & Confidentiality

ID	SABLE Position	Compliance	Commentary
SC-1	⚠️ ISM / Essential 8 alignment work to be done	Partially Compliant	The SaaS shell will be designed against ISM and Essential 8 from day one (multi-factor admin auth, application allow-listing, patch-management cadence, daily backups, etc.). Full IRAP assessment is a procurement-stage activity.
SC-2	✅ Privacy by construction	Compliant	SABLE’s defining property is that biometric data never leaves the user’s device. APP 1 (open and transparent management): open-source codebase. APP 3 (collection of solicited PI): we collect only the ZK proof + minimal metadata, never the biometric. APP 11 (security): biometric data is committed-and-hidden in Pedersen commitments; even an SaaS breach exposes no biometric data.
SC-3	⚠️ Uses NIST-aligned primitives, ASD HACE catalogue review pending	Partially Compliant	SABLE uses BLS12-381 (128-bit security), Poseidon (peer-reviewed ZK-friendly hash), ChaCha20-Poly1305 (NIST/ISM-listed). BLS12-381 itself is not yet on the ASD HACE list but is widely deployed and aligned with NIST proposals. We commit to replacing any primitive that fails ASD/IRAP review with an ASD-approved equivalent (e.g. P-256 with SHA-256 in pure-classical mode, alongside the BLS12-381 ZK path).
SC-4	✅ Halo2 proof IS the integrity control	Compliant	The Halo2 ZK proof cryptographically binds (a) the captured biometric, (b) the PAD liveness fingerprints, (c) the session-binding nonce, and (d) any selectively-disclosed credential attributes — a single ~2 KB proof. Tampering with any component invalidates the proof.
SC-5	✅ Personal Information never crosses the boundary at all	Compliant	Biometric PI never leaves the user’s device. Only the ZK proof, the session nonce, and (optionally) selectively-disclosed predicates traverse the network. ATO’s SaaS endpoint receives no PI.
SC-6	⚠️ PROTECTED certification not yet held	Partially Compliant	We commit to engaging an IRAP assessor for PROTECTED-level certification of the SaaS shell + integration within the procurement evaluation phase. Open-source codebase + minimised attack surface (no PI server-side) materially simplifies the IRAP path.
SC-7	✅ AWS ap-southeast-2 (Sydney) hosting	Compliant	All operational data (verification logs, audit trail, configuration) hosted in `ap-southeast-2`. Data Hosting Certification Framework: AWS Sydney holds the Certified Strategic Hosting Provider classification.
SC-8	✅ Full SBOM provided	Compliant	Open-source SBOM produced via `cargo cyclonedx`; every dependency, license, and access scope documented. Third-party components: Halo2 (PSE/zcash), Poseidon (academic), ChaCha20-Poly1305 (RustCrypto).

Operations, Vendor Implementation Support & Maintenance, Maintainability

ID	SABLE Position	Compliance	Commentary
OP-1	✅ Standard SaaS architecture	Compliant	dev / staging / prod environments, all monitored 24×7 via CloudWatch + PagerDuty integration.
OP-2	✅ CI/CD with ephemeral test environments	Compliant	GitHub Actions pipelines spin up per-PR test environments via Terraform; integration tests run automatically.
OP-3	✅ AWS Sydney + CloudWatch Service Health	Compliant	Data sovereignty enforced via IAM SCPs preventing replication outside `ap-southeast-2`; real-time status via internal CloudWatch + public status page.
OP-4	✅ CloudTrail + GuardDuty	Compliant	All access to ATO data and all privileged operations logged via CloudTrail; GuardDuty monitors for anomalous patterns.
OP-5	✅ ATO IP allow-list at VPC PrivateLink	Compliant	Access enforced at the VPC endpoint level + at the API authentication layer (mTLS); IP ranges configurable per environment.
OP-6	⚠️ Personnel coercion-detection is a specialist domain	Partially Compliant	We do not currently operate behavioural-analytics tooling for personnel monitoring. We will partner with an Australian managed-SOC provider for managed insider-risk detection if required (no such arrangement in place at the RFI stage), or accept this as a desirable-not-met.
OP-7	✅ Real-time alerting on biometric failure patterns	Compliant	EventBridge → SNS → PagerDuty for high-risk patterns (PAD failure clusters, brute-force enrolment attempts, geographic anomalies).
OP-8	✅ Tiered alerting via severity tags	Compliant	Critical / High / Medium / Low alert tiers route to different channels with different SLAs; data-loss-prevention covered by abnormal-access detection on the verification API.
OP-9	⚠️ NV1-cleared staff and iRAP-certified portal not yet held	Partially Compliant	Anuna Research Cooperative will engage an Australian Security Vetting Agency–cleared support subcontractor for NV1-cleared L2 support, and sponsor founder NV1 clearance in parallel, inside a procurement evaluation phase. Incident management via an IRAP-assessed Australian incident management portal. No subcontractor or portal arrangement is in place at the RFI stage.
OP-10	⚠️ No prior government identity-system deliveries (see IN-5)	Partially Compliant	We offer: (a) dedicated helpdesk with named L2/L3 engineers; (b) public fraud-prevention roadmap; (c) knowledge-transfer commitment via documentation, on-site workshops, and pair-programming during transition. We acknowledge limited prior government identity-system delivery history (see IN-5).
VISM-1	✅ Helpdesk via dedicated email + status page	Compliant	Tiered support (P1/P2/P3/P4) with SLA-bound response times; AusGov.au-hosted ticketing portal.
VISM-2	✅ Open-source documentation + ops runbooks	Compliant	All `docs/` is public; ops runbooks for the SaaS shell will be ATO-private and version-controlled.
VISM-3	✅ Monthly security patch cadence, weekly minor updates	Compliant	Documented patching schedule; CVE response SLA: 4 hours triage / 24 hours patch for Critical, 7 days for High.
VISM-4	✅ Ongoing maintenance is the commercial subscription scope	Compliant	Subscription tier includes platform maintenance, dependency patching, ZK circuit revisions as cryptographic best practice evolves.
VISM-5	✅ Public roadmap	Compliant	Codeberg-hosted public roadmap; quarterly stakeholder review cycles. Items already on roadmap: BBS+ selective disclosure rollout, post-quantum migration (CRYSTALS-Dilithium signature path), multi-spectral liveness (IR), continuous authentication.
VISM-6	⚠️ Limited government track record (see IN-5, OP-10)	Partially Compliant	Honest disclosure. We propose a paid PoC against ATO’s myID test cohort as the most decisive evidence.
VISM-7	✅ Active research programme	Compliant	Anuna Research Cooperative publishes on identity, biometrics, and digital trust. Recommendations include: BBS+ for selective disclosure; post-quantum identity (NIST PQC integration); zero-knowledge KYC; offline-first identity proofs.
M-1	✅ Patching is a published SLA commitment	Compliant	See VISM-3. Third-party components are tracked via `cargo audit` in CI; out-of-date dependencies block merges.

Reporting & Monitoring, User Experience & Accessibility

ID	SABLE Position	Compliance	Commentary
RM-1	✅ CloudWatch Logs with optional log-shipping to ATO’s SIEM	Compliant	All API activity, configuration changes, and security-relevant events logged; Kinesis Firehose for ATO log-shipping.
RM-2	✅ CloudWatch / Grafana dashboards	Compliant	Out-of-the-box dashboards for: capture-time distribution, PAD pass/fail rates, FMR/FNMR over time, regional latency, error rates. ATO can customise via Grafana.
RM-3	✅ ATO read access via IAM cross-account roles	Compliant	Cross-account read role for ATO to query CloudWatch Logs Insights directly; sample CloudWatch Logs Insights queries provided in the runbook.
RM-4	✅ Monitoring integration options documented	Compliant	Native integration with: CloudWatch (default), Datadog (via Lambda), Splunk (via HEC), ATO’s existing SIEM (via log-shipping).
UX-1	✅ Mobile-first capture flow + responsive web fallback	Compliant	Native iOS / Android first-class; responsive web demo verified on phones, tablets, desktops.
UX-2	✅ UI standards + Figma + user-flow docs	Compliant	Brand-customisable UI; Figma library; user-flow maps for enrolment, authentication, account recovery, error states.
UX-3	⚠️ WCAG 2.1 AA audit not yet completed	Partially Compliant	Capture flow uses standard form patterns + ARIA labels + sufficient contrast ratios. Formal WCAG 2.1 AA audit by an accredited Australian accessibility audit firm is planned and can be completed in 4-6 weeks (no audit firm arrangement in place at the RFI stage). Accessibility-mode liveness alternative (audio prompts, larger UI elements) on roadmap.
UX-4	✅ Customisable UI via configuration	Compliant	Branding (colours, fonts, logos), copy (multi-language), capture flow steps, and even challenge parameters are configuration-driven, not code changes.

Cross-cutting business-requirement narrative

Secure — Halo2 ZK proof gives cryptographic guarantees stronger than any statistical match-rate threshold. Spatial-flash PAD defeats current photo/screen/replay attacks; ongoing R&D into deepfake / 3D-mask defences. FMR/FNMR benchmarking against ISO/IEC TS 19795-9 commitment per TV-3.
User-friendly — Capture flow is ~10 seconds (face capture + 3 spatial-flash rounds); no special device required; no internet required for capture; biometric data never leaves device.
Device compatibility — Any smartphone with a front-facing camera and modern browser; specifically tested on iOS 14+, Android 9+, Chrome / Safari / Edge / Firefox.
Accessible — WCAG 2.1 AA commitment (UX-3); accessibility-mode liveness alternative on roadmap; multi-language support.
Scalable — Stateless verification at ~1.8 ms; capacity scales linearly with EKS pods.
Cost-effective — Open-source library means no per-seat ZK proof licence; commercial scope is SaaS shell + integration + ops. Pricing model in Part 4a covers both perpetual and subscription tiers.
Compliant — Aligned with Digital ID Act 2024 data-minimisation principles by construction; ISM / Essential 8 / Australian Privacy Principles addressed in SC-* responses.
Integratable & maintainable — MAUI bindings (IN-1, 4-6 weeks); IaC deployment (IN-4); public SBOM (SC-8).
Value for money — The privacy-by-construction architecture removes the need for expensive ongoing breach-mitigation, data-sovereignty audits, and consent-management infrastructure that traditional biometric solutions accrue over their lifecycle.