0Where we are

A snapshot of the project's state. This hub is the living memory — update it as things move.

Design work is largely complete and grounded in the club's real documents. The first interactive portal is live at royals.innerstate.au. Infrastructure is set up: innerstate.au now runs on Cloudflare DNS, and demos publish to here.now and get an {name}.innerstate.au subdomain. The next real engineering step is standing up the Cloudflare D1 schema (people → teams → events → money) and the import that loads the club's register and calendar, then pointing the portal at live data.

1The idea

One north star, two apps pointed at it.

You're building a brain.

An associative mapped graph with select-to-reorganise navigation — the way human understanding is stored, where meaning lives in the links, not the items. It's a core requirement for managing a business: the webspace is both faces at once — the public site and the inner management surface — and Ask is how the team coordinates across it.

2Concept stack

The layers, top (what people see) to bottom (the engine).

The portal — a page per member

Every member lands on a personal "what I need to do & know" page over one set of shared data: Player/Parent, Coach, Committee, Official, Sponsor, Admin. Led by a one-tap "your next thing" — designed so getting a club thing done feels effortless.

Two engines under it

• Development — a curriculum of video + info mapped to pathway stages, feeding each player's view and rolling up to the coach's.
• Operations · HQ — projects → tasks → routed to the right person with the right authority; templates turn know-how into ready-made work.

Compliance and Fundraising (money) thread through both.

The Big-Ask engine

A vague request ("update the website", "write a business plan") isn't one task — it's matched to a process template and exploded down into a structured action tree: Project → Lane → Process → Activity → Task, with owners, dependencies and a readiness gate. Same move InnerState makes on a source. It's a draft you refine; lessons feed the template, never the finished instance.

The PM interface

One graph, four projections — Map / Gantt / Kanban / List — navigated TheBrain-style: select any item (task, person, role, project, Ask) and the view reorganises around it to show only its neighbourhood. Keeps a thousand-task plan workable.

3The Ask system

The common front door — anyone enters a request once; it finds the right person and is tracked to a decision. (Grounded in the "Authority & Ask routing model" doc.)

The pipeline

Raw → structured → planned → watched. Train on how people actually type → map to the plan's structured language (keep the original viewable) → confidence-gated automation (auto-place when reliable; a wrong landing is one correction that teaches) → it becomes a managed plan item → an attention engine surfaces it on urgency or neglect.

The data model (5 records + outcome)

Authority lives on the role, not the person, so changing a volunteer never breaks routing. An Ask lands at the lowest role with enough authority, then moves upline / downline / to a catch-all.

The guardrail

The bot only suggests structure and routing. Authority, spend and access always come from confirmed rules a person approves — never the AI. "Training" means the club's rules & scenarios are built and confirmed (seed scenarios, shadow mode, a 90%-first-time-correct launch bar). Safeguarding and junior data are excluded from learning.

4Royals domain facts

From the club's real sheets (a Logan, QLD basketball club). Player identities are kept out of prototypes.

Organisation model

Three pillars — Admin, Operations, Projects; HQ coordinates (it is not another subcommittee). Two connected views: the organisation (pillars → roles → people) and the work (Project → Lane → Process → Activity → Task), joined through process ownership. One owner per task, many contributors (RACI).

5Architecture & infra

Where it all runs.

6Demos & links

Live prototypes and diagrams. (claude.ai artifacts open in your account.)

7Source docs

The club's own material (Google Drive).

Key reads digested: Authority & Ask routing model, peter V5 (+ response — the "Ask Planner" synthesis), the video curriculum, the player register, and the season calendar.

8Decisions locked

• Data on Cloudflare D1; sign-in via Access; API on Workers.
• One normalized register — every view pulls from it (relationships are structural, held in the schema's shape).
• Role-aware portal (6 roles) over shared data; HQ as the operations engine.
• Stages are age-anchored; termly assessments drive movement.
• Multi-tenant from day one (club → association → nation).
• The bot suggests; authority / spend / access are always human-confirmed.
• Real player identities stay out of prototypes.
• Demos host on here.now at *.innerstate.au; registrar stays GoDaddy, DNS on Cloudflare.

9Next steps

• Stand up the D1 schema for the spine (people → teams → events → money) and the import that loads the register + calendar.
• Wire the portal to live data (replace sample data with D1).
• Build the PM interface (one graph, four projections, brain-nav) and the Ask Planner → plan bridge.
• Ground the remaining details: stage-progression rules, the full event calendar, sponsor & fundraising specifics.
• Keep publishing demos to *.innerstate.au as they're built.