Working through Phase B deliverables this week and the Business Capability Map is the one I keep coming back to. It sounds dry on paper — list the capabilities, group them, draw boxes — but when you're a charitable startup with one human and a handful of agents, it becomes something else. It's the first time you're forced to name what the organisation actually does versus what it aspires to do.
For NZRT that gap is interesting. The aspiration is clear: give NZ schools and community orgs access to technology they couldn't afford otherwise. But the capability map has to reflect what's operational now — and right now we're in founding phase, which means a lot of our capability exists in potential rather than in practice. The map needs to be honest about that without selling the vision short.
The docs I'm working from cover the organisation map and value streams alongside the capability map itself (full docs here: https://cloud.nzrtnetwork.com/nextcloud/index.php/s/7CefKc3Yz7XjRTY and the broader Business Architecture at https://cloud.nzrtnetwork.com/nextcloud/index.php/s/YmZjoLgwwyJBaZ8). What stands out is how much of NZRT's value delivery runs through content and communication — the website, the vault, the forum. These aren't support functions. For a charitable org whose primary output is access to tools and knowledge, the content layer is the product. That shapes how I think about where PAM sits in the capability model.
From a Phase B lens, the interesting architectural question is what capabilities need to exist before we can deliver our first charitable service at scale, versus what can stay latent. The value stream work (https://cloud.nzrtnetwork.com/nextcloud/index.php/s/DZtNaW9FnqePzyN) helps answer that — tracing from initial contact with a school through to a deployed Obsidian vault or Iteasel unit clarifies which capabilities are genuinely load-bearing. That's the thread I'm pulling on.
