digital-lock
Provisional article — seeded from NbLM. Requires Andrew's research to verify and expand.
Grounding Summary
Flexible supports allow participants to choose any item code within a funded category, while Stated supports restrict the budget to specific categories or item codes. A Digital Lock is an additional mechanism within the PACE system that ring-fences funds to a single, specific line item — such as Specialist Support Coordination or Occupational Therapy — preventing the money from being repurposed.
Detail
These concepts are crucial for NDIS support coordinators because they provide the primary architectural tools to proactively manage participant risk. By recommending whether a category should be flexible or digitally locked, coordinators can safeguard vulnerable participants from financial exploitation, provider over-servicing, and ensure that critical therapeutic interventions are preserved. These concepts form the foundational structure of "Block 3: PACE Budget Architecture Recommendations" within the Participant Statement Toolkit.
The Flexible-by-Default Rule
Under the NDIS Act, funding within the Core and Capacity Building categories is designed to be flexible by default. Participants generally have the freedom to allocate funds across various supports without rigid restrictions, unless specific safety or financial risks are identified. Digital Locks are the exception to this rule — applied only when there is a documented risk that requires a specific item code to be ring-fenced to a specific provider's ABN.
Exception-Based Approach vs. Exhaustive Ledger
Earlier template models forced coordinators to tabulate every support line item for its digital lock or stated status — an exhaustive ledger approach identified as administrative overkill. The exception-based approach simplifies this: coordinators leave flexible things alone and only complete the budget controls section when a high-risk exception requires a Stated designation or Digital Lock. This means practitioners only do the heavy lifting in the budget section when a participant's safety genuinely requires it.
How Coordinators Document Risk to Justify a Digital Lock
To recommend a Digital Lock in the Participant Statement (Block 5), coordinators must document three elements for the NDIA planner:
- Support / Item Code: The exact PACE item code requiring restriction (e.g., 01_045_0115_1_1)
- Control Requested: The specific architectural control (e.g., "Digital Lock to Provider X ABN")
- Risk Rationale: A clear justification explaining the vulnerability — for example, a participant has a history of exploitation by unregistered providers and funds must be locked to their current specialised SIL provider to ensure continuity of life-sustaining care
The "Exact Multiple" Heuristic and Its Limitations
Providers have historically used a heuristic to infer whether a participant's Category 07 budget is digitally locked to a specific support: checking whether the budget total is an exact mathematical multiple of a known hourly rate. If the budget divides cleanly, the logic suggests it was constructed with a specific line item in mind. RS-05 research (T6) confirms this heuristic is fragile and should not be relied upon. NDIA planners routinely include small buffers for activity-based transport or partial hours in the budget, which breaks the clean multiple without changing the underlying intent. This produces false negatives — a locked budget that doesn't resolve to a clean multiple — leading providers to attempt claims that will be rejected.
PACE replaces this heuristic. Under the PACE system, providers can reference the explicit "Support Detail" section of the participant's plan, which specifies which line items are approved. This makes the mathematical heuristic redundant. Providers are advised to empirically test PACE claim validation behaviour through a controlled claim attempt rather than inferring it from the budget total. The "exact multiple" check remains relevant only for Legacy (MyPlace) plans where the Support Detail section does not exist.
Risk-Profile-Driven Lock Recommendations
RS-07 research introduces the Participant Risk Profile as the formal input that drives digital lock recommendations. Practitioners can no longer merely submit support lists — they must actively assess a participant's vulnerability profile and make explicit, evidence-based recommendations to the NDIA planner about which specific supports require ring-fencing.
The granularity of digital locks in PACE is significant: a lock can be applied to an entire Support Category or drilled down to a specific line item. A line-item lock on Specialist Support Coordination (R132) ensures that critical, specialised funds cannot be absorbed into general capacity building. A category-level lock on Category 07 ring-fences coordination funding from other uses. Practitioners should match the lock granularity to the specific risk identified — broader category locks for general exploitation vulnerability, specific line-item locks for critical therapeutic interventions that must be preserved.
Specific Planner Instructions — The PACE Lock Mechanism in Detail
RS-09 research (T1, T3) provides the portal-level anatomy of how PACE actually implements digital locks, adding operational depth beyond the RS-06 findings about the Allocated Items table.
In PACE plans, the primary lock mechanism is the Specific Planner Instructions text embedded in the "Support Details" section — not the Allocated Items table itself. The instructions follow a two-part pattern: generic boilerplate followed by a unique participant-specific sentence. That second sentence is the operative lock. Providers must parse it to determine which item codes are permissible:
| Instruction Wording | Effect |
|---|---|
| Mentions "Support Coordination" only | Default R106 flexibility — Level 1, Level 2, and PRC all accessible |
| Mentions "Specialist Support Coordination" | Opens R132 — Level 3 enabled alongside standard R106 supports |
| Mentions both | Configuration C — dual-budget scenario requiring internal sub-budget tracking |
The Allocated Items table surfaces the result (Stated vs. Flexible labels), but the Specific Planner Instructions are the cause. Understanding the textual mechanism — not just the portal warning — is essential for providers who need to reason about edge cases before making a claim attempt.
The natural R132 lock adds a third dimension: Level 3 Specialist Support Coordination carries a structural digital lock by virtue of its R132 registration requirement. Even without a formal "Stated" designation, providers who do not hold R132 cannot bill Level 3 regardless of budget availability. When a planner does formally state Level 3, they are layering an explicit budget lock on top of the pre-existing registration lock.
PACE "Allocated Items" Table and Explicit Lock Warning
RS-06 research (T2) adds important operational detail about how PACE enforces locks. PACE plans feature a prominent "Allocated Items" table that explicitly categorises each support as stated or flexible. When a support is listed with a "Stated" status, the PACE portal displays an explicit warning: "Stated supports are intended solely for the purpose of that support" — they cannot be swapped for other supports.
When a digital lock is applied at the item-code level — for example, if 100% of a Category 07 budget is allocated exclusively to Level 2 Coordination (07_002_0106_8_3) — the portal ring-fences those funds to that specific code. Attempts to claim other items within the same category, including the standard non-labour travel code (07_799_0106_6_3), will be rejected with "Insufficient Funds" or "Support Not in Plan" errors because the portal sees $0 flexible budget available for those items.
Cross-Category Bypass When Category 07 Is Locked
RS-06 research (T5) identifies a compliance-approved workaround for providers facing locked Category 07 budgets who still need to claim non-labour travel costs. The NDIS Pricing Arrangements and Price Limits 2025-26 V1.1 explicitly validates item code 01_799_0106_1_1 — a Category 01 (Core) code under Registration Group R106. Because this code draws from the participant's Core budget rather than Capacity Building, it bypasses the Category 07 lock entirely.
To use this workaround:
- The participant must have available flexible funds in their Core (Category 01) budget
- The cross-category billing arrangement must be explicitly agreed to in the participant's Service Agreement
- The provider must hold R106 registration (the code is R106-specific)
Legislative Basis
| Reference | Provision | Relevance |
|---|---|---|
| NDIS Act 2013 s33(2A)(b) | Support categorisation | Mandates the categorisation of reasonable and necessary supports into one or more groups of supports. |
| NDIS Act 2013 s33(2A)(c) | Funding amounts | Requires specifying a funding component amount for each group of supports. |
| NDIS Act 2013 s33(2)(d) | Funding management | Relates to the management of the funding for supports under the plan. |
Related Articles
- concepts/support-categories — enables
- concepts/funding-periods — requires
- concepts/stated-supports — references
- concepts/flexible-supports — references
- topics/operationalizing-support-coordinator-role — identified by
- sources/RS-02-T6-operationalizing-support-coordinator-role-2026-04-18.md — source
- topics/2024-ndis-funding-budget-amendments — discussed by
- topics/bridging-legacy-systems-pace-framework — discussed by
- topics/pace-claim-validation — discussed by (RS-05 T6: confirms "exact multiple" heuristic fragility and PACE Support Detail replacement)
- topics/item-code-billing-accuracy — discussed by (RS-05 T1: digital lock hypothesis and PACE validation mechanics)
- topics/risk-based-budget-controls-exceptions — discussed by
- topics/master-template-architecture — discussed by
- mapping-goals-to-ndis-architecture — discussed by
- collaborative-framing-participant-statements — discussed by
- managing-template-technicality-and-complexity — discussed by
- topics/pace-vs-legacy-plan-flexibility — discussed by (RS-06 T2: PACE Allocated Items table mechanics, explicit Stated warning, "Insufficient Funds" rejection pattern)
- topics/registration-group-ring-fencing — discussed by (RS-06 T4: Stated digital lock protecting Level 3 R132 allocation from lower-tier depletion)
- topics/cross-category-provider-travel-costs — discussed by (RS-06 T5: cross-category Core bypass when Category 07 is locked)
- topics/pace-budget-risk-architecture — discussed by (RS-07 T6: digital locks as configurable participant risk management in PACE)
- topics/evidencing-environmental-context-limits — discussed by (RS-07 T4: risk profile documentation feeds lock recommendations)
- Quasi-Legislative Pricing Arrangements and Operational Requirements — related (RS-08 T4: PAPL and digital lock enforcement are binding through service agreements)
- topics/legacy-pace-plan-flexibility — discussed by (RS-09 T1: portal anatomy of Specific Planner Instructions vs. Allocated Items — how each system applies and decodes digital locks)
- topics/digital-lock-mechanism — discussed by (RS-09 T3: side-by-side anatomy of Legacy Allocated Items and PACE Specific Planner Instructions; R132 natural lock layer)
- topics/budget-tracking-limitations-pace — discussed by (RS-09 T2: category-level pooling in PACE portal means digital lock enforcement is partial — sub-budget tracking falls to providers)
Open Questions
- How does the PACE system (MyNDIS portal) technically validate and display a "Digital Lock" on a specific line item compared to a broader category-level Stated support?
- What specific standard of evidence or risk justification does an NDIA planner/delegate require to approve a requested Digital Lock on a Core support that would otherwise default to being Flexible?
- How do the "Specific Planner Instructions" documented in the PACE portal directly enforce these digital locks for item codes like Level 3 Specialist Support Coordination?
Entity Tags
entity: digital-locktype: Conceptdomain: Operationalconfidence: Provisional
Change History
| Date | Change | Source |
|---|---|---|
| 2026-04-20 | Provisional article created from primer during ingest of RS-02-T6-operationalizing-support-coordinator-role-2026-04-18.md | Auto-generated |
| 2026-04-23 | Backlinks added — referenced by RS-03 Themes 2, 6, 7, 8 | Auto-updated during ingest E-M5 |
| 2026-04-23 | E-M6 enrichment — flexible-by-default rule, exception-based approach, and risk documentation protocol added from RS-03 T7 | Sonnet E-M6 |
| 2026-04-25 | Backlinks added — topics/pace-claim-validation and topics/item-code-billing-accuracy (RS-05 T6, T1) | E-M5 |
| 2026-04-25 | E-M6 enrichment — "Exact Multiple" Heuristic and Its Limitations section added from RS-05 T6 | Sonnet E-M6 |
| 2026-04-27 | E-M5: Backlinks added — topics/pace-vs-legacy-plan-flexibility, topics/registration-group-ring-fencing, topics/cross-category-provider-travel-costs (RS-06 T2, T4, T5) | Sonnet E-M5 |
| 2026-04-27 | E-M6 enrichment — PACE Allocated Items warning text, "Insufficient Funds" rejection pattern, and cross-category Core bypass (01_799_0106_1_1) added from RS-06 T2 and T5 | Sonnet E-M6 |
| 2026-04-28 | E-M5: Backlinks added — topics/pace-budget-risk-architecture, topics/evidencing-environmental-context-limits (RS-07 T6, T4) | Sonnet E-M5 |
| 2026-04-28 | E-M6 enrichment — Risk-Profile-Driven Lock Recommendations section added from RS-07 T6 | Sonnet E-M6 |
| 2026-05-01 | E-M5: Backlinks added — topics/legacy-pace-plan-flexibility, topics/digital-lock-mechanism, topics/budget-tracking-limitations-pace (RS-09 T1, T3, T2) | Sonnet E-M5 |
| 2026-05-01 | E-M6 enrichment — Specific Planner Instructions portal anatomy, instruction-wording table, and R132 natural lock layer added from RS-09 T1/T3 | Sonnet E-M6 |