http://github.com/dylang/node-rsssite-lib/media/favicon.pngWebpage HTML Export plugin for ObsidianMon, 18 May 2026 02:55:04 GMTMon, 18 May 2026 02:55:04 GMT60Product Brief - NDIS Wiki - Stage 3 Enriched — The purpose and scope of the NDIS Wiki product. Explains who benefits, how, and what done looks like.
Product Brief - Participant Statement Toolkit - Stage 3 Extract — The Participant Statement Toolkit: NAVV's first pilot product. The baseline for Andrew's ongoing requirements work.
NAVV Wiki - Waterline Taxonomy and Information Architecture v3 — How the wiki is structured, and why this three-tier architecture was chosen.
Maturity Mud Map - Wiki to Web Transition — The development pathway: where the project started, where it is, and where it is heading.
Prototype Specification - v7 - 2026-04-14 — The reverse-engineered specification of Andrew's v7 prototype. The baseline from which all governed development proceeds.
P3-Index — Entry point to the P3-Governance tier: the constitutional framework, programme principles, and strategic records that govern all NAVV work. The content in this wiki was developed through the collaboration between you, Brian, and a set of AI research and synthesis tools. Your contribution — the practitioner knowledge, the sector experience, the requirements you have developed through NotebookLM — is what makes this material grounded in real-world need rather than theoretical design.When you review a document here and have a question or concern, raise it in NotebookLM as you normally would. The feedback loop is working.This wiki is a living record. It reflects where the project is now — not where it started, and not yet where it is going.]]>index.htmlindex.mdSun, 17 May 2026 04:16:05 GMTNAVV-2026-05-10 Item 2.
References: P3 Programme Guidance Section 4 (Programme Artefact Map), Section 6 (Practical Step-by-Step)Date: 2026-05-10This gap analysis was performed to identify missing strategy documentation for the IFC build-out within the P3 programme. It documented why the Strategy Dossier was necessary and commissioned the formal Strategy Dossier that now resides in P3-Governance. The analysis established the rationale for governance investments.
CITES: navv-principles-register — Cites the Principles Register as the source of the four corridor-wall principles for the IFC Programme (PR-A001, PR-R001, PR-I003, PR-I001); identifies the attribution gap (principles not linked to IFC Dossier ID) and recommends the lightweight fix once the Dossier ID exists
SUPPORTS: strategy-dossier-ifc — Identified the critical absence of a formally issued Strategy Dossier (Step 1 in the priority sequence, blocking all other artefacts) and provided the recommended action — approve content, assign ID, rename, and file in P3-Governance/Strategy/ — that directly led to the commissioning and filing of SD-IFC-2026-001
SUPPORTS: factory-charter-ifc-build-out — Identified the Factory Charter as a high-priority critical gap (Step 3) blocked on Strategy Dossier issuance; articulated what the Charter must contain (binding Dossier ID, named Factory, bounded scope, epoch dates) and flagged the P3-Governance/ folder structure gap (Q-022); provided the rationale basis for Charter creation
SUPPORTS: saga-ifc-build-out — Identified the IFC Saga as a critical gap (Step 4) dependent on Charter issuance; established that pre-Charter work (v1–v7 prototype, NbLM extraction, brief production) should be captured in a founding Saga entry to give the Programme an accurate operational record from inception This document's conclusions are based on the state of referenced artefacts at the time of authorship. Subsequent changes to dependencies may affect applicability.
Purpose: Systematic review of artefacts required for a P3-compliant Programme (Strategic Bundle) at the IFC level, against current state. Produced in response to NAVV-2026-05-10 Item 2.
References: P3 Programme Guidance Section 4 (Programme Artefact Map), Section 6 (Practical Step-by-Step)Date: 2026-05-10
According to P3 Programme Guidance, a Programme requires the following eight artefact types:Status: Critical Gap — draft only, not formally issued
IFC Strategy Brief - Stage 3 Strategy Pass exists in Droppings/ as a working paper. The content is complete and passes the P3 Minimum Viable Strategy six-part filter. However three structural gaps prevent it from functioning as a formal Dossier: No Strategy Dossier ID has been assigned — the binding key that every downstream artefact must cite The document has not been filed in P3-Governance/Strategy/ The name "IFC Programme Brief" is ambiguous — in P3, this document IS the Strategy Dossier, and naming it "Brief" risks confusion with the Product Brief artefact class Recommended action: Brian approves the content; assigns a Dossier ID (format to be confirmed — see Q-021); the document is renamed and filed in P3-Governance/Strategy/. The filing act IS the issuance — from that moment, the IFC Programme exists as a P3 Strategic Bundle.Priority: Critical. Nothing else can be correctly attributed to the IFC Programme until this ID exists. All seven remaining artefact types are blocked on this.Status: Partial — Principles Register exists, IFC attribution does not
NAVV Principles Register - 2026-05-08 contains all active principles. The IFC Strategy Brief identifies four foregrounded for this Programme as corridor walls:Gap: The Principles Register is portfolio-level. Individual principles are not attributed to the IFC Dossier ID.Recommended action: The most lightweight P3-compliant approach is to update these four Principles Register entries to cite the IFC Dossier ID. Full separate Dossier documents are not required at this maturity level.Priority: Low — simple update once Dossier ID exists.Status: Partial — patterns documented, not attributed to IFC
Product Patterns and Workflow Patterns exist as NAVV-wide pattern libraries. These are general rather than IFC-specific.Gap: No patterns cite the IFC Dossier ID.Recommended action: Low-priority. Attribution can be added as a simple update to each pattern used within the IFC Programme, once the Dossier ID exists.Priority: Low.Status: Adequately covered
NAVV Maturity Assessment - 2026-05-08 provides the baseline. The IFC Strategy Brief's Strategy Sieve (Section 3) applies it directly: two Now elements (compliance and governance infrastructure), five Grow elements (all five component tools), one Recalibrate element (scale). This constitutes the Maturity Epoch Assessment for the IFC build-out epoch.Gap: The Maturity Assessment is not cited within the Strategy Dossier as the corridor-width instrument.
Recommended action: When the Dossier is formally filed, add a citation to NAVV Maturity Assessment - 2026-05-08 as the Corridor Width instrument. Minor update only.Priority: Low.Status: Critical Gap — none existNo Factory Charter exists anywhere in the project. Without a Charter: Brian and Andrew's production within the IFC Programme is ungoverned in P3 terms Work produced cannot be formally attributed to the Programme The Charter → Saga connection is broken (a Saga requires a Charter) What a Charter for NAVV-IFC would contain: Binding IFC Strategy Dossier ID Named Factory (e.g., "NAVV Founders — Brian and Andrew") Bounded production scope within the IFC build-out epoch Epoch start date; decommissioning criteria Folder gap: P3-Governance/ has no Charters/ folder. This structural decision is needed before a Charter can be filed — see Q-022.Priority: High — should be created promptly after the Strategy Dossier is issued.Status: Partial — 1 of 5 IFC components has a validated briefThe PST brief predates the IFC Programme structure. It needs to cite the IFC Dossier ID to be formally attributable — a simple update, deferred until the ID exists.Note on Component #3: The IFC Strategy Brief flags a potential overlap between Component #1 and Component #3 — both address the R106 Category 7 flexibility decision. Clarification from Andrew is needed before a separate brief for Component #3 is commissioned.
Priority: Medium — commission briefs for #1, #2, #5 once Dossier ID exists and #1/#3 overlap is clarified.Status: Critical Gap — none existA Saga is the append-only operational record of what a Factory produced during its Charter epoch. For the IFC Programme, it would record: prototype versions built, briefs produced and validated, first deployment date, first NDIA responses received.Dependency: A Saga requires a Charter. Saga creation follows Charter issuance.Note on pre-Charter activity: Work already done — v1 through v7 prototype, NbLM extraction, brief production — is pre-Charter activity. A founding Saga entry summarising this history would give the Programme an accurate operational record from its inception.Folder gap: Same as Charters — P3-Governance/ has no Sagas/ folder. See Q-022.Priority: High — start immediately after the Charter is issued.Status: Not yet derivable — dependent on Dossier ID
Once the Strategy Dossier is issued with a binding ID, the Portfolio Integration Map entry becomes derivable on demand: query for all artefacts referencing that ID. The P3-Index serves as the closest current proxy.Required P3-Index updates when the Dossier is issued: Add a Programme section to the Product Registry (or a separate Programme Registry table) Register IFC as a Programme with its Dossier ID Register the IFC notebook (07344d6e-933e-43f0-81e2-8576ff93e178) in the Notebook Registry Critical path: Step 1 (Dossier issuance) unblocks Steps 3–8. Step 2 (folder structure) unblocks Steps 3–4. Steps 3 and 4 must be sequential. Steps 5–8 can be run in parallel once Step 1 is done.Produced: 2026-05-10 — Missive NAVV-2026-05-10, Item 2.
References: P3 Programme Guidance, IFC Strategy Brief - Stage 3 Strategy Pass, P3-Index, NAVV Maturity Assessment - 2026-05-08
strategy-dossier-ifc — Identified the critical absence of a formally issued Strategy Dossier (Step 1 in the priority sequence, blocking all other artefacts) and provided the recommended action — approve content, assign ID, rename, and file in P3-Governance/Strategy/ — that directly led to the commissioning and filing of SD-IFC-2026-001
factory-charter-ifc-build-out — Identified the Factory Charter as a high-priority critical gap (Step 3) blocked on Strategy Dossier issuance; articulated what the Charter must contain (binding Dossier ID, named Factory, bounded scope, epoch dates) and flagged the P3-Governance/ folder structure gap (Q-022); provided the rationale basis for Charter creation
saga-ifc-build-out — Identified the IFC Saga as a critical gap (Step 4) dependent on Charter issuance; established that pre-Charter work (v1–v7 prototype, NbLM extraction, brief production) should be captured in a founding Saga entry to give the Programme an accurate operational record from inception
navv-principles-register — Cites the Principles Register as the source of the four corridor-wall principles for the IFC Programme (PR-A001, PR-R001, PR-I003, PR-I001); identifies the attribution gap (principles not linked to IFC Dossier ID) and recommends the lightweight fix once the Dossier ID exists ]]>navv-operational/p3-programme-artefact-gap-analysis-ifc.htmlNAVV-Operational/P3 Programme Artefact Gap Analysis - IFC.mdSun, 17 May 2026 01:33:50 GMTndis-dispersed-boundary-waterline-amendment — Provides the option analysis and architectural recommendation that informed this amendment, specifically the rationale for keeping Droppings/ ephemeral rather than transforming it into a formal Below-the-Waterline tier
SUPPORTS: p3-index — Contributed the waterline architecture design that governs document classification and governance structure across the entire P3 programme This document represents a point-in-time analysis. Subsequent decisions or implementation changes may supersede specific recommendations or assessments contained herein.Type: Design Recommendation
Commissioned by: Brian, via Missives/NAVV-2026-05-14 Date: 2026-05-14
Context: Response to Brian's waterline model feedback on P3 Portal Analysis - Concept Assessment and State Machine QuestionThe NDIS Dispersed Boundary Waterline Amendment was designed for participant data governance — managing what information flows to which audience in a clinical support context. Brian proposes adapting its core organising principle — a three-tier governance architecture — as the structural spine of NAVV's own knowledge organisation.The adaptation is sound. The tiers map cleanly:Without the waterline model, the wiki is a flat list of P3 artefacts Andrew can browse. It solves the immediate access problem but does not scale — every new document type requires an ad-hoc classification decision.With the waterline model, the wiki becomes a tiered knowledge architecture. Three structural changes follow:1. Delineation is architectural, not cosmetic. The tiers are not navigation tabs or folder colours — they represent qualitatively different governance relationships. The wiki must make this visible in its structure, and that distinction must be defensible to Andrew, to future partners, and ultimately to regulators.2. Dispute and approval mechanics differ by tier. A dispute against a Deep Ocean artefact (a Product Brief, a Principle) is a constitutional act — it goes through Brian's full P3 state machine protocol. A dispute against a Below-the-Waterline operational document is a lighter-weight operational correction. The tier determines the governance pathway. This matters enormously for the portal design.3. The Below-the-Waterline tier is the active build frontier. The Deep Ocean is already substantially populated — Stages 1-4 of P3 are complete. The wiki surface for those artefacts is primarily read-browse-dispute; the content exists. The immediate build work is the Below-the-Waterline tier: operational documents that elaborate, contextualise, and support each P3 artefact. This is what Brian means by "generate the below the waterline P3 view."The Dispersed Boundary Amendment established an important principle: a single event or workflow can generate nodes distributed across multiple tiers simultaneously.For NAVV, this plays out as follows. The IFC programme decision, for example, generated: A Deep Ocean entry — the Saga record, the Charter, the Strategy Dossier (canonical governance) A Below-the-Waterline counterpart — the analyses, rationale documents, and operational notes that contextualise why those decisions were made Eventually an Above-the-Waterline expression — when NAVV commercialises, a market-facing description of what IFC produces These are the same event captured at different governance depths. The wiki architecture must make these cross-tier relationships traceable — a reader in the Below-the-Waterline tier must be able to follow the thread back to the Deep Ocean artefact it contextualises.Based on existing project output, the Below-the-Waterline tier for NAVV will include:Much of this material already exists in Droppings/ — it simply has no formal tier assignment or governance classification.This is a single combined design document — the design authority for all subsequent wiki structure decisions. It will define: The formal governance characteristics of each tier What document types belong in each tier (classification rules, not an exhaustive list) The physical folder/section structure in Obsidian that reflects the three tiers The navigation model for the web-facing wiki (how Andrew moves between tiers)
How cross-tier relationships are represented (Dispersed Boundary traceability — e.g., WikiLink from a Below-the-Waterline analysis to its Deep Ocean parent artefact) Governance rules per tier: who can dispute what, what gating applies This is my work. I can produce it in a single session. Brian reviews and approves before any structural changes are made.Not all Droppings/ content belongs in the Below-the-Waterline tier. Some material is ephemeral working output (lint reports, phase specifications for completed phases, triage analyses). Some is formal operational material that deserves a permanent, accessible home.The audit will produce a classification of all current Droppings/ content: Promote to Below-the-Waterline (with target location) Archive as ephemeral (already in _Archive/ — no action) Retire (outdated, superseded) This can be produced in the same session as Step 1 or immediately after, depending on Brian's preference.The taxonomy/architecture document and the audit both need Brian's sign-off before any restructuring begins. No files are moved or renamed until Brian approves.With architecture approved, we begin producing the formal Below-the-Waterline layer: Promote eligible existing content Identify gaps per P3 artefact (what operational support documents are missing?) Produce missing documents systematically
This needs Brian's input before Step 1 can begin. See Q-029 in NAVV Questions Log.The question: Droppings/ currently serves as the ephemeral working space for all operational output. The Below-the-Waterline tier is the formal layer — permanently accessible, classified, and traceable. Two options:Option A — Keep Droppings/ as ephemeral; create a new formal Below-the-Waterline folder Droppings/ remains the working space; content produced here is working output A new folder (e.g., Below-Waterline/ or Operational-Record/ or a name Brian prefers) holds formally promoted content Promotion is an explicit act — content is reviewed, classified, and moved Option B — Transform Droppings/ into the formal Below-the-Waterline structure Droppings/ is renamed and reorganised to become the formal Below-the-Waterline tier Ephemeral working output gets a new home (or Droppings/_Working/ sub-folder) Recommendation: Option A. Keeping the working/formal distinction clean matters at scale. Droppings/ is where work lands before it is assessed — it should remain an intake zone. The formal Below-the-Waterline tier should be a curated record, not a dump. The distinction mirrors how the P3-Governance folder works — canonical artefacts have a formal home; working analyses are separate.Both Step 1 (Taxonomy + Architecture) and Step 2 (Candidate Audit) can be produced in the current session pending Brian's direction on: Q-029 — Droppings/ relationship (Option A or B, or alternative) Whether to proceed with Steps 1 and 2 now, or hold for further guidance Prepared by Sonnet — 2026-05-14
Commissioned via Missives/NAVV-2026-05-14]]>navv-operational/p3-navv-wiki-design-waterline-architecture-recommendation.htmlNAVV-Operational/P3-NAVV Wiki Design - Waterline Architecture Recommendation.mdSun, 17 May 2026 01:33:50 GMTproduct-brief-ndis-wiki — Elaborates the three-tier architecture and governance model for the NDIS Wiki product This document represents a point-in-time analysis. Subsequent decisions or implementation changes may supersede specific recommendations or assessments contained herein.Type: P3 Product Artefact — Stage 3 (draft, awaiting Brian review)
Source: Product Brief - NDIS Wiki stub + missive directive NAVV-2026-05-09 (three-purpose framing) Sentinel authority: Andrew (Product pillar) Date: 2026-05-09
Reference: P3 Minimum Viable Products
Status: Draft — awaiting Brian approval before Product Brief - NDIS Wiki stub is updated Product type: Multi-tier — Instrument (Tier 1, internal navigation and curation), Theory (Tier 2, knowledge base underpinning the Handbook), Theory evolving toward Service (Tier 3, public "Context as a Service" resource). Blue Ocean / Red Ocean: Blue Ocean. No governed, NDIS-specific knowledge base at this level of specificity exists in the sector. The Tier 3 evolution toward Context as a Service creates a differentiated position not currently occupied by any NDIS-sector offering. The missive identifies three concurrent purposes, each with a distinct beneficiary and value proposition. These are not development stages — they are simultaneous design considerations that must be held together from the outset.P3 implication: The Wiki is not one product with three uses — it is one infrastructure supporting three distinct value transfers. Each tier has its own Beneficiary Statement, Value Exchange, and Done Criteria. Governance must hold all three tiers simultaneously without collapsing them.Tier 1 — NAVV Internal: The NAVV team — Brian and Andrew — in their planning, governance, and product development work. Before the Wiki: NDIS knowledge is scattered across individual experience, informal sources, and ad hoc research; each planning session requires re-derivation of foundational knowledge. After: the Wiki is the single source of truth from which all planning, commissioning, and product work proceeds — "where we steer the ship."Tier 2 — Handbook Pipeline: Future NDIS Handbook users — practitioners, educators, sector bodies — who will benefit from a Handbook whose content is provenance-grounded, structurally consistent, and maintained without independent duplication. Before the Wiki: each Handbook section requires its own research and editorial pipeline, creating version drift and maintenance burden. After: all Handbook content is developed within the Wiki, governed by its quality pipeline, and published via its content architecture. The Handbook becomes a curated, maintained extension of a living resource.Tier 3 — Sector Resource: Broader NDIS sector practitioners — Support Coordinators, Plan Managers, Psychosocial Recovery Coaches, allied health practitioners — seeking reliable, current NDIS domain knowledge. Before: practitioners navigate fragmented, unofficial, and often contradictory sources (Facebook groups, word of mouth, outdated NDIA materials). After: a governed, publicly accessible, maintained knowledge base is available — trusted because it is traceable to legislative and pricing sources.Classification: Instrument (T1), Theory (T2 and T3), Service-in-development (T3 future state).Tier 1 — Instrument: Transfers the operational capacity for NAVV to make knowledge-grounded decisions consistently, without re-deriving foundational NDIS domain knowledge in each session. The Wiki is the decision substrate — not just a reference but the active base from which planning, commissioning, and product development proceed.Tier 2 — Theory (structured and flowing): Transfers structured, governable NDIS knowledge into the Handbook product. The value is not only what the Wiki contains — it is the governance architecture that ensures Handbook content is traceable to sources, consistent across articles, and maintainable as legislation and pricing evolve. The flow is directional: all Handbook content is developed in the Wiki and exported through a managed publication pipeline.Tier 3 — Theory evolving toward Service: Transfers current, trusted NDIS knowledge to sector practitioners via publicly accessible content. The "Context as a Service" evolution takes this further — knowledge is not only browsable but queryable, making the Wiki an active information provisioning service rather than a static library.Tier 1: If NAVV maintains a governed NDIS knowledge base as its internal source of truth, all downstream products will be more consistent, accurate, and maintainable than if each product manages its own knowledge independently. The test: every P3 product brief's Validity Marker should trace its domain knowledge back to the Wiki — not to ad hoc research.Tier 2: If all Handbook content is developed and governed within the Wiki before publication, the resulting Handbook will maintain structural consistency and legislative currency without requiring parallel maintenance workflows. The test: when PAPL changes, a single Wiki update propagates to all affected Handbook sections — no separate editorial sweep required.Tier 3: If a governed, publicly accessible NDIS knowledge resource exists, practitioners will adopt it as a preferred reference over fragmented informal sources. The test: practitioner-reported reduction in time spent finding reliable NDIS information; organic citation and referral.Current probe: Provisional-status Wiki — approximately RS-01 through RS-10 ingested, covering Core Support categories, Support Coordination, PACE framework concepts, and price codes.What each tier is testing: T1 probe: Does the NAVV team use the Wiki as the first reference in planning sessions? Signalled by: Missive work that references Wiki articles rather than external sources or ad hoc explanation. T2 probe: Can a Handbook section be produced directly from Wiki content without independent research? Signalled by: the first Handbook draft section produced from Wiki sources only. T3 probe: Do practitioners external to NAVV find the Wiki useful when given access? Signalled by: Andrew's field report after sharing with trusted colleagues. T3 scope boundary: Public access is not yet enabled. T3 probe requires a content governance decision — what is safe to publish — before it can begin. This is a Brian-to-confirm prerequisite.Tier 1: NAVV resolves any NDIS domain question from the Wiki without resorting to external sources during a planning session. Andrew confirms the Wiki is his first stop for checking domain knowledge in his practice.Tier 2: At least one NDIS Handbook section is produced by flowing Wiki content through a publication export, without requiring independent research or editorial from scratch. The section is structurally consistent with other Handbook sections by inheritance, not manual alignment.Tier 3: At minimum two practitioners external to NAVV report the Wiki is useful for real-world practice questions. The Wiki is publicly accessible (filtered to safe-to-publish content).Future commitment implied by T3 scope: Public content must be filtered against a "safe to publish" standard — articles may contain NAVV-internal planning notes, speculative content, or in-progress work that should not be externally accessible. A content classification standard will be needed before T3 goes live. Recommend as a future Critical Commitment candidate.
Brian reviews and approves this brief — or notes required corrections #action/brian
Brian confirms whether this brief replaces the stub in Product Brief - NDIS Wiki #action/brian
Brian confirms the scope of T3 public access (W-01) — or defers to later commissioning #action/brian
Brian notes the NDIS Handbook will need its own P3 Product Brief (W-03) — confirm when to commission #action/brian
Brief produced: 2026-05-09 from missive directive NAVV-2026-05-09 + Product Brief - NDIS Wiki stub.]]>navv-operational/product-brief-ndis-wiki-stage-3-enriched.htmlNAVV-Operational/Product Brief - NDIS Wiki - Stage 3 Enriched.mdSun, 17 May 2026 01:33:50 GMTproduct-brief-participant-statement-toolkit — Contains the Stage 3 analytical extract for the PST brief, defining scope, product type, Blue Ocean classification, and delivery model for the Participant Statement Toolkit product This document represents a point-in-time analysis. Subsequent decisions or implementation changes may supersede specific recommendations or assessments contained herein.Type: P3 Product Artefact — Stage 3 (draft, awaiting Brian review)
Source: NbLM extraction pass (notebook: NAVV-NDIS-Participant-Statement-Toolkit) + 2.2 - REF Requirements v1.0 + 2.3 - REF Specification v1.0 Sentinel authority: Andrew (Product pillar) Extraction date: 2026-05-09
Reference: P3 Minimum Viable Products
Status: Draft — awaiting Brian approval before Product Brief - Participant Statement Toolkit stub is updated Product type: Instrument (primary) — transfers operational capacity to practitioners. Theory (secondary) — embedded orientation content builds coordinator understanding of the NDIS planning process and PACE framework. Blue Ocean / Red Ocean: Blue Ocean. No equivalent structured tool exists for PACE-framework Participant Statements at this level of specificity. Nearest alternatives are generic NDIS goal templates that do not address PACE architecture, budget recommendation structure, or legislative traceability to s33(2) and s34(1)(a).
The existing stub in Product Brief - Participant Statement Toolkit identifies "NDIS participants and their families" as the primary beneficiary. This is incorrect. The NbLM extraction and Specification both confirm that the direct user of the toolkit is the Support Coordinator or PRC — not the participant. Participants are the ultimate beneficiaries but they do not use the tool themselves. This correction is material to the Done Criteria and Probe Design. Brian to confirm before updating the stub.Primary beneficiary: Support Coordinators (SCs) and Psychosocial Recovery Coaches (PRCs) preparing formal Participant Statements for NDIA planning meetings.Before the toolkit: coordinators must translate complex, personal participant stories into technically precise NDIA language — navigating PACE support categories, outcome domain mapping, funding architecture rules, and legislative requirements (s33(2), s34(1)(a)) — without structural guidance. The result is inconsistent, incomplete statements that expose participants to inadequate planning outcomes.After the toolkit: coordinators work through a single guided document that systematically captures participant context, goals, and budget architecture, pre-mapped to NDIA data requirements. The resulting statement is structured to make funding approval administratively straightforward and rejection procedurally costly for the NDIA — making it difficult to roll over old goals or simplify the plan without triggering a clear administrative error reviewable under s100.Ultimate beneficiary: NDIS participants, whose authentic goals are captured in their own words while being mapped to the legislative and technical structures that protect their funding.Classification: Instrument (primary), Theory (secondary).What transfers to the coordinator — three distinct capabilities: Goal translation: The ability to convert plain-English participant goals into the "NDIS Trinity" — Goal → Support Category (1–21) → Outcome Domain (1–8) — in a form that NDIA planners can act on directly without interpretation. PACE Budget Architecture: The operational capacity to recommend funding period structure, Flexible/Stated designations, Digital Lock requests, and risk rationale — components of budget design that most coordinators lack a structured framework for and currently produce ad hoc or omit entirely. Legislative anchoring: A document that is explicitly traceable to s33(2) (the participant's right to submit a goals statement) and structured to invoke s34(1)(a) necessity requirements — creating a legally grounded record that constrains NDIA decision-making in the participant's favour. Secondary Theory component: the embedded orientation section transfers understanding of the submission-response chain (Part A → NDIA → Statement of Participant Supports) and provides working reference material (item code anatomy, 8 Outcome Domains, 21 Support Categories) — excluded from printed output to avoid polluting the submission document.Form of transfer: A single self-contained browser-based HTML file. No installation, no external dependencies, no data transmission. Opens in any browser; prints to PDF for submission.If a Support Coordinator or PRC uses the toolkit to prepare a Participant Statement before a planning meeting, the resulting document will: Be more structurally complete and legislatively grounded than statements prepared without the toolkit Map participant goals to PACE support categories and outcome domains in a form NDIA planners can act on directly Reduce the risk of an inadequate or under-funded plan by making it administratively difficult for the NDIA to reject, simplify, or roll over the statement without triggering a reviewable error What will confirm this: Coordinator self-report on preparation quality; comparison of NDIA responses (Statement of Participant Supports) for toolkit-prepared statements vs. prior practice.Current probe: v7 HTML prototype — a fully self-contained browser file implementing 22 of 23 requirements (R-001 through R-022 active; R-023 pending).What this probe tests: Whether the structured guided form is sufficient for coordinators to produce compliant, complete statements without additional training — and whether the PACE budget architecture section (Block 3, Alignment Matrix) is understood and usable by coordinators in practice.Intentional scope constraint: PACE framework only — no Legacy plan mode (G-01). This is a deliberate probe boundary, not a defect requiring immediate resolution.Primary probe limitation: No save function (R-023 Pending) — data is lost if the browser is closed. This constrains the probe to single-session preparation only. The limitation does not invalidate the probe but must be resolved before general deployment.The probe is complete when ALL of the following are observable: A Support Coordinator completes the toolkit in a single session and produces a printable, complete statement (R-021 satisfied) The statement is formally submitted to the NDIA as a Part A Participant Statement under the declaration (R-018, R-019 satisfied) At minimum one NDIA response (Statement of Participant Supports) is received for a toolkit-prepared statement The coordinator reports that the Budget Architecture section (Block 3, Alignment Matrix) reduced the time and effort required to prepare funding recommendations No critical structural issue prevents completion (no blocker-severity defect in the 22 active requirements) Done vs. Valid distinction: Done means the test ran. Valid requires the NDIA response to confirm the statement was accepted and acted on — not merely acknowledged. The first NDIA response to a toolkit-prepared statement will be the first validity evidence. Until then, the product is Done in intent but not yet Valid in outcome.Key design choices traceable to governing commitments:
Known validity risk — G-03: Domain knowledge underpinning the toolkit was derived from AI-generated analysis and has not been independently validated against the exact text of the NDIS Act or published NDIA operational guidelines. This is a known, managed risk. Before any version beyond the probe is deployed at scale, independent regulatory review is required. Recommend flagging in Critical Commitments Register.
Brian reviews and approves this brief — or notes required corrections #approved/brian
Brian confirms whether this brief replaces the stub in Product Brief - Participant Statement Toolkit or is versioned alongside it #feedback/brian This can replace the original provisional stub - it was not authoratative.
Brian confirms whether G-03 (validation risk) should be added to Critical Commitments Register #feedback/brian Yes, add the validation risk to the register Brief produced: 2026-05-09 via NbLM extraction pass + Requirements v1.0 + Specification v1.0. NbLM notebook: NAVV-NDIS-Participant-Statement-Toolkit (4e7b7c28-8cd3-4dcc-be74-5fa989a28979)]]>navv-operational/product-brief-participant-statement-toolkit-stage-3-extract.htmlNAVV-Operational/Product Brief - Participant Statement Toolkit - Stage 3 Extract.mdSun, 17 May 2026 01:33:50 GMTproduct-brief-participant-statement-toolkit — Documents the v7 HTML prototype specification for the Participant Statement Toolkit, providing the reverse-engineered formal requirements baseline that informs PST product development This document represents a point-in-time analysis. Subsequent decisions or implementation changes may supersede specific recommendations or assessments contained herein.Type: Dropping — Phase 1 Output Prepared by: Sub-agent Manager Source: History/Prototype-v7.html (reverse-engineered) Status: Awaiting Brian reviewThis document is the reverse-engineered specification of Prototype-v7.html. It describes what the prototype does in structured, governed terms — independent of the HTML implementation. This becomes the baseline specification that Andrew will manage going forward. Title: NDIS Participant Statement of Goals and Aspirations — PACE Framework Format: Interactive HTML (browser-based, no server required) Legislative basis: Section 33(2), National Disability Insurance Scheme Act 2013 Version: 7 (as of 2026-04-14) Prepared by: Support Coordinator or Psychosocial Recovery Coach Target users: Frontline Support Coordinators and Psychosocial Recovery Coaches The document has four major structural layers: Header — Document identity and participant metadata Orientation section — Explains how the document works (educational, not printed) Part A — What We Submit to the NDIA — Blocks 1 and 2 Part B — Anticipated NDIA Response and Architecture Recommendations — Alignment Matrix and Block 3 Design note: Impairment types appear as pill-shaped toggles (chip UI), not a traditional checkbox list. Selected impairments are visually highlighted. Multiple selections are permitted.Title: "How This Document Works — The Submission → Response Chain"A visual flow diagram showing that the Participant Statement is an input to the NDIA, not an output. The NDIA responds with the Statement of Participant Supports."We Submit" side (Part A): Goals in the participant's own words Impairment and functional context Environmental and risk context Barriers to achieving goals What informal and mainstream supports cannot cover NDIA Responds with: Support Category (positions 1–21) Funding Type — Core (1), Capital (2), Capacity Building (3) NDIS Outcome Domain (1–8) Budget amounts, flexibility, and funding periods Digital locks where required "The Critical Chain" diagram: Goal → Context → NDIA → Category (01–21) → Funding Type (1–3) → Outcome Domain (1–8)An expandable reference block explaining how PACE item codes are structured:CC_NNN_RRRR_P_F CC = Support Category NNN = Support Item Number RRRR = Registration Group P = NDIS Outcome Domain (position 4) F = Funding Type (position 5) Also includes visual legends for: 8 NDIS Outcome Domains (Domain 1–8 with plain-language descriptions) 21 PACE Support Categories (01–21 with names) Special note included: Explains why Support Coordination (Category 07) maps to Outcome Domain 8 (Choice and Control) but Psychosocial Recovery Coaching (also Category 07, item 07_101) maps to Outcome Domain 6 (Social and Community Participation). Also notes the Registration Group 0132 distinction for Specialist Support Coordination.Legislative reference: s33(2)(b) and s34(1)(e)–(f)Guidance callout (non-printed): The NDIA uses this section to determine whether a support should be funded by NDIS or by informal/mainstream systems. Clarity about the boundaries and limitations of existing non-NDIS supports strengthens the case for NDIS funding.Risk callout (non-printed, between 1.4 and 1.5): "Risks documented here directly justify the Funding Period intervals, Digital Lock requests, and budget architecture recommendations in Part B."All Block 1 fields are free-text, multi-line, browser-editable (contenteditable divs with placeholder text).Legislative reference: s33(2)(a)Guidance callout (non-printed): Under s34(1)(a), the NDIA cannot fund a support unless it assists the participant to pursue the goals in this statement. If a goal is not here, it cannot be funded.The prototype ships with 4 default goal cards. Additional cards can be added dynamically (no stated upper limit). Cards can be removed individually.Each goal card contains:Sub-section 1: Participant's Goal Label: "Participant's Goal — In Their Own Words" Hint: "Record the goal as the participant expressed it. Use their language, not clinical language. This is their voice — honour it." Input: Free-text editable area Placeholder: "Write the participant's goal here in their own words…" Sub-section 2: Goal → Outcome Bridge Label: "Goal → Outcome Bridge" Hint: "What measurable outcomes should this goal produce? How will achieving this goal improve the participant's life? Think about the concrete difference this support is expected to make — this is what demonstrates the support is reasonable and necessary." Input: Free-text editable area Placeholder: "Describe the expected outcomes — what will change, what will improve, and how you will know this goal has been achieved…" NDIS Outcome Domain checkboxes: All 8 domains with plain-language descriptions (multi-select) Domains listed: Daily Living — Choice and control in daily activities Home — A suitable, stable place to live Health and Wellbeing — Maintaining health and personal wellbeing Lifelong Learning — Access to learning opportunities Work — Economic participation and employment Social and Community — Participation in community life Relationships — Building and maintaining connections Choice and Control — Autonomy over life decisions Dynamic behaviour: "Add Goal" button dynamically creates new goal cards "Remove" (×) button on each card removes it New cards are numbered sequentially (starting from 5 after the 4 defaults) Goal numbering does not renumber after deletion (known limitation) Purpose: For each submitted goal, maps the coordinator's anticipated NDIA response — which Support Category, Funding Type, and Outcome Domain should result.Explanatory callout (non-printed): Justifies why this section is included in the Participant Statement — Section 33(2) permits "other matters" the participant considers relevant.Reference legends included: 8 NDIS Outcome Domains (Pos 4) 21 PACE Support Categories (Pos 1) Headers: ← WE SUBMITTED (Part A): Goal Ref | Impairment | Barrier and Support Justification ANTICIPATED NDIA RESPONSE →: Pos 1 Category | Pos 5 Fund Type | Pos 4 Outcome | Expected Item Code(s) Row grouping by Funding Type:The table is pre-grouped into three funding type sections:The Funding Type column for each row displays a fixed badge (1–Core, 2–Capital, 3–CB) rather than an editable cell.Dynamic behaviour: "Add Core Row," "Add Capital Row," and "Add CB Row" buttons add rows within their respective sections New rows are added at the bottom of the document (known limitation — not inserted within sections) Legislative reference: Funding Periods · Digital Locks · Flex/StatedExplanatory callout (non-printed): These are recommendations to the NDIA — not instructions. The NDIA makes the final determination. Budget controls operate at three levels: Flexible vs. Stated categories, Digital Locks on specific items, and Funding Periods.Table headers: Pos 5 Fund Type (fixed badge — not editable) Pos 1 Category Flex / Stated Rec. Funding Period Expected Item Codes Digital Lock? Risk Management Rationale Row grouping (same as Alignment Matrix):Dynamic behaviour: "Core Row," "Capital Row," "CB Row" buttons add rows within each section.Fixed text: "I confirm that this Participant Statement of Goals and Aspirations has been prepared with my input and represents my views, goals, and current circumstances. I understand that Part A of this document will be submitted to the NDIA as the primary input for my Statement of Participant Supports, and that Part B contains my coordinator's recommendations for how the resulting plan should be structured. The NDIA makes the final determination on all funded supports."Signature fields: Participant / Nominee Signature (with signature line and date) Support Coordinator / PRC Signature (with signature line and date) File format: Single self-contained HTML file (no external dependencies) Interactivity: All text entry via contenteditable="true" divs and standard HTML inputs Print: Print CSS removes non-printed elements (guidance callouts, orientation section, add-row buttons) Dynamic goals: JavaScript adds/removes goal cards Dynamic rows: JavaScript adds rows to the Alignment Matrix and Block 3 tables No server: Runs entirely in browser — no data is submitted to any server No save function: Data entered is lost when the browser tab is closed (this is a significant limitation not addressed in v7) Browser compatibility: Modern browsers (Chrome, Firefox, Safari, Edge); responsive for mobile (tables scroll horizontally) Andrew has indicated there are additional changes he wants to make. These have not been documented in the history files. They will be captured when Andrew's notebook is operational and Andrew can specify them using the governed requirements process. Brian to confirm with Andrew: should known limitations L-01 to L-06 be added to the change request list, or should Andrew specify these requirements independently?
#feedback/closed No, we won't add these to our list – change requests are Andrews world. We provide him with the mechanisms to generate them within NotebookLM End of Prototype Specification — v7]]>navv-operational/prototype-specification-v7-2026-04-14.htmlNAVV-Operational/Prototype Specification - v7 - 2026-04-14.mdSun, 17 May 2026 01:33:50 GMTProgramme Analysis - Product Brief 02, Strategy Dossier - IFC, P3-Index Status: Working paper — identifies gaps and impacts only. No P3 artefacts updated.This analysis was conducted to identify discrepancies between Product Brief 02 (the evolving product specification) and the P3 baseline governance framework. It was a point-in-time assessment commissioned to surface misalignments and guide architectural decisions. The analysis documents the rationale for decisions made to resolve identified gaps.
CITES: p3-index — Used as the programme governance framework reference for artefact status tracking; the Baseline State table and Summary Table reference P3 artefact locations and attribution requirements
SUPPORTS: product-brief-participant-statement-toolkit — Identified the PST as the highest-priority update target, flagging three specific gaps: the New Framework Plan framing absent from the brief, the Goal 5b hybrid model mandate not incorporated, and the missing SD-IFC-2026-001 citation; provided the analytical basis for subsequent PST brief revision priorities
SUPPORTS: product-brief-psychosocial-recovery-plan — Assessed Component #5's gaps against Andrew's Goals 4 and 5a; identified the dual progress reporting constraint as a design requirement not yet in the brief, and provided the analytical basis for routing Goal 4 to the wiki territory report class rather than treating it as a new product component
SUPPORTS: product-brief-visual-guide-ndis-plan — Confirmed Component #1 is validated by Andrew's Goal 1; identified the Old/New Framework Plan distinction as a minor addendum need; provided the gap analysis basis for the structural decision to absorb Component #3 as Loop 4
SUPPORTS: product-brief-visual-guide-service-agreement — Confirmed that the R106 SC/PRC choice is the instrument of informed consent for the hybrid model itself; identified G-01 (visual design approach) as a medium-priority gap requiring resolution before the component is production-ready
SUPPORTS: strategy-dossier-ifc — Identified three programme-level gaps in the Strategy Dossier: the commissioning window absent from the Epoch Definition, the Practice Rationale unregistered as a "Now" element in the Capability Assessment, and the commissioning context absent from the Value Rationale; provided the analytical basis for Saga Entry 002 This document represents a point-in-time analysis. Subsequent decisions or implementation changes may supersede specific recommendations or assessments contained herein.Type: Gap Analysis Scope: Comparing Andrew's Product Brief: 02 (2026-05-11) with the P3 programme artefacts established at yesterday's baseline (2026-05-10) Date: 2026-05-11
Cross-references: Programme Analysis - Product Brief 02, Strategy Dossier - IFC, P3-Index Status: Working paper — identifies gaps and impacts only. No P3 artefacts updated.The following P3 programme artefacts were in place at the end of yesterday's session:The IFC Direction Statement ("NAVV is moving toward participant financial sovereignty in the NDIS") remains valid. Andrew's new document deepens the evidence base for the direction but does not change it.Gap: None at the direction level.The existing Value Rationale in the Strategy Dossier references the R106 "Master Key" and the market void for informed-consent-centred SC/PRC practitioners. Andrew's Product Brief: 02 adds a critical external validation layer: Butler's political position confirms the market void is not a NAVV observation — it is a government-acknowledged problem The commissioning process creates a strategic urgency: before the commissioning framework locks in, NAVV needs an established, auditable, compliant hybrid model The "Blue Ocean position" is now reinforced by the government's own demand for independence and productivity Gap: The Strategy Dossier's Value Rationale does not mention the commissioning process or the April 2027 New Framework Plans deployment as context. This is not incorrect, but it is now incomplete.Recommended action: A minor addendum to the Value Rationale and/or an update to the Saga (operational note, not a dossier revision). Defer to Brian's direction.The existing sieve has two "Now" elements (legislative framework, Service Agreement / COI model) and five "Grow" elements (the five component tools).Andrew's Product Brief: 02 introduces a newly completed artefact that could be classified as a "Now" element:New "Now" element — Practice Rationale and Audit Framework: The compliance document embedded in Product Brief: 02 is substantively complete. It provides the regulatory justification for the hybrid model, the Least-Cost-Appropriate-Provider decision rule, and the documentation/audit trail protocols. This represents completed intellectual capital, even though it hasn't yet been formally filed as an IFC artefact.Gap: The Strategy Dossier's sieve does not include the Practice Rationale as a "Now" element. It is unregistered in the P3 product inventory.The Sacrifice List remains unchanged and appropriate. However, Andrew flags a new category of potential scope expansion via PRC's R106 breadth: PRC can be delivered across Categories 8 (housing), 9 (community participation), and 10 (employment) Andrew explicitly mentions this as a scope hedge, while acknowledging it introduces conflict-of-interest risk (bringing in "Amanda") Gap: The Sacrifice List does not address Categories 8, 9, and 10. These are NOT currently excluded, but they are also NOT currently in scope. This is a scope boundary that needs to be defined before it creates ambiguity.The four foregrounded principles (PR-A001, PR-R001, PR-I003, PR-I001) remain valid. The Practice Rationale document provides extensive new evidence for PR-I001 (Managed Conflict of Interest), particularly the Least-Cost-Appropriate-Provider rule and the categorical argument that same-pool billing eliminates structural COI.Gap: None at the principle level. The Saga should note the enriched evidence base as an operational milestone.The current epoch horizon ("all five component tools used in at least one complete NDIS planning cycle and first NDIA responses received") remains valid. However, Andrew's document reveals a secondary horizon:Commissioning window: New Framework Plans are delayed until April 2027. The government is simultaneously developing the commissioning framework for navigators. A commissioned navigator framework that excludes direct service providers would force EYC to choose between the coordinator/navigator model and the PRC/direct model. The current epoch horizon should be achievable before April 2027, but this is now a material external constraint.Gap: The Strategy Dossier's epoch definition does not acknowledge the commissioning window. This is a planning risk, not a dossier error.Yesterday's status: Active, 14/14, filed.Today's impact: Andrew's Goal 1 ("help participants understand foundational NDIS concepts") maps directly and confirms the component. The component is validated.Minor gap: The current brief was written without distinguishing Old Framework Plans from New Framework Plans. Under New Framework Plans, the foundational NDIS concepts that participants need to understand are somewhat different (functional capacity framing vs. goals/diagnosis framing). The brief may need a minor addendum noting the Old/New Framework Plan distinction.Severity: Low. Not blocking. Deferred.Yesterday's status: Active, 12/14, G-01 (visual design approach pending).Today's impact: Andrew's Goal 2 confirms this component and adds specificity: the Service Agreement is now explicitly where the R106 choice (SC, PRC, or both) is exercised. The Service Agreement is not merely a contractual document — it is the instrument of informed consent for the hybrid model itself.Gap clarification: G-01 (visual design approach not yet specified) remains open. Andrew's framing suggests the visual approach needs to reflect the SC/PRC choice architecture, not just the financial structure. This contextualises G-01 more precisely.Severity: Medium. G-01 needs resolution before the component can be considered ready for production.Yesterday's status: Structural Hold — NbLM recommended embedding in Component #1 as Loop 4. Brian decision pending (Q-023).Today's impact: Andrew skips Goal 3 entirely in his product brief. He moves from Goal 2 directly to Goal 4 with no acknowledgement of a standalone Choice and Control Flexibility Educator.Analysis: Andrew's silence is strongly suggestive. The SC/PRC choice is now embedded in Goal 2 (the Service Agreement) rather than articulated as a standalone educational product. This aligns with NbLM's structural recommendation from yesterday.Significance: Q-023 (Brian decision — standalone or embedded?) is still formally open. But Andrew's behaviour in Product Brief: 02 is the strongest signal yet that he does not conceive of this as a standalone product. If Brian confirms on Q-023, Component #3 can be absorbed into Component #1 or Component #2 depending on scope.Severity: Medium. Q-023 still requires Brian's formal confirmation. No action taken.Yesterday's status: Active, validated 2026-05-09. Not yet cited to SD-IFC-2026-001 (deferred for token budget).Today's impact: This is the most significantly impacted component.Two new developments:A — New Framework Plans change the PST's functional role: Under Old Framework Plans, the Participant Statement of Goals and Aspirations (s33(1)(a)) was the formal starting point of the plan. Under New Framework Plans (s32D(1)), the statement still exists but functions as a contextual input to the Needs Assessor's determination, not as an independent driver of funding. The PST was designed for the Old Framework architecture. It remains legally grounded (the statement is still required), but its purpose must be reframed.Under New Framework Plans, the PST must function as a translation layer — converting the participant's lived experience and goals into the functional impairment language that Needs Assessors use. This is a framing shift, not a tool redesign. The data captured by the PST is still the right data; it just needs to flow into a different analytical framework at the planning meeting.B — Andrew's Goal 5b provides a design mandate: Goal 5b explicitly calls for "an innovative Participant Statement of Goals and Aspirations that links to the insights behind the hybrid coaching and coordination approach." This is Andrew directing the PST to evolve to serve the hybrid SC/PRC model — not just the participant's goals in isolation, but the PST as a tool that proves why the hybrid model is the right intervention for this participant.NbLM finding: NotebookLM confirmed that Goal 5b is the strategic mandate that originally gave rise to Component #4. The PST and Goal 5b are the same product — but the brief needs updating to reflect the New Framework Plan context and Andrew's evolved vision.Summary of gaps: PST brief does not cite SD-IFC-2026-001 (mechanical — known carry-over from yesterday) PST brief does not address New Framework Plans (Old Framework-only framing) PST brief does not incorporate Goal 5b's hybrid model integration mandate Severity: High. The PST brief is the most out-of-date component brief in the portfolio. Recommend this be the first brief to receive a formal update.Yesterday's status: Active, 14/14, filed.Today's impact: Andrew's Goals 4 and 5a both relate to this component, and together they expand its scope.Goal 5a — Benchmark recovery plan for dual-role practitioners: This maps directly to the existing Component #5 brief. The CHIME-D framework and NDIS Outcomes crosswalk already captured. However, Andrew adds one new specification: the plan must align with dual progress reporting requirements (one report for coordination, one for coaching). This is a compliance-specific design constraint not currently in the brief.Goal 4 — Practitioner Best Practice Guide: This is a practitioner-facing compliance guide helping coordinators understand what PRC is, how it differs from SC, and how to meet compliance requirements (no duplication; demonstrate capacity-building trajectory; connect to core supports over time). This maps to the Practice Rationale document embedded in Product Brief: 02 — which is already substantially written.Critical question: Is Goal 4 a sub-component of Component #5, or a new, separate component? The distinction matters for P3 architecture: Sub-component of #5: Keeps the portfolio at five components. The recovery plan and the practitioner guide are complementary practitioner-facing tools. New Component #6: Reflects the fact that Goal 4 is a standalone practitioner-facing product with a different audience, purpose, and use case from the benchmark recovery plan. The current P3 inventory doesn't accommodate this cleanly. This is a structural decision for Brian.Severity: Medium. Goal 5a can be absorbed into the existing brief as a design constraint update. Goal 4 requires a structural decision.Updated 2026-05-11 following Brian's structural decisions on Q-023 and Q-024.Decision A — Component #3 (Q-023): Brian confirmed embed in Component #1 as Loop 4. Actioned 2026-05-11.Decision B — Goal 4 / Practice Rationale (Q-024): Brian confirmed this is not a product component — route to wiki as a territory report candidate. Actioned 2026-05-11. Territory report design dropping in Droppings/.Gap analysis produced: 2026-05-11. Updated: 2026-05-11 following Brian's decisions. Baseline: P3 artefacts at end of 2026-05-10 session.
product-brief-participant-statement-toolkit — Identified the PST as the highest-priority update target, flagging three specific gaps: the New Framework Plan framing absent from the brief, the Goal 5b hybrid model mandate not incorporated, and the missing SD-IFC-2026-001 citation; provided the analytical basis for subsequent PST brief revision priorities
product-brief-psychosocial-recovery-plan — Assessed Component #5's gaps against Andrew's Goals 4 and 5a; identified the dual progress reporting constraint as a design requirement not yet in the brief, and provided the analytical basis for routing Goal 4 to the wiki territory report class rather than treating it as a new product component
product-brief-visual-guide-ndis-plan — Confirmed Component #1 is validated by Andrew's Goal 1; identified the Old/New Framework Plan distinction as a minor addendum need; provided the gap analysis basis for the structural decision to absorb Component #3 as Loop 4
product-brief-visual-guide-service-agreement — Confirmed that the R106 SC/PRC choice is the instrument of informed consent for the hybrid model itself; identified G-01 (visual design approach) as a medium-priority gap requiring resolution before the component is production-ready
strategy-dossier-ifc — Identified three programme-level gaps in the Strategy Dossier: the commissioning window absent from the Epoch Definition, the Practice Rationale unregistered as a "Now" element in the Capability Assessment, and the commissioning context absent from the Value Rationale; provided the analytical basis for Saga Entry 002
p3-index — Used as the programme governance framework reference for artefact status tracking; the Baseline State table and Summary Table reference P3 artefact locations and attribution requirements ]]>navv-operational/gap-analysis-product-brief-02-vs-p3-baseline.htmlNAVV-Operational/Gap Analysis - Product Brief 02 vs P3 Baseline.mdSun, 17 May 2026 01:33:50 GMTproduct-brief-ndis-wiki — Describes the five-level delivery maturity model for the NDIS Wiki platform, providing the technical architecture vision, technology preferences (Python, open-source, Neo4j), and cross-level design principles (graph-migration-friendly metadata, L2 disposable prototype mandate) that govern the product's technical delivery roadmap from current state to national scale This document's conclusions are based on the state of referenced artefacts at the time of authorship. Subsequent changes to dependencies may affect applicability.]]>navv-operational/maturity-mud-map-wiki-to-web-transition.htmlNAVV-Operational/Maturity Mud Map - Wiki to Web Transition.mdSun, 17 May 2026 01:33:50 GMTp3-index — The canonical design authority for the three-tier waterline architecture governing all P3 document classification; defines Deep Ocean, Below the Waterline, and Above the Waterline tiers and their governance rules This document represents a point-in-time analysis. Subsequent decisions or implementation changes may supersede specific recommendations or assessments contained herein.Type: Design Specification — Revised following Brian's 2026-05-14 feedback (single-root question)
Commissioned by: Brian, via Missives/NAVV-2026-05-14 Date: 2026-05-14
Supersedes: Droppings/NAVV Wiki - Waterline Taxonomy and Information Architecture v2 Status: Pending Brian's approval before any restructuring beginsChanges from v2: Single NAVV-Wiki/ root folder introduced — one wiki, three tiers P3-Governance/ moves inside NAVV-Wiki/ (logical constitutional independence retained) CaaG standards remain at project root (cross-wiki scope) Wiki agent infrastructure (registry, wiki CLAUDE.md) placed at NAVV-Wiki/ level All v2 design decisions and CaaG decisions remain in force — unchanged Brian's approvals to date (all in force for v3): Flat sub-folder structure within NAVV-Operational/ (#approved/brian) Web navigation model: P3 artefact-centric primary (#approved/brian) Traceability header format (#approved/brian) CaaG Tier A as minimum standard for NAVV-Operational documents (#approved/brian) Registry bootstrap as Stage A before Candidate Audit (#approved/brian) Linter commissioned after registry bootstrap (#approved/brian) Brian's question cuts to the architectural heart: are we building three independent tier-folders, or one integrated wiki with three tiers?Answer: One integrated wiki.The v2 proposal (three separate top-level folders) created a structural problem that Brian correctly identified. Three independent folders at project root means: No shared coordination point for wiki-managing agents No shared registry root — registry scope becomes ambiguous Brian managing three separate structures — "a pathway to hell" Agents cannot traverse from the operational tier to the canonical record without reaching across sibling folders The correct structure mirrors the NDIS-Wiki pattern: one root folder that owns the entire wiki management infrastructure, with the tier structure nested inside it.NAVV-Wiki/ is that root.NDIS-Wiki/ is not the wiki itself — it is the root of the entire wiki management infrastructure. Inside it lives: The article folders (concepts/, topics/, legislation/, etc.) The registry (registry.json) The CLAUDE.md (wiki agent constitution) The raw content, quality logs, tools, etc. Autonomous agents managing the NDIS wiki are rooted at NDIS-Wiki/ — they do not need to reach outside that folder to do their work.NAVV-Wiki/ follows the same pattern. It is the coordination root for all agents managing NAVV's governance wiki. Everything the NAVV wiki needs — across all three tiers — lives inside NAVV-Wiki/.NAVV-NDIS-Handbook/ ├── NAVV-Wiki/ Single root — NAVV governance wiki (all three tiers) — NEW ├── NDIS-Wiki/ NDIS product wiki — existing, unchanged ├── Context as a Graph (CaaG)/ Shared CaaG standards — cross-wiki, stays at root ├── Droppings/ Ephemeral working space — unchanged ├── Andrew-Interface/ Andrew interaction material — unchanged ├── Missives/ Control artefacts — unchanged ├── Standards/ Control standards — unchanged ├── Stock-Takes/ Audit reports — unchanged ├── History/ Historical records — unchanged ├── Sandpit/ Experimentation — unchanged └── Tools/ Project tools — unchanged NAVV-Wiki/ ├── P3-Governance/ Deep Ocean — moved from project root (see Section 4) │ ├── Principles/ │ ├── Products/ │ ├── Strategy/ │ ├── Governance/ │ ├── Maturity/ │ ├── Patterns/ │ ├── Charters/ │ ├── Sagas/ │ ├── P3-Reference/ │ └── P3-Index.md ├── NAVV-Operational/ Below the Waterline — new (flat structure) ├── NAVV-Commercial/ Above the Waterline — new (placeholder) ├── navv-registry.json NAVV wiki entity registry — new └── CLAUDE.md Wiki agent constitution — new (wiki-scoped) The CaaG standards govern multiple wikis — currently the NDIS-Wiki and the NAVV-Wiki. Placing Context as a Graph (CaaG)/ inside NAVV-Wiki/ would incorrectly imply it is NAVV-specific. It remains at the project root as cross-wiki infrastructure.When agents need CaaG standards while working within NAVV-Wiki/, they reach up one level. This is the only cross-boundary reference from NAVV-Wiki/ agents, and it is explicitly scoped to read-only reference standards.P3-Governance/ moves from NAVV-NDIS-Handbook/P3-Governance/ to NAVV-NDIS-Handbook/NAVV-Wiki/P3-Governance/.The folder contents are unchanged. The separation guarantee is unchanged.The P3-Index.md states: "Deleting P3-Governance/ must not affect any product artefact."This guarantee is a logical property, not a filesystem property. Moving P3-Governance/ inside NAVV-Wiki/ does not change the logical guarantee — it means: The contents of P3-Governance/ do not embed or depend on product artefact files Product artefact files (NDIS-Wiki/, etc.) do not depend on P3-Governance/ being at any particular path P3-Governance/ retains its constitutional independence as the canonical governance record
Obsidian resolves WikiLink by file name, not by full path. Moving P3-Governance/ inside NAVV-Wiki/ does not break any existing wiki links that use bare file names (e.g., Direction Statement, NAVV Principles Register - 2026-05-08). These will continue to resolve correctly.Any references that use full paths (e.g., in CLAUDE.md or control documents) will need to be updated — this is a one-time migration task, not an ongoing burden.The P3-Governance/ move is a structural change to existing canonical content. Nothing moves until Brian explicitly confirms.
Approve the move of P3-Governance/ from the project root into NAVV-Wiki/. #action/brian With NAVV-Wiki/ as the common root:Single coordination point: Agents managing the NAVV wiki are rooted at NAVV-Wiki/. They can access all three tiers without crossing outside their root.Registry scope: navv-registry.json at NAVV-Wiki/ level covers all entities in all three tiers — Deep Ocean artefacts in P3-Governance/, operational documents in NAVV-Operational/, and commercial documents in NAVV-Commercial/.Wiki CLAUDE.md scope: A CLAUDE.md at NAVV-Wiki/ level governs wiki agent behaviour — article standards, link protocol, CaaG tier requirements, linter rules. This is separate from the project-level CLAUDE.md (which governs the broader project sub-agent behaviour).Agent independence from NDIS-Wiki: NAVV-Wiki/ agents do not enter NDIS-Wiki/ and vice versa. Cross-wiki federation (the CaaG graph) is managed at the project root level when that work commences.All v2 staging decisions remain in force. The single-root architecture adds one step to Stage A:Stage A — Foundation (revised) Create NAVV-Wiki/ folder at project root Move P3-Governance/ into NAVV-Wiki/ — Brian's explicit approval required first Create NAVV-Wiki/NAVV-Operational/ and NAVV-Wiki/NAVV-Commercial/ (placeholder) Bootstrap navv-registry.json at NAVV-Wiki/ level — register all Deep Ocean artefacts Create NAVV-Wiki/CLAUDE.md — wiki agent constitution Establish the Tier A document template for NAVV-Operational documents Update any full-path references in project-level control documents (CLAUDE.md, P3-Index.md) Stage B — Below-the-Waterline build (unchanged from v2) Stage C — Linter WP (unchanged from v2) Stage D — NDIS-Wiki CaaG retrofit (future, unchanged from v2)One open decision remains (all others resolved):
Approve the single NAVV-Wiki/ root folder architecture as described in Section 3. #action/brian
Approve the move of P3-Governance/ into NAVV-Wiki/ (Section 4). #action/brian Once both are approved, Stage A can commence.Prepared by Sonnet — 2026-05-14
Commissioned via Missives/NAVV-2026-05-14]]>navv-operational/navv-wiki-waterline-taxonomy-and-information-architecture-v3.htmlNAVV-Operational/NAVV Wiki - Waterline Taxonomy and Information Architecture v3.mdSun, 17 May 2026 01:33:50 GMTR-00001 - Initiation — P3 project brief - R-00003 - Planning — Original seven-objective plan - R-00024 - Execute task skill — Request that produced the execute-task skill - _Skills/execute-task — The skill itself - 2026-04-22 - Experimental Outcomes and Recommendations — Final scoring report This analysis captures lessons learned from P3 experiments regarding token offload and caching implications for the NAVV system. It distills operational insights from experimental runs into documented guidance for future architecture decisions. The document refines the project's understanding of performance constraints and optimization strategies.
REFINES: workflow-patterns — Analyses token cost implications of the P3 experimental phase and derives workflow design principles for agent context and token budget management, informing agent routing and session design patterns This document's conclusions are based on the state of referenced artefacts at the time of authorship. Subsequent changes to dependencies may affect applicability.Date: 2026-04-25 Prepared by: Sonnet (Sub-agent Manager)
Source: Missive NAVV-2026-04-25 — Item 1 Documents Reviewed:
R-00001 - Initiation — P3 project brief
R-00003 - Planning — Original seven-objective plan
R-00024 - Execute task skill — Request that produced the execute-task skill
_Skills/execute-task — The skill itself
2026-04-22 - Experimental Outcomes and Recommendations — Final scoring report The P3 experiment tasked a local LLM agent (not Sonnet — a local Ollama model) with normalising a complex knowledge graph and its associated entity Wiki: renaming files, standardising IDs, cleaning WikiLinks, and reconciling a shadow-graph against a master graph. The experiment ran through multiple replanning cycles before converging. A final Sonnet-level review scored the overall outcome at 6.5/10.The core infrastructure it operated on: ~215 entity .md files A Theory-Context-Graph.json master graph A Python-generated shadow-graph for reconciliation A bulk entity-mapping JSON (186 → 439 mappings) This is structurally analogous to our NAVV wiki — a growing set of interlinked .md articles, a registry as the master reference, and a need for ongoing normalisation and enrichment.The P3 experiment used Python scripts to: Extract all WikiLinks from 215 entity files and build a shadow-graph Generate an entity-mapping JSON with 186 entries (later 439) Perform 227 link replacements across 124 files Rename 101 files from coded format to fluent English Remove 30 non-existent ghost links from 30 files Crucially, none of this work consumed LLM tokens. The scripts were written once (by the agent) and re-run repeatedly. The LLM's token cost was limited to designing the script, not executing it.NAVV implication: We already have registry.py — this is the right pattern. Every bulk operation that registry.py can do (inject-links, QA checks, registry lookups) costs zero LLM tokens per run after the initial build. We should aggressively extend registry.py capabilities rather than having Sonnet or Haiku iterate over files manually.
The _Skills/execute-task skill enforces a Plan → Execute → Verify cycle for every task. Critically, it requires: Explicit inputs and outputs defined before execution starts A procedural test (bash/grep/python) — not an LLM judgment — as the definition of done The experimental report found that when this skill was applied (tasks T-0033 to T-0038), the work was more disciplined and the outputs were more consistent. When it was not applied (the earlier tasks), inconsistencies accumulated and required a costly remediation cycle.NAVV implication: Our ingestion workflow phases already have some of this structure, but verification steps are still largely LLM-assessed. The lesson is: if we can write a bash command or a Python assertion to verify an output, we should — and the LLM should not be doing the verification at all.The execute-task skill creates something important: a task spec that is detailed enough for a lower-capability model to execute. The spec includes inputs, outputs, transformation steps, edge case handling, and acceptance criteria. Once that spec exists, the executing agent does not need to reason — it just follows the runsheet.The P3 local agent (far less capable than Haiku) was able to execute renaming, link-fixing, and mapping tasks reliably when given a clear spec. It failed where the spec was ambiguous — not because it lacked capability, but because the instructions weren't clear enough.NAVV implication: Our RS ingestion is currently end-to-end Sonnet. Applying the execute-task pattern would let us decompose the ingestion into:Under this model, Sonnet costs drop to: task planning (once per RS doc), article enrichment (D), and the Ingestion Report (G). Everything else becomes script or Haiku.The P3 experiment's most expensive failure was that naming conventions (file name format, ID format, WikiLink format) were revisited three times. Each revision required remediation that consumed the local agent's entire remaining budget.The experimental report recommends: produce a decision table that specifies, for each entity domain, what the file name, ID field, and WikiLink form looks like — and lock it as a separate artefact before any execution begins.NAVV implication: Our registry IS our convention lock. As long as the registry schema is stable and authoritative, Haiku can work against a clear spec. But this means: we must not change the registry schema mid-ingestion. Registry schema decisions must precede execution, not emerge from it.The P3 report identified that the same agent that executed tasks also wrote the verification tests. The tests were too narrow — they verified what the agent knew to check, not what was actually required. 62 compound WikiLinks were missed because the verification regex only targeted bare coded links.NAVV implication: Our current QA steps have the same vulnerability — Sonnet designs the check and reports on it. Two countermeasures: Use script-based verification where the assertion is mechanical and not LLM-authored (registry.py can do this) Where LLM judgment is unavoidable, have Haiku do the verification check against Sonnet's output — two independent passes The experimental report notes that two of the original seven objectives (Acronym Linking, Unlinked Concept Detection) were simply never attempted — they were silently dropped as the project evolved. No one noticed until the final review.NAVV implication: We should maintain an explicit "outstanding and deferred" log for each RS ingestion. After each RS run, any item that was scoped but not completed should be formally deferred — not silently abandoned. This is a low-token cost (a single Haiku-level append to a log file) but prevents accumulating unknown gaps. Registry lookup: does this concept already exist? Link injection: registry.py inject-links Field completeness QA: does this article have all required frontmatter? Duplicate detection: are there two stubs for the same concept? Shadow-graph equivalent: which concepts in the source doc have no wiki article yet? Phase A extraction: structured extraction of claims from source documents, given an extraction schema Phase C stub creation: populate article template from registry entry + extracted claims Phase F QA pass: Haiku reads Sonnet's article output and checks it against a rubric Deferred-items log update: append deferred items to outstanding log at end of each run Task planning: design the phase specs and extraction schema for each RS doc Phase D enrichment: deepen articles requiring semantic synthesis across multiple sources Phase G Ingestion Report: narrative summary for Brian and Andrew Registry schema decisions: whenever a schema gap or ambiguity is found Before the RS-05 run, produce a Phase Specification document for the RS-05 ingestion using an execute-task-style format: What are the inputs? What are the outputs? What is the transformation for each phase? What is the procedural verification (bash/python)? Which phases will be Haiku and which Sonnet? This planning investment (one Sonnet session) would create a repeatable template applicable to all future RS runs — and it is exactly what the P3 experiment lacked from the start.
Dropping closed — all items from Missive NAVV-2026-04-25 Item 1 addressed.]]>navv-operational/p3-experiment-lessons-token-offload-implications.htmlNAVV-Operational/P3 Experiment Lessons - Token Offload Implications.mdSun, 17 May 2026 01:33:50 GMTp3-state-machine-insights — Identifies the state machine governance question raised by the P3 portal concept and provides the analytical framing that informed the state machine design work
PART-OF: p3-index — Assesses the P3 portal concept as a candidate P3-Governance artefact and records the decision to proceed with P3 wiki components before portal governance design This document's conclusions are based on the state of referenced artefacts at the time of authorship. Subsequent changes to dependencies may affect applicability.Type: Strategic Analysis
Commissioned by: Brian, via Missives/NAVV-2026-05-13 Date: 2026-05-13 Question: Does the P3 State Machine block the P3 Portal, or is it the price of entry — and if so, can we pay that price at current maturity?Brian proposes a hybrid web application — P3 Portal — to give Andrew direct, steerable access to: A P3 Wiki — wiki-style view of NAVV's product portfolio and P3 artefacts, with dispute and approval mechanisms An interactive dashboard — portfolio status, viewable through two lenses: P3 artefact view and traditional business portfolio view The strategic goal: reduce the turnaround friction between Brian and Andrew by removing Brian as the intermediary for artefact access and review decisions.This analysis endorses the goal unambiguously. Brian-as-intermediary is a scaling constraint that compounds. Every time Andrew needs a document, a status view, or wants to provide feedback, the path runs through Brian. This is not a workflow inefficiency — it is a structural ceiling on NAVV's operating tempo. The P3 State Machine Insights document names the analogous failure in agentic governance ("token dumpster fire"), but the human equivalent is just as real: every mediated interaction is friction, and friction compounds into inertia.The proposal is architecturally sound at the concept level. The question is not whether to build it, but when and in what scope.
P3-Reference/L1-Bootstrapping/P3 State Machine Insights is unambiguous: the state machine is not a feature of the P3 harness — it IS the harness. The document's instruction is specific: build it before the first agent takes its first action, because retrofitting it later means building around structure that has already been laid without bulkheads.Translated to the P3 Portal: if Andrew can directly change the state of P3 artefacts through the portal — approve a Product Brief, update a strategy direction — without those actions being gated by governance mechanics, drift begins from day one. The difference between the NDIS Wiki and the P3 Wiki is critical here:In the NDIS Wiki, Andrew's approval is a review action. In the P3 Wiki, Andrew's approval of a Product Brief or Strategy Dossier is a Sentinel action — it changes the formal constitutional record of the organisation. These are categorically different. The state machine is needed for the P3 Wiki's approval mechanism precisely because of this difference.Yes — for write-path actions in the P3 Wiki. Any mechanism that lets Andrew formally change the state of a P3 artefact (approve, retire, supersede) needs governance gating. Without it, drift is structural, not accidental.No — for the read path and dispute submission. Andrew can browse P3 artefacts, read product briefs, and submit disputes without a state machine. Dispute submission is read-only from a governance perspective — it is a signal to the state machine operator (Brian), not a state transition itself.The State Machine Insights document offers a critical release valve that is easy to miss: "Test it with no agents at all — just human beings triggering transitions manually." The state machine does not need to be automated software first. It needs to be a deterministic governance protocol first. The protocol can be manually executed by Brian as state machine operator, and automated incrementally as maturity increases.At current maturity (Stage 2/3 scaffolding complete, Stage 5 governance structures pending), the viable sequence is: Design the protocol — define the valid state transitions for P3 artefacts in the Portal (what Andrew can do, what Brian gates, what escalation paths exist). This is Stage 5 governance work, concentrated into what the Portal actually needs. Build the Portal with the protocol as the access model — Andrew's write-path actions are constrained to what the protocol allows. Initially, this means: Andrew submits disputes; Brian processes and approves state changes. The portal reflects the outcome. Automate the state machine incrementally — as the protocol proves stable, automate the mechanical checks (predicate validation, Saga generation, Air Gap enforcement). The automation replaces Brian-as-operator, not the governance structure. This is not a compromise on the architectural principle — it is the correct implementation sequence the document describes.The P3 Portal proposal naturally separates into two independently scopeable components:Component A — P3 Wiki (MVP viable at current maturity) Andrew can browse P3 artefacts (Product Briefs, Strategy Dossiers, Direction Statement, Principles) Andrew can submit disputes and flag concerns — exactly the NDIS Wiki dispute model Andrew cannot directly approve state changes — those route to Brian as state machine operator Reuses the NDIS Wiki's dispute pipeline and corrections queue architecture Component B — Dashboard (future scope, separate work package)The dashboard — two-view portfolio visualisation — is a significant additional scope item requiring its own data model and rendering architecture. It is independent of the wiki component and should not block it. At current maturity, the data it would show (product status, programme progress) can be read from the P3-Governance artefacts. The dashboard is a visualisation layer over existing data.Recommendation: scope Component A now; treat Component B as a future work package. The wiki provides the majority of Andrew's friction reduction without the dashboard complexity.One structural clarification for the builders: the P3 Wiki is a view on the canonical artefacts in P3-Governance/. It is not the canonical record. When Andrew approves a corrected article in the P3 Wiki: The state machine protocol governs what happens next (Brian reviews and updates the canonical P3-Governance file) The P3 Wiki article reflects the outcome of that governance action The Saga records the full transition This is the Air Gap principle applied to the portal: Andrew interacts with the view; the canonical record is never directly edited through the portal. Endorse the P3 Portal concept — the friction reduction goal is correct and urgent. Scope Component A (P3 Wiki) for this epoch. Reuse the NDIS Wiki architecture: Obsidian export → HTML pipeline → dispute/corrections queue. The structural work is largely already done. Design the minimal state machine protocol as part of P3 Stage 5 work — not a full software implementation, but a formal written protocol defining valid P3 artefact state transitions and governance gates. This is the "test with human beings first" step. It is pre-requisite for Component A. Defer Component B (Dashboard) — important but not urgent. One work package at a time. The Portal must not give Andrew direct write access to the canonical P3-Governance artefacts — disputes only, with Brian as state machine operator for the transition from disputed to approved-and-applied. Q-028: Does Brian want to initiate Stage 5 (Governance Structures / state machine protocol design) as the next P3 work package — before any portal build begins — or does he want to defer Stage 5 and proceed with Component A under a provisional protocol?Both paths are viable. The first is more correct architecturally. The second is faster. Brian should decide given current capacity.Prepared by Sonnet — 2026-05-13
Commissioned via Missives/NAVV-2026-05-13]]>navv-operational/p3-portal-analysis-concept-assessment-and-state-machine-question.htmlNAVV-Operational/P3 Portal Analysis - Concept Assessment and State Machine Question.mdSun, 17 May 2026 01:33:50 GMTproduct-brief-ndis-wiki — Designed the dispute and correction workflow through which Andrew reviews and feeds back on NDIS Wiki articles, a core quality governance mechanism for the product This document represents a point-in-time analysis. Subsequent decisions or implementation changes may supersede specific recommendations or assessments contained herein.Type: Architectural Design
Commissioned by: Brian, via Missives/NAVV-2026-05-13 Date: 2026-05-13 Status: For Brian's review and guidanceThe dispute pipeline modifies wiki articles in Obsidian then re-exports them as HTML. Those corrected HTML files are safe to rsync to the server — they are static content and do not clash with anything.The problem is the state file. navv-page-state.json on the server is a living document that Andrew is actively writing to as he approves and disputes pages. We pulled a snapshot of it at the start of the dispute batch. We cannot safely upload our snapshot back to the server, because Andrew may have changed additional pages since then. An overwrite would destroy those changes.At the same time, Andrew needs to know which pages have been corrected — so he can go back, re-read the corrected version, and formally re-approve it. Without that notification, Andrew has no visibility into what changed or why.The safest architectural principle for managing shared state is: every data file should have a single authoritative writer.Applied here: navv-page-state.json — Andrew writes it. The pipeline never touches it. Andrew's actions in the status page UI are the only source of truth for approval status. navv-corrections-queue.json — The pipeline writes it. This is a new, separate file listing corrections that are ready for Andrew's review. The pipeline appends to it; Andrew reads from it. With this separation, there are no write conflicts. The two files are entirely independent concerns.A new file: navv-corrections-queue.json — maintained by the dispute pipeline, uploaded to the server independently of navv-page-state.json.The pipeline appends a record to this file each time a dispute batch completes. Each record describes what was corrected, when, and why.[ { "correction_id": "DR-001", "article_slug": "concepts/participant-statement", "article_title": "Participant Statement", "correction_date": "2026-05-13", "correction_summary": "Corrected s33(2) scope — rollover breach now correctly conditioned on whether a statement was submitted. Previously stated unconditionally.", "dispute_type": "Factual Error", "reviewed_by_andrew": false, "reviewed_date": null } ] After each batch completes, Brian uploads navv-corrections-queue.json in the same rsync step as the corrected HTML:rsync -avz navv-corrections-queue.json deploy@96.126.96.225:/var/www/NDIS-Wiki-HTML/navv-corrections-queue.json This is a separate file from navv-page-state.json and does not interact with it.Brian's direction is that the status page should become a multi-component report, and that the design should anticipate further components being added over time.The right pattern here is a panels architecture: the status page is a container that renders a list of registered panels. Each panel has its own data source and its own rendering logic. Adding a new panel means registering a new panel definition — the container does not need to change.The status page should use a clear visual hierarchy: Each panel is a distinct section with a header, a brief description of what it represents, and its content below. Panels that have no content (empty corrections queue, etc.) should display a clean "nothing pending" message — not be hidden entirely. Hiding panels would obscure the growing structure of the system from Andrew. The Pending Corrections panel should list each correction as a card or row, showing: article title, date corrected, and a plain-English summary of what changed. Each correction card has a "Mark as Reviewed" button. Andrew uses this to acknowledge he has re-read the corrected article and accepts the change. Revised 2026-05-13 — Brian identified a false-approval risk in the original design."Mark as Reviewed" means I have read this correction — nothing more. It does NOT record approval.When Andrew clicks "Mark as Reviewed" on a correction: The local server sets reviewed_by_andrew: true and reviewed_date in navv-corrections-queue.json for that correction. navv-page-state.json is not touched. The page's approval status is unchanged. The correction card visually confirms the acknowledgment (greyed out, "Reviewed ✓"). Andrew's decision after reviewing (two paths):Why this is correct: The original design conflated acknowledgment with approval. Andrew may review a correction and find it insufficient — in that case, auto-setting the page to "Approved" would create a false record. Under the revised design, the corrections queue tracks only whether Andrew has been notified. Approval remains entirely in Andrew's hands via the existing mechanism. No new approval logic is needed.Panel UX note for Builder agents: The Pending Corrections panel should include a short note near the "Mark as Reviewed" button explaining its meaning: "Marking as reviewed means you've read the correction. To approve or re-dispute the page, use the Approval Status panel above."For current maturity: leave them in the queue with the reviewed_by_andrew: true flag. Do not delete them. They become a tamper-evident record of what was corrected and when Andrew accepted each change.At higher maturity levels, a periodic archive process could move reviewed corrections to a separate history file. But for now, the reviewed items serve as an audit trail — which is consistent with the project's traceability requirements.The following changes are required in NDIS-Wiki-HTML: New file managed by pipeline: navv-corrections-queue.json (pipeline generates; Builder agents read only) New server endpoint (local-server.py): POST /api/corrections/mark-reviewed — accepts correction_id; sets reviewed_by_andrew: true and reviewed_date in navv-corrections-queue.json only. Does NOT touch navv-page-state.json. Andrew approves or re-disputes separately via the existing Approval Status panel. Status page — Panels Architecture: Refactor the status page to a panels-based structure. Two panels initially: Approval Status (existing), Pending Corrections (new). Pending Corrections panel: Reads navv-corrections-queue.json. For each unreviewed correction, renders a card showing: article title, date corrected, correction summary, and a "Mark as Reviewed" button. For reviewed corrections, renders a greyed-out "Reviewed" row (audit trail visible but not prominent). Empty-state handling: If navv-corrections-queue.json is absent or has no unreviewed corrections, the Pending Corrections panel shows "No corrections pending review." Brian mentioned a future reconciliation report that identifies discrepancies between stored state and the server. At current maturity: leave it aside. But the panels architecture explicitly accommodates it — a Reconciliation panel would simply be another registered panel with its own data source. Nothing in the current design closes off that path. Never upload navv-page-state.json from the pipeline. That file is Andrew's territory. Only Andrew's UI actions write to it. The corrections queue is append-safe. Multiple batches can append records without conflict. If two batches run close together, later records simply accumulate in the queue. If navv-corrections-queue.json does not yet exist on the server: the first upload creates it. The panel handles a missing file gracefully (renders as empty). Prepared by Sonnet — 2026-05-13
Commissioned via Missives/NAVV-2026-05-13]]>navv-operational/change-feedback-architecture-andrew-review-loop.htmlNAVV-Operational/Change Feedback Architecture - Andrew Review Loop.mdSun, 17 May 2026 01:33:50 GMTproduct-brief-ndis-wiki — Defines the reporting structure and data architecture for the NDIS Wiki knowledge ingestion pipeline, including format and metadata conventions for research synthesis outputs This document represents a point-in-time analysis. Subsequent decisions or implementation changes may supersede specific recommendations or assessments contained herein.Type: Design analysis dropping — for Brian's consideration Prepared by: Sonnet sub-agent manager — 2026-04-20 Trigger: NAVV-2026-04-20 Q: — Andrew's need for structured ingestion reportingAndrew needs three things after each research ingestion: A list of new documents created from his research A list of existing documents updated with insights from his research A list of new stubs — topics identified but not yet researched, to guide his next session The current Log.md contains all this information, but it is: Mixed with system maintenance chatter (path corrections, normalisation passes, deletions) that is noise for Andrew Written for auditability, not readability Not scoped by research session — no way to filter "what came from RS-02" without reading the whole file Redesign the log so it has two sections: a clean "Research Sessions" section and a separate "System Operations" section.Verdict: Not recommended.The log serves two fundamentally different purposes: an audit trail (for us) and a research summary (for Andrew). Trying to serve both makes it worse for both. System entries will always accumulate and pollute the Andrew-facing view. Structural separation within a single file creates a maintenance burden with no architectural benefit.At the end of Phase E, Sonnet generates a clean Ingestion Report scoped to that session and either saves it to a reports/ folder or pushes it directly to Andrew's NbLM notebook.Structure of the report:## RS-02 Ingestion Report — 2026-04-20 ### New articles created - [article title] — [one-line summary] - ... ### Existing articles updated - [article title] — [what was added] - ... ### New stubs (topics identified — awaiting research) - [topic name] — [brief context on why it was flagged] - ... ### Suggested research directions for Andrew's next session [Sonnet's synthesis of what the stubs reveal about knowledge gaps] Verdict: Recommended for the near term. This is clean separation with no sync problem IF the report is generated from Log.md at Phase E completion, not maintained separately. It becomes a derived output, not a separately maintained artefact.The report also has a natural delivery path: push it to Andrew's NbLM notebook via source_add as part of Phase E completion. Andrew reads it in his familiar environment. No new file format. No Obsidian navigation required.Convert Index.md or Log.md to a JSON data structure, then programmatically generate all downstream artefacts (reports, views, Andrew-facing summaries).Analysis:Brian's instinct here is architecturally sound for a mature, high-volume system. Structured data enables: Programmatic filtering by session, status, folder, date Multiple rendered views from a single source of truth Consistent formatting without agent interpretation However, three constraints make this premature right now:Constraint 1 — Scale. The wiki currently has 33 articles. JSON overhead is not justified until the index grows to 150–200 entries or ingestion cycles run monthly with 50+ articles each. At current scale, a well-structured Markdown log with session IDs is equivalent in queryability.Constraint 2 — Agent reliability. The local gemma agent must write the JSON. LLMs are unreliable JSON writers — malformed output is a real risk that would corrupt the backing store. Markdown is forgiving; JSON is not.Constraint 3 — Obsidian-native integration. All operations must be actionable from Obsidian (as per CLAUDE.md). JSON files are not Obsidian-native. Rendering them as Markdown views requires a build script that does not currently exist in the pipeline, and adding one introduces a new operational dependency Brian would need to manage.Verdict: Defer. Revisit when any of these conditions are met: Index grows beyond 150 articles Ingestion runs more than once per month A script runner is established and stable in the pipeline Short term (now): Add Ingestion Report to Phase E — at the end of Phase E, Sonnet generates a clean per-session report (see structure above) and saves it to NDIS-Wiki/reports/RS-[slug]-report-YYYY-MM-DD.md. Sonnet also pushes it to Andrew's NbLM via source_add. Add session scope to Log.md entries — a minor log format change: prefix each ingest session block with a session ID tag (e.g., [RS-02-2026-04-20]). This costs nothing now and enables programmatic extraction later without a full JSON migration. Mid term (next few research cycles): Stubs Queue in Overview.md — the "Stub articles" section of Overview.md is already maintained. Expand it to include a one-line research direction for each stub, derived from the context in which the stub was created. This gives Andrew a curated research queue in his primary entry point. Longer term (if/when scale warrants it): JSON backing store — if the above constraints are met, migrate Index.md to a JSON file (index.json) and regenerate Index.md as a rendered Markdown view. At that point, Ingestion Reports, stubs queues, and Andrew-facing summaries all become programmatic outputs. The short-term recommendation (Ingestion Report + session IDs) is low-risk and immediately actionable. It does not lock in any architectural decision and positions us well for the JSON path if we need it later.Questions for Brian: Agree with short-term approach (Ingestion Report at Phase E + session IDs in Log)? Should the Ingestion Report be pushed to Andrew's NbLM automatically as part of Phase E, or held for Brian's review first? For the stub research directions — should these be generated by Sonnet (from the source context) or by Andrew's own queries in NbLM? These questions can be answered in the next missive or flagged as #action/brian items.]]>navv-operational/design-ingestion-reporting-and-data-architecture.htmlNAVV-Operational/Design - Ingestion Reporting and Data Architecture.mdSun, 17 May 2026 01:33:50 GMTproduct-brief-ndis-wiki — Defines the triage protocol for article disputes, specifying how disputed articles are routed, reviewed, corrected, and re-published within the NDIS Wiki product
SUPPORTS: workflow-patterns — Contributes a dispute triage workflow pattern applicable across any NAVV product where stakeholder review and correction cycles are required This document represents a point-in-time analysis. Subsequent decisions or implementation changes may supersede specific recommendations or assessments contained herein.Type: Process Design — Revised
Commissioned by: Brian, via Missives/NAVV-2026-05-12 Date: 2026-05-12 (revised same session after Brian's feedback) Revision note: Initial draft revised to incorporate Brian's six design principles: orchestrator/executor separation, batch-first analysis, complexity routing, token efficiency, typology recording, and skill design.Six principles govern this design:Orchestrator: Sonnet │ ├── Step 1 — Sync trigger (Brian action) │ ├── Step 2 — Batch Inventory and Analysis (Sonnet orchestrates) │ ├── List all disputed pages │ ├── Assess per-dispute complexity │ ├── Check inter-article dependencies │ ├── Cluster by type and root cause │ └── Produce batch plan → present to Brian for Validated Fix approval │ ├── Step 3 — Execution (delegated per routing plan) │ ├── Local Agent (Ollama/gemma4) — deterministic Quick Fixes │ ├── Haiku sub-agent — moderate Validated Fixes │ └── Sonnet sub-agent — complex multi-article or legal-interpretation fixes │ ├── Step 4 — Quality Check (Sonnet reviews delegated output) │ ├── Step 5 — Typology recording (Sonnet logs each resolution to DR log) │ └── Step 6 — Re-export signal (Brian re-exports HTML when batch complete) Brian pulls the latest page state from the server:rsync -avz deploy@96.126.96.225:/var/www/NDIS-Wiki-HTML/navv-page-state.json \ /Users/brianc2/Dev/TheNest/Project/NAVV-NDIS-Handbook/NDIS-Wiki-HTML/navv-page-state.json Brian then issues a missive directive: "process pending disputes" or equivalent. This is the triage trigger. Sonnet does not initiate triage speculatively.Sonnet reads navv-page-state.json and performs a full batch analysis before any execution begins. No fixes are made at this stage.List all disputed pages. For each: article path, feedback type, impacted item, brief summary of the correction requested.Check the article graph for inter-article dependencies in the batch: Are any disputed articles linked to each other? (e.g., a dispute about conflict-of-interest.md alongside one about direct-vs-indirect-supports.md — both touch the hybrid model argument) If dependent articles are both disputed: they must be handled as a coordinated unit, not independently. Assess each dispute at two levels:Task complexity (per dispute):Batch complexity: If two or more disputes are dependent → batch complexity is elevated regardless of individual task complexity If a batch contains both Low and High tasks → sequence Low tasks after High (High tasks may change context for Low ones) If all disputes in the batch are Low → potential for local agent batch execution Group disputes by type. Disputes of the same type arising across multiple articles may share a root cause: Multiple "Out of Date" disputes → possibly a single legislation change not yet incorporated. Consider a targeted re-ingestion rather than individual article fixes. Multiple "Missing Connections" disputes in the same article class → structural gap in E-M5 reverse linkage. Note for the next normalisation pass. Multiple "Factual Error" disputes pointing at the same RS source → the source article may need enrichment. Log as a wiki quality issue. Sonnet produces a structured batch plan:For Validated Fix items: The batch plan includes the proposed text change, so Brian can approve in a single pass before any execution begins. Brian does not need to approve Quick Fix items — they proceed automatically.Execution follows the approved batch plan. Sonnet coordinates but does not write to wiki articles directly. "Add this WikiLink" → Local agent "Correct this factual claim (replacement text is already specified in Brian's approval)" → Local agent "Enrich this section using content from related RS articles" → Haiku sub-agent "Assess whether this claim is consistent across three related articles" → Sonnet sub-agent "Interpret this NDIS Act provision" → Sonnet sub-agent (or escalate to Brian if genuinely ambiguous) Execute in this order to avoid dependency violations: High-complexity tasks first (establish the correct framing before lower-level tasks run) Dependent task groups as coordinated units Independent Low-complexity tasks (can be batched to the local agent as a single instruction set) After each execution unit: Sonnet reviews the output before committing to the wiki article. This is the quality gate. If the output diverges from the approved plan, Sonnet either corrects inline or sends back to the agent with revised instructions.After each agent returns output, Sonnet: Reads the proposed change against the original dispute description Confirms the change addresses the stated concern without overreach Checks that no other article sections have been inadvertently modified If acceptable: write to the wiki markdown file If minor adjustment needed: correct inline If unacceptable: escalate to Brian with specific issue The quality check is the only step where Sonnet interacts with wiki files — and only to write approved content.Every resolved dispute generates a row in the Dispute Resolution Log. File: NDIS-Wiki/dispute-log.md (created when first dispute is resolved).Schema:Typology analysis (at each stock-take):Sonnet reviews the DR log for patterns: Which article classes generate the most disputes? → attention signal for quality improvement Which dispute types are most common? → informs where to strengthen the ingestion pipeline Are disputes clustering around specific RS sources? → signals a targeted re-ingestion Is the routing model calibrated? → if Local agent routes frequently need correction, elevate to Haiku The goal over time: a prescriptive routing policy. "Disputes of type X in article class Y at Low complexity are reliably handled by the local agent using template Z." Anticipatory planning reduces triage overhead as the typology matures.After all disputes in a batch are resolved, Sonnet signals: "Batch complete — re-export ready."Brian then: Re-exports NDIS-Wiki from Obsidian (Obsidian Webpage HTML Export) Runs pipeline: python3 3.Scripts/pipeline.py Uploads: rsync -avz --delete exported-html/ deploy@96.126.96.225:/var/www/NDIS-Wiki-HTML/exported-html/ Article: concepts/participant-statement.html Type: Factual Error Impacted item: Participant Ownership and the Translated VoiceDispute: The current article claims any NDIA rollover of goals without participant input breaches s33(2). The correction is more precise: the NDIA must address a submitted statement. If no statement is submitted, rollover is permissible.Batch analysis: One dispute in the current batch. No dependencies. Task complexity: Moderate (legal claim about NDIS Act interpretation; correction is clearly stated but touches a statutory provision). Routing: Haiku sub-agent. Resolution path: Validated Fix.Status: Awaiting Brian's missive directive to proceed.The skill script enforces this exact sequence on every run. No steps may be skipped or reordered.Phase 1 — Sync confirmation [ ] Confirm navv-page-state.json has been rsync'd (Brian confirms via missive) Phase 2 — Batch inventory and analysis [ ] List all disputed pages [ ] Assess task complexity per dispute [ ] Run dependency scan across batch [ ] Cluster by type and root cause [ ] Produce batch plan table [ ] Flag Validated Fix items for Brian approval Phase 3 — Brian approval gate (for Validated Fix items) [ ] Present proposed text to Brian [ ] Wait for explicit approval before proceeding [ ] Quick Fix items proceed without Brian approval Phase 4 — Execution (delegated, in dependency-ordered sequence) [ ] Route per plan: Local / Haiku / Sonnet sub-agent [ ] Quality check each output before writing to wiki [ ] Do not write to wiki until quality check passes Phase 5 — Typology recording [ ] Write DR log entry for each resolved dispute in dispute-log.md Phase 6 — Completion signal [ ] Report batch summary to Brian [ ] Flag re-export ready The skill file will be created at .claude/commands/process-dispute.md once Brian confirms this design is ready to formalise.Prepared by Sonnet — 2026-05-12 Revised after Brian's design feedback (same session)]]>navv-operational/dispute-triage-workflow-design.htmlNAVV-Operational/Dispute Triage Workflow Design.mdSun, 17 May 2026 01:33:50 GMTp3-minimum-viable-products — CaaG Tier A standard is the classification authority for what constitutes a Below-the-Waterline operational document
CITES: workflow-patterns — Agent routing and assembly patterns cited in classification rationale
CITES: p3-state-machine-insights — Referenced in classification of the P3 Portal Analysis document
DEPENDS-ON: p3-index — Registry of all Deep Ocean artefacts; used to verify P3 artefact targets for each Promote candidate
DEPENDS-ON: ndis-dispersed-boundary-waterline-amendment — Waterline model that defines the three-tier classification architecture underlying this audit
PART-OF: p3-index — This audit is a governance record within the NAVV-Wiki assembly; it supports the P3 programme through the wiki build it governs
REFINES: workflow-patterns — This audit refines the operational understanding of what constitutes actionable content for the Below-the-Waterline tier
SUPPORTS: product-brief-ndis-wiki — Audit classifies seven documents that support the NDIS Wiki product delivery
SUPPORTS: product-brief-participant-statement-toolkit — Audit classifies three documents that support the PST product
SUPPORTS: product-brief-psychosocial-recovery-plan — Referenced as a supported artefact in the Gap Analysis promote candidate
SUPPORTS: product-brief-visual-guide-ndis-plan — Referenced as a supported artefact in the Gap Analysis promote candidate
SUPPORTS: product-brief-visual-guide-service-agreement — Referenced as a supported artefact in the Gap Analysis promote candidate
SUPPORTS: strategy-dossier-ifc — Audit classifies two IFC programme documents (one promote, one retire)
SUPPORTS: workflow-patterns — Audit classifies three documents that support the workflow pattern artefact
SUPPORTS: p3-index — Audit governs promotion into the wiki that serves all P3 artefacts indexed here This document's conclusions are based on the state of referenced artefacts at the time of authorship. Subsequent changes to dependencies may affect applicability.]]>navv-operational/candidate-audit-2026-05-14.htmlNAVV-Operational/Candidate-Audit-2026-05-14.mdSun, 17 May 2026 01:33:50 GMTMissives/NAVV-2026-05-14 Date: 2026-05-14 Purpose: Assess the NDIS-Wiki-HTML agent assembly framework for replication into the NAVV-Wiki build. Identify what to keep, what to deprecate, and what to improve.The NDIS-Wiki-HTML assembly has now processed 58 task plans and 60 execution logs across 10 work packages. That is a substantial test run. The experiment has proven that the WP → Task Plan → Execute → Log discipline works. The framework is no longer speculative — it is an established operating model with a track record.The NDIS-Wiki-HTML build provided the original test bed for the three-skill assembly pattern. After 10 work packages and 58 task plans, the pattern has demonstrated clear value: it prevents agent improvisation on undefined constraints, creates verifiable task completion criteria, and maintains an immutable execution record. The NAVV-Wiki project now faces the question of whether this framework transfers to a different problem domain — one focused on markdown-based content management and registry bootstrap rather than HTML pipeline operations.The NAVV-Wiki build matches the conditions that make the assembly pattern valuable: multi-stage, multi-task work; clear guard rails needed; mix of agent tiers; verifiable task completion; and Brian's retention of WP-level control. However, the two builds are structurally different enough that certain elements of the framework (HTML-specific reconnaissance, folder structure) will not transfer directly. Others (the three-skill pattern, task plan structure, logging discipline) are domain-agnostic and transfer cleanly.The assessment identifies both what transfers unchanged and what requires adaptation. It also surfaces improvements that would strengthen the framework before it becomes a general-purpose tool: explicit agent routing rules, clearer escalation procedures, explicit guard rail inheritance, and an assembly-level status dashboard.
SUPPORTS: workflow-patterns — Validated the WP → Task Plan → Execute → Log assembly discipline through analysis of the NDIS-Wiki-HTML build; operational findings directly shaped the workflow patterns adopted for NAVV-Wiki
SUPPORTS: product-brief-ndis-wiki — Assessed which NDIS-Wiki-HTML components were suitable for NAVV-Wiki replication, providing architectural rationale for the NDIS Wiki product's technical delivery approach This assessment is based on the NDIS-Wiki-HTML build's experience through 10 work packages. The proposed improvements (sections 4.1–4.6) remain untested — they represent recommendations derived from operational lessons, not validated patterns.The assessment assumes the framework's core principles (WP → Task Plan → Execute → Log discipline, immutable logging, guard rail inheritance) will transfer unchanged to NAVV-Wiki. However, domain-specific elements (HTML reconnaissance, component library checks) do not apply. Gaps in the framework will surface during NAVV-Wiki execution and should be fed back into the assembly design.The NDIS-Wiki-HTML assembly retains six pending tasks from WP-009 and WP-010 (TP-0049, TP-0050, TP-0053–TP-0058) that have not been executed. The applicability of those tasks post-project-pause has not been evaluated. This does not block NAVV-Wiki but represents unfinished business in the source assembly.Verdict: Yes. The NAVV-Wiki build is an excellent candidate for this framework.The NDIS-Wiki-HTML assembly has now processed 58 task plans and 60 execution logs across 10 work packages. That is a substantial test run. The experiment has proven that the WP → Task Plan → Execute → Log discipline works. The framework is no longer speculative — it is an established operating model with a track record.The NAVV-Wiki build matches the conditions that make the framework valuable:Deploying the framework here also serves Brian's broader goal: hardening the assembly pattern by applying it to a different problem domain before it becomes a general-purpose tool. The NAVV-Wiki build is a good proving ground because it is structurally different from the HTML pipeline — it involves markdown management, registry bootstrap, and content production rather than HTML processing. Gaps in the framework will surface./plan-wp → /plan-task → /execute-task is the right sequence. The discipline works: WP sets scope and guard rails (Brian owns this level) Task Plan creates an unambiguous runsheet before any execution Execute-task follows the runsheet exactly, logs the result This prevents the most common agent failure mode: improvising when the plan is ambiguous. Keep all three skills.The five-folder pattern (0.Skills/, 1.WorkPackages/, 2.Tasks/, 5.Logs/ + content output folders) is the right model. Keep all of these inside NAVV-Wiki/. The numbered prefixes ensure Obsidian displays them in the correct sequence order — this is intentional and should be retained.The NDIS-Wiki-HTML/CLAUDE.md is the governing document for builder agents rooted in that assembly. It defines: role, principles, inputs/outputs, and the mandatory four-step workflow. This pattern transfers directly. The NAVV-Wiki will need its own NAVV-Wiki/CLAUDE.md with the same structure but adapted content.The WP format — brief context paragraph + Scope + Guard Rails + Planned Tasks table — is clean and effective. Keep it. The guard rails section is particularly valuable: it is the mechanism that prevents agent improvisation on non-negotiable constraints. Brian's decisions become permanent constraints, not recommendations.The six-section task plan structure (Context, Inputs, Outputs, Transformation, Definition of Done, Procedural Test) is thorough. Keep all six sections. The Procedural Test section is the quality gate — a task with no verifiable test is a task with no quality assurance.Task logs (TL-xxxx) are written once and not edited — they are the immutable execution record. This mirrors the Missive/freeze-line convention in the control layer. Keep this. It is what makes the assembly auditable.The following are NDIS-Wiki-HTML-specific and do not carry forward to a markdown wiki build:For NAVV-Wiki, the equivalent content outputs are markdown files in NAVV-Operational/, NAVV-Commercial/, and the registry. The script and output folders carry forward conceptually:The current plan-wp skill's Phase 2 (Reconnaissance) surveys HTML structure, component library, and injection points. This is entirely HTML-pipeline-specific.For NAVV-Wiki, the reconnaissance phase should instead: Audit existing content (what's in P3-Governance/, what's in Droppings/) Check the registry (what entities are already registered) Review NAVV-Wiki/CLAUDE.md standards (what Tier A requirements apply) Check 0.Skills/ for reusable patterns before building new ones The principle is the same — read-only survey before planning — but the implementation differs.NDIS-Wiki-HTML has inconsistent WP naming: WP-001 - Discovery Planning.md through WP-008 - Documentation review.md but WP-009.md (no title). Before replication, adopt one convention and stick to it:Recommended: WP-NNN - Title.md — always include a descriptive title. The title makes the WP list scannable in Obsidian without opening files.The current framework does not specify which agent tier executes which task type. This is implicit — experienced users know, but agents don't. For NAVV-Wiki, add an explicit routing table to the assembly CLAUDE.md:The execute-task skill currently says "do NOT mark the task complete if verification fails" — but it doesn't define what happens next. In NDIS-Wiki-HTML, this has been implicit (agents stop and report). For NAVV-Wiki, make it explicit in the skill:If verification fails: Write the log with FAIL status and describe what failed Add a #action/brian checkbox in the log with the specific issue Do not attempt to improvise a fix Stop and surface to Brian via the next Missive cycle WP guard rails currently live in the WP document but are not explicitly referenced in each Task Plan. An agent executing TP-0055 (for example) should inherit WP-010's guard rails, but the TP doesn't link to them. For NAVV-Wiki, add a mandatory field to the Task Plan template:## Guard Rails Inherited **Work Package:** [[1.WorkPackages/WP-NNN - Title]] **Applicable constraints:** [key guard rails from the WP, summarised here] This ensures agents executing a task always have the WP guard rails in scope, not just the task instructions.For multi-WP assemblies, the WP Planned Tasks tables are the only status view. For Brian to get an at-a-glance view across all work packages, add a simple STATUS.md at the NAVV-Wiki root: | WP | Title | Tasks | Status | |---|---|---|---| | WP-001 | Foundation | 6 tasks | Pending | | WP-002 | Registry Bootstrap | 4 tasks | Pending | ... This mirrors what the NDIS-Wiki-HTML status page does for per-article state — but at the work package level, not the article level.The current plan-task skill says "Atomic tasks only — if a task cannot be verified by a single script, it is too large." This is good in principle but vague in practice. Add a size heuristic to the skill:Task size guidance: A task should be completable in under 30 minutes of execution time, produce at most 3 output files, and have exactly one verification command. Anything larger should be split.NAVV-Wiki/ ├── P3-Governance/ Deep Ocean content (moved from project root) ├── NAVV-Operational/ Below-the-Waterline (flat, Tier A standard) ├── NAVV-Commercial/ Above-the-Waterline (placeholder) ├── 0.Skills/ plan-wp.md, plan-task.md, execute-task.md (adapted) ├── 1.WorkPackages/ WP-NNN - Title.md files ├── 2.Tasks/ TP-xxxx.md files ├── 3.Scripts/ Registry, linter, utility scripts ├── 4.Output/ Script outputs (JSON, audit reports) ├── 5.Logs/ TL-xxxx.md execution logs ├── navv-registry.json Entity registry ├── CLAUDE.md Wiki agent constitution └── STATUS.md Assembly-wide status index Note: 6.Components/ is not included — there are no HTML/CSS/JS components in a markdown wiki build. If visual components are needed later (for the web-facing portal), a separate 6.Components/ can be introduced.These map to the Stage A–D staging plan from the v3 taxonomy document:WP-001 through WP-003 are sequential (each is a prerequisite for the next). WP-004 can begin after WP-003 is complete. WP-005 can begin after WP-002 is complete (linter needs registry to validate slugs).The NDIS-Wiki-HTML assembly currently has six pending tasks from WP-009 (TP-0049, TP-0050) and WP-010 (TP-0053 through TP-0058) that have not yet been executed. Before deploying builder agents on NAVV-Wiki, it is worth confirming the NDIS-Wiki-HTML assembly state: are those pending tasks still relevant, or have they been superseded by subsequent events?This is not a blocker for the NAVV-Wiki deployment — the two assemblies are independent — but it is good housekeeping.Prepared by Sonnet — 2026-05-14
Commissioned via Missives/NAVV-2026-05-14]]>navv-operational/agent-assembly-framework-ndis-wiki-html-review-and-replication-assessment.htmlNAVV-Operational/Agent Assembly Framework - NDIS-Wiki-HTML Review and Replication Assessment.mdSun, 17 May 2026 01:16:58 GMT2.2 - REF Requirements v1.0 + 2.3 - REF Specification v1.0 Sentinel authority: Andrew (Product pillar)
Status: Active — replaced provisional stub 2026-05-09. See Product Brief - Participant Statement Toolkit - Stage 3 Extract for working paper.
Reference: P3 Minimum Viable Products Product type: Instrument (primary) — transfers operational capacity to practitioners. Theory (secondary) — embedded orientation content builds coordinator understanding of the NDIS planning process and PACE framework. Blue Ocean / Red Ocean: Blue Ocean. No equivalent structured tool exists for PACE-framework Participant Statements at this level of specificity. Nearest alternatives are generic NDIS goal templates that do not address PACE architecture, budget recommendation structure, or legislative traceability to s33(2) and s34(1)(a). Primary beneficiary: Support Coordinators (SCs) and Psychosocial Recovery Coaches (PRCs) preparing formal Participant Statements for NDIA planning meetings.Before the toolkit: coordinators must translate complex, personal participant stories into technically precise NDIA language — navigating PACE support categories, outcome domain mapping, funding architecture rules, and legislative requirements (s33(2), s34(1)(a)) — without structural guidance. The result is inconsistent, incomplete statements that expose participants to inadequate planning outcomes.After the toolkit: coordinators work through a single guided document that systematically captures participant context, goals, and budget architecture, pre-mapped to NDIA data requirements. The resulting statement is structured to make funding approval administratively straightforward and rejection procedurally costly for the NDIA — making it difficult to roll over old goals or simplify the plan without triggering a reviewable error under s100.Ultimate beneficiary: NDIS participants, whose authentic goals are captured in their own words while being mapped to the legislative and technical structures that protect their funding.Classification: Instrument (primary), Theory (secondary).What transfers to the coordinator — three distinct capabilities: Goal translation: The ability to convert plain-English participant goals into the "NDIS Trinity" — Goal → Support Category (1–21) → Outcome Domain (1–8) — in a form that NDIA planners can act on directly without interpretation. PACE Budget Architecture: The operational capacity to recommend funding period structure, Flexible/Stated designations, Digital Lock requests, and risk rationale — components of budget design that most coordinators lack a structured framework for and currently produce ad hoc or omit entirely. Legislative anchoring: A document explicitly traceable to s33(2) (the participant's right to submit a goals statement) and structured to invoke s34(1)(a) necessity requirements — creating a legally grounded record that constrains NDIA decision-making in the participant's favour. Secondary Theory component: the embedded orientation section transfers understanding of the submission-response chain (Part A → NDIA → Statement of Participant Supports) and provides working reference material (item code anatomy, 8 Outcome Domains, 21 Support Categories) — excluded from printed output.Form of transfer: A single self-contained browser-based HTML file. No installation, no external dependencies, no data transmission.If a Support Coordinator or PRC uses the toolkit to prepare a Participant Statement before a planning meeting, the resulting document will: Be more structurally complete and legislatively grounded than statements prepared without the toolkit Map participant goals to PACE support categories and outcome domains in a form NDIA planners can act on directly Reduce the risk of an inadequate or under-funded plan by making it administratively difficult for the NDIA to reject, simplify, or roll over the statement without triggering a reviewable error What will confirm this: Coordinator self-report on preparation quality; comparison of NDIA responses (Statement of Participant Supports) for toolkit-prepared statements vs. prior practice.Current probe: v7 HTML prototype — a fully self-contained browser file implementing 22 of 23 requirements (R-001 through R-022 active; R-023 pending).What this probe tests: Whether the structured guided form is sufficient for coordinators to produce compliant, complete statements without additional training — and whether the PACE budget architecture section (Block 3, Alignment Matrix) is understood and usable by coordinators in practice.Intentional scope constraint: PACE framework only — no Legacy plan mode (G-01). This is a deliberate probe boundary.Primary probe limitation: No save function (R-023 Pending) — data is lost if the browser is closed. Constrains the probe to single-session preparation only. Must be resolved before general deployment.The probe is complete when ALL of the following are observable: A Support Coordinator completes the toolkit in a single session and produces a printable, complete statement (R-021) The statement is formally submitted to the NDIA as a Part A Participant Statement under the declaration (R-018, R-019) At minimum one NDIA response (Statement of Participant Supports) is received for a toolkit-prepared statement The coordinator reports the Budget Architecture section (Block 3, Alignment Matrix) reduced the time and effort required to prepare funding recommendations No critical structural issue prevents completion (no blocker-severity defect in the 22 active requirements) Done vs. Valid: Done means the test ran. Valid requires the NDIA response to confirm the statement was accepted and acted on — not merely acknowledged.
Known validity risk — G-03: Domain knowledge underpinning the toolkit was derived from AI-generated analysis and has not been independently validated against the exact text of the NDIS Act or published NDIA operational guidelines. Managed risk — see Critical Commitments Register GC-004.Brief validated: 2026-05-09. Replaces provisional stub created 2026-05-08.]]>p3-governance/products/participant-statement-toolkit/product-brief-participant-statement-toolkit.htmlP3-Governance/Products/Participant-Statement-Toolkit/Product Brief - Participant Statement Toolkit.mdThu, 14 May 2026 04:22:08 GMTP3 Minimum Viable Products filter Programme binding key: SD-IFC-2026-001 IFC Component: #5 Sentinel authority: Andrew (Product pillar) Date: 2026-05-10
Score: 14/14 — Ingest (via P3 Product Brief Scoring Rubric) Status: Active
Reference: P3 Minimum Viable Products, Strategy Dossier - IFC Product type: Instrument — transfers operational capability and compliance safety to dual-role SC/PRC practitioners and their participants. Blue Ocean / Red Ocean: Blue Ocean. No existing NDIS recovery plan template combines CHIME-D framework mapping, a Barrier-to-Implementation Matrix, SC/PRC pivot logic, and the structural compliance elements required to defend dual-role billing in audit. Primary beneficiaries: Dual-role NDIS practitioners (SC/PRC) and participants whose mental health struggles — whether primary or secondary — create functional barriers to achieving NDIS plan goals.Before the plan: participants experienced plan waste because rigid support models failed to respond to episodic mental health fluctuations. Practitioners faced severe audit risk from accusations of duplicating services — billing both SC (Outcome 8) and PRC (Outcome 6) without a documented, participant-endorsed rationale for each.After the plan: participants can exercise choice and control to dynamically pivot between direct coaching and indirect coordination as their capacity fluctuates. Practitioners are fully shielded by a compliant, transparent audit trail that demonstrates genuine non-duplication — each activity traceable to a specific NDIS outcome and a specific participant-identified barrier.Classification: Instrument.What transfers to the practitioner — three distinct capabilities: Structured goal-to-barrier mapping: The Barrier-to-Implementation Matrix links each of the participant's NDIS goals to the specific mental health barriers preventing their achievement, and connects those barriers to the legislative criteria under Section 34 (Reasonable and Necessary). This translates lived experience into fundable justification. CHIME-D to NDIS Outcomes crosswalk: Organises the recovery plan around the CHIME-D domains (Connectedness, Hope, Identity, Meaning, Empowerment, Distress) with explicit mapping to NDIS Outcome 6 (PRC — direct coaching) and Outcome 8 (SC — indirect coordination). Makes the clinical framework visible to NDIA planners in terms they can fund. Compliance architecture: The plan embeds the four NDIA-mandated lifecycle stages (Design, Plan, Implement, Review), a Dual-Role Narrative Statement (participant-endorsed), and a Structural Pivot Checkpoint at the end of each goal — proving the capacity-building trajectory and preventing practice drift. If we structure the Psychosocial Recovery Plan around a Barrier-to-Implementation Matrix that maps the participant's mental health barriers to NDIS plan waste and Section 34 Reasonable and Necessary criteria, then NDIA planners will approve dual-role funding, and auditors will recognise a clear differentiation between Outcome 6 (PRC) and Outcome 8 (SC) activities without flagging duplication.What will confirm this: At least one dual-role practitioner completes the plan with a participant, the plan is accepted by the NDIA (or withstands audit scrutiny), and no duplication claim is upheld against dual Outcome 6/Outcome 8 billing.Minimum viable version: A structured recovery plan template embedding five structural elements: Barrier-to-Implementation Matrix: Links participant's psychosocial barriers to specific legislative risk (e.g., s34(1)(c) Value for Money / Plan Waste) and offers the participant the choice between SC or PRC support at each identified barrier. Four mandated stages: The plan visibly moves through the NDIA-mandated lifecycle: Design, Plan, Implement, and Review — each stage explicitly labelled and documented. CHIME-D to NDIS Outcomes crosswalk: Recovery domains (Connectedness, Hope, Identity, Meaning, Empowerment, Distress) mapped to NDIS Outcome 6 and Outcome 8 activities — the clinical-to-legislative bridge. Dual-Role Narrative Statement: A participant-facing preamble explaining the hybrid SC/PRC approach in plain English — ensuring transparency and upholding the participant's right to choice and control before the plan is signed. Structural Pivot Checkpoint: Embedded at the end of each goal — "Has sufficient capacity been built to transition this support to a core worker?" — proving the capacity-building trajectory and preventing practice drift toward indefinite support dependency. The probe is complete when ALL of the following are observable: A dual-role practitioner completes the plan with a participant, clearly separating direct coaching interventions (Outcome 6) from indirect logistical support (Outcome 8) Both the practitioner and the participant sign off that the document reflects a clear, non-duplicated path to the participant's NDIS goals The plan is submitted to the NDIA or used in at least one support delivery interaction without triggering a duplication query The Structural Pivot Checkpoints are actively used — at least one goal has been reviewed against the "transition to core worker" criterion Brief produced: 2026-05-10 via NbLM extraction pass on IFC notebook (07344d6e-933e-43f0-81e2-8576ff93e178). NbLM source confidence: All six fields well-supported — "robust and complete information", no fields flagged as insufficient. Score: 14/14. Ingested directly.]]>p3-governance/products/psychosocial-recovery-plan/product-brief-psychosocial-recovery-plan.htmlP3-Governance/Products/Psychosocial-Recovery-Plan/Product Brief - Psychosocial Recovery Plan.mdThu, 14 May 2026 04:22:08 GMTP3 Minimum Viable Products filter Programme binding key: SD-IFC-2026-001 IFC Component: #1 (absorbs former Component #3 — Choice and Control Flexibility Educator, merged 2026-05-11) Sentinel authority: Andrew (Product pillar) Date: 2026-05-10 | Last updated: 2026-05-11
Score: 14/14 — Ingest (via P3 Product Brief Scoring Rubric) Status: Active
Reference: P3 Minimum Viable Products, Strategy Dossier - IFC Structural note (2026-05-11): Component #3 (Choice and Control Flexibility Educator) has been merged into this brief as Loop 4. The former standalone extract remains in Droppings/ as immutable history. All P3 references to Component #3 now point to this document. Product type: Theory (primary) + Instrument — transfers foundational understanding of NDIS mechanics AND the decision-making capacity to actively direct Category 07 funding. Blue Ocean / Red Ocean: Blue Ocean. No existing intake tool explains R106 Category 7 flexibility (SC/PRC dual-role), Digital Locks, and the participant's right to self-direct at this level of accessibility and specificity. Primary beneficiary: NDIS participants entering the agency who have flexible Support Category 07 funding but lack the technical knowledge to deploy it effectively.Before the guide: participants were passively assigned a "Coordinator" and remained disempowered, often having funds consumed by indirect system navigation when they needed direct face-to-face coaching. The R106 flexibility that entitled them to choose was invisible to them.After the guide: participants understand their legal rights and the architectural reality of their NDIS plan — what their budget is, what "locks" on it mean, and that Category 07 gives them the power to dial support up or down between indirect coordination (Outcome 8) and direct recovery coaching (Outcome 6) based on their actual episodic needs.Ultimate beneficiary: NDIS participants — whose informed engagement with their own plan prevents budget waste and produces funding decisions that reflect their real situation.Classification: Theory (primary) — paradigm transfer. Instrument (secondary) — decision-support tool at intake.What transfers to the participant — two distinct capabilities: Foundational understanding: The participant receives the conceptual framework for their NDIS plan — what goals unlock which "bank accounts" (Support Categories), what "digital locks" (Stated item codes) mean and when planners apply them, what "mainstream" versus "NDIS-funded" supports means, and what "Everyday Living Expenses" are excluded. The R106 Master Key: The participant understands that if Category 07 is unlocked, they hold the power to choose between indirect system navigation (Support Coordination, Outcome 8) and direct trauma-informed relational coaching (Psychosocial Recovery Coaching, Outcome 6) — and to blend these in any proportion their plan allows. Form of transfer: A highly accessible visual intake tool using a "Fibonacci Shell" pedagogical structure (Loops 0 to 4) — an expanding narrative of infographics styled like a clinical reference booklet. No jargon; accessible metaphors (Bank Accounts, Safes, Keys) throughout.If we replace the standard administrative intake process with an educational visual guide that explicitly explains the boundaries of NDIS funding, Digital Locks, and R106 Category 7 flexibility, then participants will exercise genuine informed consent and self-direct a hybrid support model that accurately reflects their real-world episodic barriers — preventing plan waste and producing funding decisions they genuinely endorse.What will confirm this: Participants, after using the guide, can articulate the difference between an indirect coordination task and a direct coaching task in their own words, before signing the Service Agreement.Minimum viable version: A visual intake tool covering four structural elements, deployed during the initial "meet and greet": The Origin Ecosystem (Loop 1): What the NDIS funds versus what Mainstream, Informal, and Everyday Living Expenses covers — the boundary of the system. The Funding Pool and Locks (Loops 2–3): How participant goals unlock specific Support Categories ("bank accounts"); the difference between flexible and Stated (locked) accounts; how planners use "digital safes" (Stated item codes) for high-cost items like Level 3 Specialist Coordination. The R106 Master Key and the Hybrid Choice (Loop 4 — absorbs Component #3): The culminating section of the guide. Covers four elements in sequence: The Funding Pool: Category 07 is a flexible budget — the participant directs it (unless digitally locked by a Stated item code) The Indirect Option (SC, Outcome 8): "Behind the scenes" — system navigation, provider connection, plan mechanics; the coordinator works on the participant's behalf The Direct Option (PRC, Outcome 6): "Side by side" — relational, face-to-face, trauma-informed coaching; the coach works directly with the participant on psychological readiness and capacity-building The Hybrid Choice: R106 is the participant's legal entitlement to blend these two supports in any proportion their plan allows — and to adjust that blend as their episodic needs fluctuate After Loop 4 the participant is ready to sign the Service Agreement with full informed consent — knowing what they are choosing and why. Intentional scope constraint: Category 07 only. Generic NDIS plan mechanics (all 21 support categories) are out of scope for this probe.The probe is complete when ALL of the following are observable: A participant completes the visual guide intake session The participant can articulate — in their own words — the difference between an indirect coordination task (Outcome 8) and a direct coaching task (Outcome 6) The participant makes a self-directed allocation choice (Coordination Only / Coaching Only / Blended) and signs the Service Agreement with that choice documented No critical structural issue prevents comprehension (no blocker-severity accessibility defect) Done vs. Valid: Done means the guided session completed. Valid requires evidence that the participant's self-directed allocation decision was maintained through the first support delivery — not merely made at intake.Brief produced: 2026-05-10 via NbLM extraction pass on IFC notebook (07344d6e-933e-43f0-81e2-8576ff93e178). NbLM source confidence: All six fields well-supported — no fields flagged as insufficient. Score: 14/14. Ingested directly.]]>p3-governance/products/visual-guide-ndis-plan/product-brief-visual-guide-to-the-ndis-plan.htmlP3-Governance/Products/Visual-Guide-NDIS-Plan/Product Brief - Visual Guide to the NDIS Plan.mdThu, 14 May 2026 04:22:08 GMTP3 Minimum Viable Products filter Programme binding key: SD-IFC-2026-001 IFC Component: #2 Sentinel authority: Andrew (Product pillar) Date: 2026-05-10
Score: 12/14 — Ingest with gap noted (via P3 Product Brief Scoring Rubric) Status: Active — visual design approach gap logged (G-01)
Reference: P3 Minimum Viable Products, Strategy Dossier - IFC Product type: Instrument (primary) — provides the documentary mechanism for informed financial consent. Theory (secondary) — transfers understanding of billing types, budget monitoring triggers, and the practitioner's conflict of interest disclosures. Blue Ocean / Red Ocean: Blue Ocean. No existing NDIS service agreement translates contractual obligations into a visual, accessible format that explicitly separates NF2F/F2F costs, documents the SC/PRC blend, and includes budget monitoring triggers and an Impartiality Shield. Primary beneficiaries: NDIS participants — especially those with psychosocial vulnerabilities, trauma histories, cognitive overload, or intellectual disabilities — and dual-role SC/PRC practitioners.Before the guide: participants were passive signatories to complex service agreements they did not understand, exposing them to hidden Non-Face-to-Face (NF2F) charges, rapid budget depletion, and rigid support models. Practitioners had no structured mechanism to document informed consent for dual-role billing, creating audit risk.After the guide: participants achieve "financial sovereignty" — they understand their rights, comprehend the billing implications of each support type, and sign a service agreement that reflects their genuine, self-directed allocation. Practitioners hold a signed document that constitutes an audit shield against claims of over-servicing, double-dipping, or Code of Conduct violations.Classification: Instrument (primary), Theory (secondary).What transfers to the participant: Legal and financial comprehension: The ability to understand — before signing — the difference between Non-Face-to-Face (NF2F) coordination work, Face-to-Face (F2F) coaching, and Provider Travel costs, and to authorise each explicitly. Choice documentation: The ability to exercise genuine informed financial consent by selecting one of three defined models (Coordination Only, Coaching Only, or Blended) and having that choice recorded in a legally binding document. Transparency assurance: Knowledge of what the practitioner explicitly does NOT provide (the Impartiality Shield) — creating the conditions for genuinely independent advice. Form of transfer: A highly accessible, visual document used at the initial intake or "meet and greet" — translating legal clauses into plain English with visual separation of billing types, monitoring triggers, and choice options.If we translate the service agreement into an accessible visual format that explicitly separates NF2F and F2F costs, maps Category 07 budget to both SC (Outcome 8) and PRC (Outcome 6), and includes conflict of interest disclosures, then participants will exercise genuine informed financial consent — and the signed agreement will constitute an audit-proof record of the participant's self-directed allocation choice.What will confirm this: The participant can articulate their billing authorisation (NF2F / F2F / Travel) and their support allocation (Coordination / Coaching / Blended) in their own words before signing. The signed agreement is accepted by the NDIA and not challenged in audit.Minimum viable version: A visual document covering the following five structural elements, used at intake: Three choices: Coordination Only (SC, Outcome 8) / Coaching Only (PRC, Outcome 6) / The Blended Option — participant selects and signs. Billing type breakdown: Explicit separation of Non-Face-to-Face (NF2F), Face-to-Face (F2F), and Provider Travel costs — what each is, when it applies, what the NDIS price limits are. Budget monitoring triggers: The 50% and 80% utilisation points — what happens at each threshold, who initiates a review, and what the participant's options are. The Impartiality Shield: A visual declaration of what the practitioner does NOT provide (Core Supports, Plan Management, SIL, Clinical Therapy) — preserving independence. Flexibility Clause: Statement of the Least-Cost-Appropriate-Provider decision rule — commitment to step down to lower-cost supports when capacity is built. Known gap — visual design approach: The exact visual format, metaphor system, and slide layouts for this product have not yet been specified in Andrew's notebook. Component #1 has a detailed Fibonacci Shell structure; Component #2's visual approach is yet to be defined. This is noted as G-01 and does not block the probe.The probe is complete when ALL of the following are observable: A participant completes the visual intake session for the Service Agreement The participant can articulate in their own words what NF2F means and why they are authorising it The participant selects one of the three support models and signs the Service Agreement with that selection recorded The signed agreement is used in at least one NDIA interaction without triggering a compliance query related to NF2F billing or dual-role duplication Brief produced: 2026-05-10 via NbLM extraction pass on IFC notebook (07344d6e-933e-43f0-81e2-8576ff93e178). NbLM source confidence: Five of six fields well-supported. G-01 flagged by NbLM — visual design approach insufficient. Score: 12/14. Ingested with gap noted.]]>p3-governance/products/visual-guide-service-agreement/product-brief-visual-guide-to-the-service-agreement.htmlP3-Governance/Products/Visual-Guide-Service-Agreement/Product Brief - Visual Guide to the Service Agreement.mdThu, 14 May 2026 04:22:08 GMTp3-governance/p3-reference/l1-bootstrapping/p3-programme-guidance.htmlP3-Governance/P3-Reference/L1-Bootstrapping/P3 Programme Guidance.mdThu, 14 May 2026 04:22:08 GMTp3-governance/p3-reference/l1-bootstrapping/p3-risk-management-guidance.htmlP3-Governance/P3-Reference/L1-Bootstrapping/P3 Risk Management Guidance.mdThu, 14 May 2026 04:22:08 GMTp3-governance/p3-reference/l1-bootstrapping/p3-state-machine-insights.htmlP3-Governance/P3-Reference/L1-Bootstrapping/P3 State Machine Insights.mdThu, 14 May 2026 04:22:08 GMTp3-governance/p3-reference/l1-bootstrapping/p3-minimum-viable-governance.htmlP3-Governance/P3-Reference/L1-Bootstrapping/P3 Minimum Viable Governance.mdThu, 14 May 2026 04:22:08 GMTp3-governance/p3-reference/l1-bootstrapping/p3-minimum-viable-patterns.htmlP3-Governance/P3-Reference/L1-Bootstrapping/P3 Minimum Viable Patterns.mdThu, 14 May 2026 04:22:08 GMTp3-governance/p3-reference/l1-bootstrapping/p3-minimum-viable-principles.htmlP3-Governance/P3-Reference/L1-Bootstrapping/P3 Minimum Viable Principles.mdThu, 14 May 2026 04:22:08 GMTp3-governance/p3-reference/l1-bootstrapping/p3-minimum-viable-products.htmlP3-Governance/P3-Reference/L1-Bootstrapping/P3 Minimum Viable Products.mdThu, 14 May 2026 04:22:08 GMTp3-governance/p3-reference/l1-bootstrapping/p3-minimum-viable-strategy.htmlP3-Governance/P3-Reference/L1-Bootstrapping/P3 Minimum Viable Strategy.mdThu, 14 May 2026 04:22:08 GMTP3 Filter Guide - Minimum Viable PrinciplesPatterns are the knowledge architecture — reusable, named responses to recurring classes of problem, encoding both the form of the solution and the reasoning behind it. Patterns translate Principle-level constraints into specific, repeatable capabilities. Critically, every pattern has an Expression Gradient (how the pattern manifests as the organisation's capability develops from Level 1 to Level 5) and a Plasticity Status (Proto, Emerging, or Canonical) that signals how much governance authority the pattern carries.
See: P3 Filter Guide - Minimum Viable PatternsProducts are the vehicles for value transfer — not artefacts, but the mechanisms through which specific capabilities move from the organisation to specific beneficiaries. Every product is a hypothesis made testable: shipping is the moment the claim becomes verifiable, not the moment it is concluded. Products come in three types — Theory (knowledge transfer), Instrument (capability transfer), and Service (outcome transfer) — each with its own success criteria and failure modes.
See: P3 Filter Guide - Minimum Viable ProductsThe SGM defines what is required of the organisation given its current environment, ambitions, and capacity. It operates in a cycle — market signals inform strategic adjustment, which feeds forward into governance and maturity investment, which shapes the next cycle.Strategy is the directional force — the intentional slope that determines where the organisation is pointed and at what pace it is moving. Strategy is not a plan or a destination: it is a direction of travel calibrated to what the organisation can sustainably do. Strategy activates Principles (choosing which governing constraints to foreground in this epoch), calibrates Products (deciding which value transfers to pursue), and must be checked against the Maturity terrain before any commitment is made.
See: P3 Filter Guide - Minimum Viable StrategyGovernance is the integrity function — the mechanism that ensures the organisation does what it claims to do. Its central distinction is between Done (stakeholder acceptance of the work) and Valid (structural integrity of the work against the commitments that shaped it). At minimum viable maturity, governance requires three things for each critical commitment: a named commitment, a named sentinel with authority to act, and a friction point where work pauses for a check before proceeding.
See: P3 Filter Guide - Minimum Viable GovernanceMaturity is the capability terrain — the honest, multi-dimensional inventory of what the organisation can reliably sustain right now. Maturity is not a single number; it is a surface with peaks and valleys across different practice domains. The Ratchet mechanism (Documentation → Tooling → Governance → Culture) converts capability gains into permanent features. The Strategy Sieve (Now / Grow / Recalibrate) uses the maturity terrain to calibrate strategic ambition to what the organisation can actually execute.
See: P3 Filter Guide - Minimum Viable MaturityThe six pillars are not independent silos. They are orthogonal forces that constrain, enable, and check one another. Understanding the key relationships is what converts six separate filter guides into a unified framework.The framework's most important interactions occur at three defined intersections — points where one P3 pillar meets one SGM pillar in productive tension. Each intersection produces a synthesis that neither pillar could reach alone.The Legislative Nexus — Principles ↔ StrategyPrinciples define the boundary of what is permissible. Strategy decides which permissible directions to actually pursue. The tension is between stability (the Principle's demand for consistent constraint) and velocity (Strategy's demand for decisive movement). The synthesis is risk-adjusted compliance: Strategy does not override Principles — it weights and activates them, foregrounding those most relevant to the current strategic epoch without violating any. An organisation without this distinction is either paralysed (too many Principles with no strategic direction) or reckless (strategic velocity without principled constraint).In practice: Always extract your Principles before formulating your Strategy. The Strategy brief's "Principle Activation" field (item 5 in the six-part template) is where this nexus is made explicit.The Architectural Nexus — Patterns ↔ MaturityPatterns describe ideal form — what good looks like in a given class of problem. Maturity describes current reality — what the organisation can actually sustain. The tension is between aspiration (the Pattern's ideal) and physics (the Maturity frontier). The synthesis is appropriate engineering: deploying the pattern expression that offers maximum fitness for the current capability level — neither over-engineering for a low-maturity organisation nor under-engineering for a high-maturity one.In practice: The Expression Gradient in each pattern must be read against the Maturity profile. A Canonical pattern designed for Level 3 capability cannot be safely deployed by an organisation at Level 1, regardless of its authority. The Maturity terrain sets the ceiling for safe pattern selection.The Value Nexus — Products ↔ GovernanceProducts define what is desired — the value transfer the beneficiary needs. Governance defines what is verifiable — whether that value transfer is structurally sound. The tension is between outcome (the Product's demand to ship) and integrity (Governance's demand to validate). The synthesis is Done vs. Valid: a product must satisfy both stakeholder-facing Done criteria and system-facing Valid criteria. Governance is not the enemy of product delivery — it is the mechanism that ensures delivery is what it claims to be.In practice: The Product brief's "Validity Marker" field (item 6 in the six-part template) is where this nexus is operationalised. Can the product's key design choices be traced to a governing commitment? If not, the product is Done but not yet Valid.Beyond the three nexus points, the framework operates through two circulation flows that keep the pillars connected over time.The Downstream Current flows from Principle → Pattern → Product: the construction flow, driven by constraint. Principles bound the space of valid patterns. Patterns shape the structure of valid products. When this current is healthy, every product is traceable back to the commitments that governed its design. When it breaks, products drift away from governing commitments invisibly — the organisation builds things that satisfy no principle anyone can remember articulating.The Upstream Current flows from Product feedback → Strategy → Principle: the correction flow, driven by learning. Market signals from delivered products inform strategic adjustment. Strategic adjustment, over time, may prompt revision of Institutional Principles. When this current is healthy, the organisation learns from what it ships. When it breaks, the organisation ships and discards what the shipping reveals — every deployment is an experiment that produces no learning. Maturity calibrates Strategy: a strategy that requires capabilities the organisation does not have is aspiration, not strategy. Always assess maturity before committing to a strategic direction; the Strategy Sieve makes this assessment explicit. Governance protects all five: without governance, Principles become aspirations, Patterns drift toward Theatre, Products ship without validity checks, Strategy loses integrity, and Maturity claims go unverified. Governance is the framework's immune system — it protects every other pillar's integrity. Patterns encode the "how" of Products: products built without reference to available patterns reinvent solutions that have already been learned. Patterns built without products to apply them to are academic. The two are complementary; designing products in awareness of available patterns accelerates quality without requiring reinvention. Maturity determines which Patterns can be safely executed: an organisation at Level 1 in a practice domain cannot reliably run Canonical patterns designed for Level 3. The Expression Gradient was designed to address exactly this — use it to find the right expression for your current capability, not the expression you aspire to. The six filter guides can be loaded simultaneously or applied sequentially. For an early-stage organisation beginning to make these distinctions explicit for the first time, the following sequence minimises the risk of building on assumptions that earlier steps would have corrected.Step 1 — Maturity first.
Before any other work, build an honest practice-level capability profile. Identify which domains are Ad-hoc (L1), Repeatable (L2), Standardised (L3), or Measured (L4). This prevents strategy, product, and governance work from being built on capabilities the organisation does not yet have. Use: P3 Filter Guide - Minimum Viable MaturityStep 2 — Extract Principles.
Identify the governing constraints that bound your solution space. Separate what you cannot change (Absolute, Regulatory) from what you have chosen (Institutional, Heuristic). Principles must be established before strategy or product work begins — they define the space within which strategy and products must operate. Use: P3 Filter Guide - Minimum Viable PrinciplesStep 3 — Formulate Strategy.
With a capability inventory and governing constraints in hand, formulate your directional slope. Apply the Strategy Sieve to each major element: Now, Grow, or Recalibrate. Ensure the strategy activates your Principles (the six-part brief's "Principle Activation" field), acknowledges the Maturity reality (the "Capability Assessment" field), and names what it explicitly will not pursue (the "Sacrifice List"). Use: P3 Filter Guide - Minimum Viable StrategyStep 4 — Design Products.
Translate the strategic direction into specific value transfers. For each product idea, apply the Transfer Test (what specifically moves to the beneficiary?), the Tripartite Classification (Theory, Instrument, or Service?), and the Validity Marker (can design choices be traced to a governing Principle?). Use: P3 Filter Guide - Minimum Viable ProductsStep 5 — Surface Patterns.
As product design proceeds, scan materials for recurring problem-solution pairs. Apply the Repeatability, Drift, and Patternitis checks. Document validated patterns with the six-element brief and classify each by Plasticity Status. Check each pattern's Expression Gradient against your Maturity profile before applying it. Use: P3 Filter Guide - Minimum Viable PatternsStep 6 — Build Governance.
Identify your three most critical commitments and apply the minimum governance structure to each. Calibrate governance intensity to maturity level. Apply Subsidiarity to everything below the top three: embed governance locally, at the team level, reserving central oversight for escalations and cross-boundary decisions. Use: P3 Filter Guide - Minimum Viable GovernanceThis is a bootstrap sequence, not a permanent operational order. Once all six pillars are active, they operate in parallel and constrain one another continuously.A complete P3 implementation is not required to begin benefiting from the framework. The minimum viable footprint — the smallest configuration that provides meaningful structure — requires five elements:This footprint is achievable in a single working session. It requires no existing P3 infrastructure. It requires only that the organisation is willing to answer honestly: What constrains us? Where are we going? What are we building? What can we actually do? And who is watching to make sure we do what we say?Patterns are deliberately absent from this minimum footprint. Not because they are unimportant — they are central to the framework — but because genuine patterns emerge from repeated practice and should be documented once they have demonstrated fitness across multiple contexts. Forcing pattern documentation before the work has generated repeatable instances creates premature institutionalisation.The Ratchet is on your side. Every distinction you make explicit is a permanent gain. Every category you clarify reduces interpretive noise in future decisions. The goal of this bootstrap toolkit is not to install a governance system overnight — it is to give the organisation the minimum vocabulary to stop conflating these six domains and start building deliberately, one tooth at a time.Begin with what you can defend today. The framework will meet you where you are.This guide is a companion reference to the six Minimum Viable filter guides. It does not replace them — it connects them. Each filter guide provides the operational detail for one pillar; this guide provides the architecture of their relationships and the sequence in which to apply them.]]>p3-governance/p3-reference/l1-bootstrapping/p3-beginners-guide.htmlP3-Governance/P3-Reference/L1-Bootstrapping/P3 Beginners Guide.mdThu, 14 May 2026 04:22:08 GMTp3-governance/p3-reference/l1-bootstrapping/p3-minimum-viable-maturity.htmlP3-Governance/P3-Reference/L1-Bootstrapping/P3 Minimum Viable Maturity.mdThu, 14 May 2026 04:22:08 GMTP3 Minimum Viable Strategy, P3 Programme Guidance
Derived from: IFC Strategy Brief - Stage 3 Strategy Pass (working paper, Droppings/) Binding key: The identifier SD-IFC-2026-001 is the spine of the IFC Programme. Every Factory Charter, Product Brief, Pattern Dossier, Saga, and Principle attribution within the IFC Programme must cite this identifier. Any artefact not carrying this identifier is not part of the IFC Programme. This Dossier confirms that IFC is a Programme, not a Product. IFC is a strategic framework that transfers value through five component products. IFC itself does not transfer value directly — it is the directional logic that holds the component products together and ensures they serve a coherent purpose.In P3 terms: IFC = this Strategy Dossier (SD-IFC-2026-001)
PST (Participant Statement) = Component Product #4 — brief exists at Product Brief - Participant Statement Toolkit Components #1, #2, #3, #5 = Products requiring their own briefs (see Component Inventory below) The P3 hierarchy: IFC Strategy Dossier → five Component Product Briefs.NAVV is moving toward participant financial sovereignty in the NDIS — from passive beneficiary to active, informed choice-maker — at a pace our current dual-credential SC/PRC practitioner model can sustain, building the informed consent tool suite and establishing the practitioner governance framework this epoch.Slope form confirmed: The direction is clear (participant financial sovereignty), the velocity constraint is real (current capacity = one or two dual-credential practitioners), and the epoch work is named (IFC tool suite build-out).The NDIS's "Choice and Control" mandate is structurally undermined by participant incomprehension of their own financial architecture. The system has, in practice, defaulted to passive coordinator assignment, while profit-seeking providers drain budgets through over-servicing and cancellation fees. Participants — particularly those with psychosocial disabilities — are making consequential financial decisions without the tools or knowledge to do so genuinely.Market void: No current NDIS service offering combines legislative compliance, financial transparency, visual accessibility, and the Registration Group R106 flexibility doctrine into a coherent, participant-facing consent suite. The R106 "Master Key" — allowing a single practitioner to move dynamically between Support Coordination (Outcome 8) and Psychosocial Recovery Coaching (Outcome 6) within Category 07 — is a unique regulatory opportunity that the market has not operationalised as a participant-empowerment mechanism.Blue Ocean position: IFC does not compete with existing NDIS coordinators on standard coordination services. It creates a new category: the informed-consent-centred SC/PRC practitioner who acts as a financial transparency navigator rather than a default service provider. This is structurally differentiated from the market, not marginally better than it.Summary: Two "Now" elements (compliance and governance infrastructure), five "Grow" elements (all five component tools), one "Recalibrate" element (scale). This is a viable strategic configuration — the direction is executable at current capacity for the build-out epoch, with scale deferred.
Corridor width: NAVV Maturity Assessment - 2026-05-08 is the governing Maturity Epoch Assessment for this Dossier.The following are explicitly out of scope and deliberately sacrificed to maintain the impartial advice model: Core Support provision (support workers, cleaners) — the single largest revenue category in the NDIS market, explicitly excluded to preserve independence Plan Management — excluded to avoid the financial incentive to maximise plan spend Supported Independent Living (SIL) — excluded; scale and compliance requirements incompatible with the practitioner model Clinical Therapy, Specialist Behaviour Support, Restrictive Practices — excluded; out-of-scope specialist services that would create scope creep and dilute the IFC focus Crisis response (CATT) and compliance enforcement — excluded; the IFC model is consent-based, not coercive This sacrifice list must be enforced as a governing constraint — not a business preference. As the IFC suite matures and trust grows, there will be commercial pressure to expand into excluded service areas. The sacrifice list is part of this Dossier and applies for the full epoch.Governing constraints foregrounded by this Dossier — the corridor walls of the IFC Programme:Principles requiring active defence: Managed Conflict of Interest — the sacrifice list must be enforced as a principle. PAPL Currency — visual guides embedded with price codes and category references will need regular refresh as PAPL changes. Current epoch: Build-out and first deployment of the five-component IFC tool suite in solo/small-team SC/PRC practitioner context.Epoch start: 2026-05-10 (this Dossier's issuance date)Epoch horizon: When all five component tools have been used in at least one complete NDIS planning cycle and first NDIA responses (Statements of Participant Supports) have been received.Recalibration signal: Structural evidence that the core hypothesis is failing — specifically, if NDIA planners are consistently rejecting or ignoring IFC-prepared statements, or if participants report the consent tools are too complex to engage with. Either finding would warrant rethinking the intervention model, not just the tool design.What does NOT constitute a recalibration signal: Individual tool defects (e.g., PST missing save function), early-phase confusion from practitioners unfamiliar with R106 flexibility, or single adverse NDIA responses. These are operational signals — fix the tool, refine the guidance.To materialise the IFC Strategic Bundle, query all P3-Governance artefacts citing SD-IFC-2026-001. The complete Programme is the derived set — not any stored container.As of issuance (2026-05-10), the IFC Strategic Bundle comprises:Issued: 2026-05-10. Derived from working paper in Droppings/. NbLM source: IFC notebook 07344d6e-933e-43f0-81e2-8576ff93e178.]]>p3-governance/strategy/strategy-dossier-ifc.htmlP3-Governance/Strategy/Strategy Dossier - IFC.mdThu, 14 May 2026 04:22:08 GMTNAVV-2026-05-08 — Stage 2 of P3 scaffolding Sentinel authority: Andrew (Principle pillar — market-facing principles) | Brian (Governance pillar — enforcement)
Reference: P3 Minimum Viable PrinciplesThis register formalises the governing constraints that NAVV has always operated under — but which have until now been implicit. Making them explicit is not a revolution. It is a naming exercise that enables governance.A principle is a governing constraint. If removing it would make our solution invalid, risky, or dishonest — it is a principle. If removing it would merely make our solution less efficient or less elegant — it is a preference.Applying the three-question governance test (Observability / Authority / Accountability) to all Institutional Principles:All four Institutional Principles pass the governance test at current maturity. No governance gaps identified at this stage.Artefact status: Active — first formal principles register. Supersedes any implicit principles previously embedded in CLAUDE.md or project documentation.]]>p3-governance/principles/navv-principles-register-2026-05-08.htmlP3-Governance/Principles/NAVV Principles Register - 2026-05-08.mdThu, 14 May 2026 04:22:08 GMTNAVV Maturity Assessment - 2026-05-08 — baseline capability terrain
NAVV Principles Register - 2026-05-08 — governing constraints
P3-Index — portfolio navigation index
Direction Statement — approved direction statement IFC structure identified (2026-05-09):
NbLM extraction pass on the IFC notebook (07344d6e-933e-43f0-81e2-8576ff93e178) revealed that IFC is a Programme (not a Product) — a strategic framework holding five component tools. Product Brief - Participant Statement Toolkit validated as Component #4 (active). IFC Strategy Brief produced as working paper in Droppings/.P3 Programme Guidance generated (2026-05-10):
P3 Programme Guidance produced to resolve Programme-level theory gaps in the P3 reference library — specifically: what a Programme is in P3 terms, the required artefact classes, and the lifecycle. Identified that the existing working paper constituted a valid Strategy Dossier pending formal issuance.Date: 2026-05-10 Type: GovernanceThe IFC Programme is formally established as a P3 Strategic Bundle.Artefacts issued this entry:Programme state at founding: Component #4 (PST): v7 prototype active. 22/23 requirements implemented. R-023 (save function) pending. Brief validated. Components #1, #2, #3, #5: not yet briefed. P3-Governance folder structure: Charters/ and Sagas/ folders created this entry. Strategy Sentinel signal: No recalibration signal active. Direction is confirmed viable. Build-out epoch begins.Date: 2026-05-11 Type: Structural Decision + Analysis
Programme-level analysis of Andrew's Product Brief: 02 (IFC notebook, source adc198b5). Full analysis in Droppings/: Programme Analysis - Product Brief 02, Gap Analysis - Product Brief 02 vs P3 Baseline.Key strategic findings: Mark Butler's commissioning process is the primary external threat — the free market for coordination is ending; only commissioned providers will be approved to operate as navigators New Framework Plans (delayed to April 2027) shift the NDIS from goals-led to needs-assessment-led — Participant Statement becomes a functional translation layer, not a plan driver The hybrid SC/PRC model is confirmed as the IFC programme's strategic core. The Practice Rationale and Audit Framework (embedded in Product Brief: 02) provides the audit-defensible compliance architecture Andrew's Goal 3 is absent — Choice and Control Flexibility Educator confirmed not intended as a standalone product Structural decision enacted (Brian confirmed): Component #3 (Choice and Control Flexibility Educator) merged into Component #1 (Visual Guide to the NDIS Plan) as Loop 4. Former standalone extract archived in Droppings/ as immutable history.Artefacts updated this entry:Product portfolio state at this entry:Practice Rationale routing decision (Brian): The Practice Rationale and Audit Framework is not a product component — it is a candidate for the wiki's first Territory Report. This knowledge is routed to the wiki intellectual commons, not to the IFC product inventory.Strategy Sentinel signal: No recalibration signal. The commissioning window (before April 2027) adds urgency to the epoch but does not change its definition.Saga opened: 2026-05-10.
Authorised under Factory Charter - IFC Build-Out (FC-IFC-2026-001) and Strategy Dossier - IFC (SD-IFC-2026-001).]]>p3-governance/sagas/saga-ifc-build-out.htmlP3-Governance/Sagas/Saga - IFC Build-Out.mdThu, 14 May 2026 04:22:08 GMTP3 Minimum Viable StrategyRevised and approved by Brian, 2026-05-08: We are exploring a new model for organisational development, structured around a distributed P3 governance model, using two founders. Andrew has sentinel responsibilities for market facing activities, including Principle, Product and Strategy. Brian has sentinel responsibilities for operational practices, including Pattern, Maturity and Governance. We are strategically testing a small range of high-potential product vectors, looking for the product-key that will unlock seed funding needed to grow the business. Brian noted that the single-sentence convention is not a constitutional requirement — clarity is more important than brevity. The approved direction statement is multi-sentence and preferred in that form. A condensed single-sentence form may be derived for use in summary contexts if needed.A full Stage 4 Direction Statement document will include: Principle Activation: Which governing Principles does this direction foreground?
Capability Assessment: Strategy Sieve applied to each strategic element (Now / Grow / Recalibrate) — see NAVV Maturity Assessment - 2026-05-08 for initial application Sacrifice List: What is explicitly excluded from this strategic direction? Review cadence: When is this direction reviewed and by whom? Stub created: 2026-05-08. Stage 4 formalisation pending Brian's direction.]]>p3-governance/strategy/direction-statement.htmlP3-Governance/Strategy/Direction Statement.mdThu, 14 May 2026 04:22:08 GMTP3 Minimum Viable Patterns, P3 Minimum Viable ProductsProduct patterns are the reusable, market-facing patterns intrinsic to NAVV's products — patterns that are embedded in how the products function within the NDIS marketplace, not in how NAVV's internal workflow operates.
These are distinct from workflow patterns (see Workflow Patterns). Brian's feedback explicitly identified these as a separate class: "there are other patterns that are intrinsic to the operation of Andrew's products within the marketplace itself… patterns used to compose the products themselves."Product patterns cannot be identified by examining NAVV's internal workflow — they emerge from Andrew's market domain knowledge. The P3 Minimum Viable Products filter, already loaded in Andrew's NbLM notebook, is the extraction mechanism.Planned extraction approach: Query Andrew's NbLM notebook using product-pattern-oriented questions (recurring problem types in NDIS service delivery that Andrew's products address) Apply the P3 pattern filter: does a proposed solution recur across multiple contexts? Is it teachable? Could it be applied by other organisations in the sector? Document each extracted pattern with a six-element brief Classify into sub-domains (e.g., participant advocacy patterns, support coordination patterns, plan management patterns) Brian's feedback notes these will "form different classifications of pattern types, within the taxonomy of our proto-pattern library." Candidate sub-domains: Participant advocacy patterns — recurring challenges participants face; structural responses the PST addresses Support coordination patterns — recurring challenges in SC practice; structural responses the wiki and future tools address NDIS navigation patterns — recurring challenges navigating the NDIS system; structural responses across NAVV's product range Product pattern extraction should be triggered by Brian via Missive when: Andrew has sufficient content in a product notebook to support extraction (intake threshold met) A new product domain is being designed and pattern analysis would inform the design Stub created: 2026-05-08. No patterns extracted yet. Awaiting NbLM filter extraction session.]]>p3-governance/patterns/product-patterns.htmlP3-Governance/Patterns/Product Patterns.mdThu, 14 May 2026 04:22:08 GMTP3 Minimum Viable Patterns
Workflow patterns are the reusable, named responses to recurring classes of operational problem in NAVV's build and delivery process. These are distinct from product-facing market patterns (see Product Patterns).At current maturity, these patterns are enacted but not yet formally documented with the P3 six-element brief. This file names them so they can be formalised over time.Full P3 pattern documentation requires a six-element brief for each: Pattern name and class Recurring problem addressed Solution form Expression Gradient (L1–L5 expressions) Plasticity Status (Proto / Emerging / Canonical) Governance authority None of these patterns have reached Canonical status. Formalisation should proceed pattern-by-pattern as each demonstrates fitness across multiple contexts.Stub created: 2026-05-08. Patterns to be formalised progressively under Brian's direction.]]>p3-governance/patterns/workflow-patterns.htmlP3-Governance/Patterns/Workflow Patterns.mdThu, 14 May 2026 04:22:08 GMTP3 Minimum Viable GovernanceThis register applies the P3 minimum governance structure to NAVV's three most critical commitments — the commitments whose violation would produce the most irreversible damage.The minimum governance structure for each commitment requires six elements: Commitment Statement Sentinel Role Friction Point Escalation Path Review Cadence Consequence Profile The following three commitments were identified in the impact assessment as the most critical:
Apply the full six-element governance template to GC-001, GC-002, and GC-003 #action/brian (to commission) Confirm sentinel authority for each commitment (aligned to PR-I001 Distributed Sentinel Model) Apply Subsidiarity principle: identify commitments below the top three that can be governed locally by the relevant sentinel Stub created: 2026-05-08. Full register pending Stage 5 commissioning.]]>p3-governance/governance/critical-commitments-register.htmlP3-Governance/Governance/Critical Commitments Register.mdThu, 14 May 2026 04:22:08 GMTp3-governance/p3-reference/ndis-dispersed-boundary-waterline-amendment.htmlP3-Governance/P3-Reference/NDIS Dispersed Boundary Waterline Amendment.mdThu, 14 May 2026 04:22:08 GMTStrategy Dossier - IFC Factory: NAVV Founders (Brian and Andrew) Issued: 2026-05-10 Epoch: IFC Build-Out — from 2026-05-10 until epoch horizon is met (see Dossier) Status: Active
This Charter grants bounded production authority to the NAVV Founders Factory (Brian and Andrew) to produce within the corridor defined by Strategy Dossier - IFC (SD-IFC-2026-001).Production authority is granted for the following scope: Design, build, and iterate the five IFC component tools (Components #1–#5), individually and collectively Produce and maintain Product Briefs, Factory Charters, Sagas, and governance artefacts that cite SD-IFC-2026-001 Engage with Andrew's NotebookLM notebook for requirements extraction and review Deploy the IFC tool suite in SC/PRC practitioner contexts and collect operational signals
This Charter does not authorise production outside the IFC Dossier's corridor. The sacrifice list in Strategy Dossier - IFC (Section 4) defines what is explicitly excluded. Factory output that would cross into Core Support provision, Plan Management, SIL, clinical therapy, or crisis response is out of scope for this Charter.The non-duplication rule and least-cost-appropriate-provider decision rule apply to all IFC tool outputs.Production within this Charter is constrained by the four foregrounded principles cited in SD-IFC-2026-001:Neither sentinel resolves decisions within the other's domain unilaterally. Escalation is mandatory where domains intersect.This Charter is decommissioned when the IFC Strategy Dossier epoch horizon is met: all five component tools have been used in at least one complete NDIS planning cycle and at least one NDIA response (Statement of Participant Supports) has been received for each.At decommissioning: This Charter is formally closed The IFC Saga (FC-IFC-2026-001) is resolved — completed, frozen, or transferred to a successor Dossier Products and completed Sagas are absorbed into NAVV's institutional memory A Strategy Sentinel review determines whether to issue a successor Dossier or close the Programme
Issued: 2026-05-10. Authorised under Strategy Dossier - IFC (SD-IFC-2026-001).]]>p3-governance/charters/factory-charter-ifc-build-out.htmlP3-Governance/Charters/Factory Charter - IFC Build-Out.mdThu, 14 May 2026 04:22:08 GMTNAVV-2026-05-08 — Stage 1 of P3 scaffolding Sentinel authority: Brian (Maturity pillar)
Reference: P3 Minimum Viable MaturityThis document provides an honest, practice-level capability profile of NAVV as of 2026-05-08. It sets the ceiling for safe governance complexity and calibrates the Strategy Sieve against Brian's revised Direction Statement.Maturity is the boundary of reliable execution. What we assess here is not what we aspire to — it is what we can sustain repeatedly, by both founders, under ordinary conditions.Ratchet Teeth convert capability gains into permanent features:Inside the capability frontier (reliable execution): Structured requirements capture via NbLM Wiki content development (RS ingestion workflow) Operational governance (Missive protocol, freeze-line) Structural quality assurance (registry.py) Review and iteration (Missive-driven) At the capability boundary (heroic effort required): Product design formalisation (brief templates not yet populated) Multi-notebook workflow management (not yet implemented) Workflow pattern documentation (identified but not yet formally named) Outside the current frontier (capability does not yet exist): Market-facing product pattern identification (requires NbLM filter extraction) Automated delivery pipeline Cross-notebook portfolio management Seed fundraising processes Applying the Now / Grow / Recalibrate sieve to the strategic elements in Brian's approved Direction Statement (2026-05-08):Recalibrate finding — seed funding: Seeking seed funding requires capabilities NAVV does not currently have: a formalised business narrative, investor-ready documentation, and fundraising process. The Direction Statement acknowledges this as a direction of travel, not a current commitment. No action needed now — but this finding should be revisited when product validation is complete. Recalibrate does not mean abandon.Recommended: Annual review minimum, triggered additionally by: Any significant change to NAVV's operational structure Launch of a new product (new notebook) Completion of Stage 5 (governance structures formalised) Artefact status: Active — first formal maturity assessment. Supersedes any informal estimates.]]>p3-governance/maturity/navv-maturity-assessment-2026-05-08.htmlP3-Governance/Maturity/NAVV Maturity Assessment - 2026-05-08.mdThu, 14 May 2026 04:22:08 GMTNAVV Principles Register - 2026-05-08 — PR-I001.]]>p3-governance/p3-index.htmlP3-Governance/P3-Index.mdThu, 14 May 2026 04:22:08 GMT