Tag Archives: nzrt

00 - Overview, 000BCH

Nzrt Blockchain Architecture

Welcome to the NZRT Wiki Podcast. Today we’re looking at NZRT Blockchain Architecture.

If you’re working at NZRT or just trying to understand how the blockchain side of things is put together, this episode gives you a clear picture of the full stack, from where code gets written all the way through to live tokens on the blockchain.

Let’s start with the big picture. The architecture shows a pipeline that flows from development tools down through testing environments and into production. At the top you’ve got Hardhat, which is the development framework the team uses to write and test smart contracts locally. From there, code can be deployed to a local test network running on your own machine, then out to Base Sepolia which is a public testnet, and finally all the way to Base Mainnet, the live production blockchain where real tokens exist. Connecting the smart contracts to the outside world is Alchemy, which acts as the RPC provider, essentially the communication layer between your application and the blockchain network. The primary smart contract right now is the ITSL Token, which follows the ERC-20 standard. There are also future contracts planned for things like staking, vesting, and governance. Sitting above all of this is a Gnosis Safe multisig wallet that acts as the contract owner and administrator. And everything is publicly visible and verifiable on Basescan, which hosts the contract verification and the public ABI.

Now let’s walk through the three deployment environments. The first is your local development environment. This runs on the Hardhat Network with a Chain ID of 31337 and connects to your own machine. This is where you do fast iteration, testing changes quickly without spending any real money or waiting on a network. The second environment is the testnet. This connects to Base Sepolia with a Chain ID of 84532 and uses Alchemy as the RPC provider. This is where you test your contracts in a realistic network environment before going anywhere near real funds. The third and final environment is production, Base Mainnet with Chain ID 8453, also running through Alchemy. This is the live network where the ITSL token actually exists and operates.

Next, let’s look at how contract ownership is structured. There are three roles to understand. The contract owner role is held by a Gnosis Safe wallet, operating as a two-of-three multisig, meaning you need at least two out of three authorised signers to approve any administrative action. This is an important security measure for a live token. The deployer role for testnet is a standard MetaMask externally owned account, used for testnet only. And for mainnet deployment, the Gnosis Safe itself acts as the deployer, so even the initial deployment of a production contract requires that multisig approval.

Now for the star of the show, the ITSL Token itself. This is an ERC-20 token, the most widely used token standard on Ethereum-compatible blockchains. It’s built on top of OpenZeppelin’s ERC20 base contract, an industry-standard audited library that gives you safe and reliable token functionality out of the box. The token lives on Base Mainnet, carries the symbol ITSL, and uses 18 decimal places, which is standard for ERC-20 tokens and allows one token to be divided into incredibly small fractions for precise transactions. The total supply is defined separately in the tokenomics documentation, so the contract itself stays flexible on that front.

To tie it all together, you’ve got a clean layered architecture. Development starts locally with Hardhat, gets validated on Base Sepolia testnet, and graduates to Base Mainnet for production. Alchemy handles the RPC connectivity throughout. The ITSL ERC-20 token is the current live contract, secured by a Gnosis Safe multisig for all ownership and admin actions. And Basescan provides public transparency for anyone who wants to verify the contract code.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

000FLA, 05 - NZRT Forum

Togaf Phase Tags

Welcome to the NZRT Wiki Podcast. Today we’re looking at TOGAF Phase Tags.

If you’ve spent any time in the NZRT forum, you’ve probably noticed that discussions are organised by tags. For TOGAF work specifically, those tags map directly to the ADM phase cycle, and understanding how they fit together makes navigating forum content a lot easier.

Let’s start with the phase tags themselves. There are ten of them covering the full TOGAF ADM lifecycle. The Preliminary phase uses the slug preliminary-phase and has a tag ID of 5. Phase A, Architecture Vision, is phase-a with ID 6. Phase B, Business Architecture, is phase-b with ID 7. Phase C, Information Systems, is phase-c with ID 8. Phase D, Technology Architecture, is phase-d with ID 9. Phase E, Opportunities and Solutions, is phase-e with ID 10. Phase F, Migration Planning, is phase-f with ID 11. Phase G, Implementation Governance, is phase-g with ID 12. Phase H, Change Management, is phase-h with ID 13. And finally, Requirements Management uses the slug requirements-management with ID 14.

Beyond the phase-specific tags, there are eight general-purpose tags. General is ID 15, Tasks is 16, Announcements is 17, Dev is 18, API is 19, and then three business unit tags: ICS at 20, ITE at 21, and NCS at 22.

Now, here’s the practical detail you need to know depending on what you’re doing. When you’re creating a new discussion using the forum tool, you pass the slug string directly into the tag parameter. So you’d write something like phase-f, and the tool resolves that to the correct numeric ID internally. You don’t have to worry about the numbers at that point.

However, if you’re patching an existing discussion to add or change a tag, the numeric ID is required. And there’s an important constraint here: you can only apply one tag per patch request. If you try to include multiple tags in a single patch, you’ll get a 500 error. So keep those calls separate. Also worth noting, you must use Python for patch operations. PowerShell fails because of how it handles CSRF tokens.

On the topic of filtering discussions by phase, the wiki includes an example of the API call you’d use. In plain terms, it’s a GET request to the forum’s API, pointing at the discussions endpoint, with a filter parameter specifying the tag slug you want and a page limit of up to 50 results. You use the full slug, so phase-f rather than any shortened version. If you’re using curl on the command line, you need the -g flag to stop curl from misreading the square brackets in the URL as glob patterns.

Putting it all together in the TOGAF workflow: at each ADM phase, a script called create_togaf_phase_tickets.py is run with the phase letter as an argument. That creates eight agent tickets, one per agent. Each agent then posts their forum discussion under the relevant phase tag. Once all eight discussions are up, both xc and cla review them before the gate sign-off document is produced. The tags are what keep all of that content organised and filterable throughout the process.

So in short, slugs for creating, numeric IDs for patching, one tag per patch, and always Python for forum write operations.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

000K8S, 10 - Kagent

Kagent Setup Nzrt

Welcome to the NZRT Wiki Podcast. Today we’re looking at Kagent Setup — NZRT.

This episode walks you through installing kagent in the NZRT Kubernetes cluster and wiring it up to use Claude Sonnet as the primary language model. By the end you’ll have a working SRE agent running inside the cluster and ready to diagnose problems.

Let’s start with what you need before you begin. There are five prerequisites. First, a Kubernetes cluster — NZRT already has prod, staging, and dev namespaces set up. Second, kubectl configured with cluster access. Third, Helm version 3 for the chart installation. Fourth, an Anthropic API key from the NZRT Gmail Anthropic account. And fifth, the kagent CLI itself, which we install in the very first step.

Step one is getting the kagent CLI onto your machine. You run a one-line install script that downloads and runs the installer automatically from the kagent website. Once that finishes, you check that it worked by asking for the version number. If a version comes back, you’re good to move on.

Step two is creating the kagent namespace in your cluster. A single kubectl create namespace command handles that. You then label the namespace with three NZRT standard values — owner set to nzrt, service-code set to 000K8S, and environment set to prod. Those labels keep things consistent with how NZRT organises all its cluster resources.

Step three is storing your Anthropic API key as a Kubernetes secret. You create a secret called anthropic-key inside the kagent namespace, passing your API key in as a literal value. You then run a get secret command to verify it’s there. Once you see it listed, the key is safely stored and ready to use.

Step four is the main Helm installation. You add the kagent chart repository, update your local cache, then run the install command. That command puts kagent into the kagent namespace and you pass in three settings: the default provider is Anthropic, the secret name is the one you just created, and you specify which field inside that secret holds the actual key value. After the install, you check the rollout status of the kagent controller deployment and list all pods in the namespace to confirm everything is running.

Step five is creating a ModelConfig resource. This is how you tell kagent exactly which Claude model to use. You write a small YAML file defining a resource of kind ModelConfig, name it claude-sonnet, place it in the kagent namespace, and add the NZRT owner and service-code labels. In the configuration spec you reference the anthropic-key secret, set the model to claude-sonnet-4-6, and set the provider to anthropic. You apply the file with kubectl and the model config becomes live. The wiki also notes that for heavier reasoning tasks you can create a second ModelConfig pointing at claude-opus-4-7.

Step six is deploying the NZRT SRE agent, and this is where everything comes together. The agent is defined in another YAML file, this time as a resource of kind Agent. It’s named nzrt-sre-agent, lives in the kagent namespace, and carries the standard NZRT labels. The most important part is its system message — the instruction set that defines what the agent does and how it behaves. It tells the agent it is an SRE agent for the NZRT cluster, lists the namespaces it works across — prod, staging, dev, monitoring, and kagent — and sets firm boundaries. It must use read-only tools first, it must never delete or modify resources, and when it has a fix recommendation it should output the exact command or YAML but wait for human confirmation before anything gets applied. The agent is linked to the claude-sonnet ModelConfig from the previous step. It also gets five tools from the kagent tool server: get resources, get pod logs, describe a resource, get cluster events, and check service connectivity. You apply the file with kubectl just as before.

Step seven is opening the dashboard. A single kagent dashboard command launches a local web interface at port 8082. If you prefer to do it manually, you can use kubectl to port-forward the kagent dashboard service to that same port on your machine.

To know that everything is working correctly, run through this mental checklist. All pods in the kagent namespace should show as Running. Your claude-sonnet ModelConfig and your nzrt-sre-agent should both show a Ready status. The dashboard should be reachable at localhost on port 8082. And when you send the agent a test message asking it to list all pods in nzrt-prod, it should respond with that pod list — confirming the model connection and tool access are both functioning end to end.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

00 - Overview, 000K8S

Nzrt K8S Architecture

Welcome to the NZRT Wiki Podcast. Today we’re looking at NZRT K8s Architecture.

So what is this page all about? It covers NZRT’s specific approach to running Kubernetes — that’s the container orchestration platform you might have heard of — including how the cluster is designed, how workloads are organised, and how deployments are automated.

Let’s start with the cluster overview. The platform itself is still being decided, and the version and node count will be confirmed once the cluster is actually provisioned. What is already locked in is the container runtime — NZRT will be using containerd, which is one of the most widely adopted and production-proven runtimes in the Kubernetes ecosystem.

Next, let’s talk about the namespace strategy. If you’re new to Kubernetes, namespaces are logical partitions inside the cluster — a way to separate different environments and concerns so they don’t interfere with each other. NZRT has five namespaces planned. The first is nzrt-prod, which is where all production workloads live. Then there’s nzrt-staging, the pre-production environment — also called UAT, or User Acceptance Testing — where things get validated before going live. After that you have nzrt-dev, the space for development and active testing work. Then there’s a namespace called monitoring, which hosts the observability stack — specifically Prometheus for metrics collection and Grafana for dashboards and visualisation, along with the logging stack. And finally there’s ingress-nginx, which runs the ingress controller — that’s the component responsible for routing external web traffic into the right services inside the cluster.

Now let’s look at workload placement — which specific services run where, and how they’re configured. There are four services mapped out so far. WordPress runs in the production namespace as a Deployment, and it connects to an external MySQL database rather than one running inside the cluster itself. Dolibarr, which is NZRT’s ERP and CRM platform, also runs in the production namespace as a Deployment. Nextcloud, the file and collaboration platform, runs in production as a StatefulSet. If you’re wondering what the difference is, StatefulSets are used when a workload needs stable storage that persists across restarts — which Nextcloud definitely requires. And finally, there’s a planned blockchain node for future use — also a StatefulSet in production — which will connect to the Base network once it’s brought online.

Now let’s cover the CI/CD integration. That stands for Continuous Integration and Continuous Deployment, and it’s the automated pipeline that takes your code changes and gets them running in the cluster without manual steps in between. The diagram in the documentation shows a flow that starts at GitHub, where all code repositories live under the NZRT source control setup. From there, a GitHub Actions workflow kicks in automatically. That workflow does two things: first it builds a Docker container image and pushes it to a container registry, and then it applies the updated configuration to the Kubernetes cluster — either directly or through a tool called Helm, which is a package manager for Kubernetes that simplifies managing complex deployments. The end result is a rolling deployment, meaning the update rolls out gradually so there’s zero downtime — your users stay connected while the new version comes up in the background.

The documentation also points to a few related resources if you want to go deeper. There’s a general Kubernetes Overview page, the Infrastructure Vault under the code 000INF, and the GitHub Vault under 000GIT.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

000K8S, 08 - NZRT Config

Nzrt Kubernetes Setup

Welcome to the NZRT Wiki Podcast. Today we’re looking at NZRT Kubernetes Setup.

This wiki covers how NZRT configures and manages its Kubernetes cluster — from the initial namespace setup right through to workload deployment conventions. Let’s walk through it together.

First, a quick look at the cluster details. The provider, Kubernetes version, and node count are all still to be confirmed — they’ll be updated once the cluster is provisioned. What we do know is that if a cloud provider is used, the cluster will be hosted in New Zealand. And when it comes to access, the kubeconfig file — which is the credential file that lets you connect to the cluster — is stored securely in the Nextcloud vault under the 000NCL section.

Next up is namespace setup. In Kubernetes, namespaces let you divide a single cluster into logical sections, keeping different environments and concerns separated. NZRT sets up five namespaces when bringing a cluster online. You create one called nzrt-prod for production workloads, one called nzrt-staging for staging, and one called nzrt-dev for development. Then you add a monitoring namespace for observability tools, and finally an ingress-nginx namespace for the ingress controller. These five namespaces form the foundation of every NZRT cluster.

Now let’s talk about standard labels. Every resource you deploy in the NZRT cluster should carry a consistent set of labels. These labels are key-value pairs attached to Kubernetes objects that help you identify, filter, and manage resources at scale. The label set NZRT uses has five fields. First is app, which you set to the name of your application. Second is environment, which should be prod, staging, or dev depending on where the workload lives. Third is owner, which is always set to nzrt. Fourth is service-code, which carries the value 000K8S. And fifth is managed-by, which tells you whether the resource was deployed using Helm or kubectl directly. Applying these labels consistently across everything you deploy makes cluster management much easier down the line.

Moving on to ingress setup. NZRT uses nginx as its ingress controller — this is the component that routes external HTTP and HTTPS traffic into your cluster services. To install it, you first add the ingress-nginx Helm repository, then use Helm to install the chart into the ingress-nginx namespace. That one Helm command handles the full installation, and if the namespace doesn’t already exist, it creates it automatically.

After ingress, you’ll want to set up cert-manager. This is what handles automatic TLS certificate provisioning for your services — so your apps get HTTPS without you having to manually manage certificates. You install cert-manager by applying a single manifest directly from the cert-manager GitHub releases page. Once that’s done, you configure a ClusterIssuer resource. Think of a ClusterIssuer as a cluster-wide object that tells cert-manager where and how to request certificates. NZRT’s ClusterIssuer is named letsencrypt-prod and it points to the Let’s Encrypt production certificate authority. It uses the ACME protocol with an HTTP challenge — meaning Let’s Encrypt verifies domain ownership by making an HTTP request through your nginx ingress. The contact email registered with Let’s Encrypt for NZRT is nzrtnetwork at gmail dot com, and the private key generated during that registration is stored in a Kubernetes secret also named letsencrypt-prod.

Finally, let’s run through the NZRT workload checklist. Before you consider any workload ready for deployment, there are eight things you need to confirm. One — your namespace has been created and a ResourceQuota is in place to prevent any single namespace from consuming too many cluster resources. Two — RBAC roles have been applied, meaning the right permissions are granted to the right service accounts. Three — any secrets your app needs have been created directly in the cluster and are not committed to a Git repository. Four — liveness and readiness probes are configured so Kubernetes knows when your app is healthy and when it is ready to serve traffic. Five — resource requests and limits are set on your containers so the scheduler can place them correctly and prevent resource starvation. Six — your ingress is configured with TLS so traffic to your service is encrypted. Seven — if your workload needs persistent storage, that has been provisioned, typically using StatefulSets. And eight — your CI/CD pipeline in GitHub Actions is configured and connected to the cluster.

If you want to go deeper, the related pages to check out are the NZRT K8s Architecture doc and the GitHub vault under 000GIT for CI/CD pipeline details.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

000NCL, 07 - NZRT Configuration

Nzrt Folder Structure

Welcome to the NZRT Wiki Podcast. Today we’re looking at NZRT Folder Structure.

If you’ve ever wondered how NZRT organises its files in Nextcloud, this episode walks you through the whole picture — from the top-level layout all the way down to individual folders for finance, HR, sales, and more. The structure is designed to match how the business actually works, and it ties directly into Dolibarr ERP, WordPress, and the various agent roles you might already be familiar with.

Let’s start at the top. There are four main areas sitting at the root level of Nextcloud. You’ve got Shared, which is the main team workspace. Then WordPress, which holds content for the website. Then Public, for sharing files with clients and vendors outside the organisation. And finally Archive and External, which handle long-term storage and connections to backup systems like a NAS drive or cloud archive on S3.

The Shared folder is where most of the action happens, and it’s owned by the EDM agent, ema. Inside Shared, you’ll find dedicated folders for Marketing, Sales, Procurement, Finance, HR, Analytics, Database, and a few others. Each one is scoped to a specific role — so for example, pam has read and write access to Marketing, cas handles Sales, sun looks after Procurement, fin owns Finance, han manages HR, and dai works across Analytics. There’s also a credentials folder that only xc, the admin, can access.

Let’s look at some of these in more detail.

The Finance folder sits under Shared and contains subfolders for invoices organised by month, purchase orders split into active and completed, bank statements which are end-to-end encrypted, budget files, and monthly reports. Access is limited to fin and xc. Bank statements require encryption — that’s non-negotiable. And everything in Finance is kept for seven years to meet legal requirements.

HR follows a similar pattern. You’ve got an Employees folder with subfolders for active and departed staff, and within each employee’s folder you’ll find things like their offer letter, contract, and performance reviews. There’s also a Payroll folder — also end-to-end encrypted — containing monthly payroll spreadsheets and reports. Then Onboarding, with checklists and forms, and a Policies folder holding documents like the code of conduct and benefits guide. Only han and xc can access HR, and like Finance, retention is seven years.

Sales is managed by cas and gives read access to pam as well. Inside you’ll find a Clients folder where each client gets their own subfolder containing contracts and quotes. There’s also a Proposals folder, a Deals area with a shared spreadsheet linked to the project board, and a CRM Export folder where Dolibarr contact exports land as CSV files. Public share links are enabled for contracts, but they expire after thirty days. Sales records are kept for three years.

Procurement, managed by sun, holds purchase orders organised by year, a Vendors folder where each vendor has their own space for contracts and pricing, a folder for requests for quotation, and a folder for invoices received from vendors. Finance also has read access here. Retention is three years.

There’s a Templates folder that all users can read but only ema can update. It contains finance templates like invoice and budget spreadsheets, sales templates including proposal slides and contract documents, HR templates for offer letters and NDAs, and general templates for things like standard operating procedures and meeting minutes.

The Analytics folder is owned by dai and is used for aggregating data across systems. You’ll find weekly and monthly report folders, and an Exports section with data pulled from Dolibarr and other systems. This folder rolls over on a one-year cycle.

The Database folder is managed by dan and stores daily and weekly backups, system logs, and a yearly archive. Daily backups are kept for thirty days, and weekly backups are retained for a full year.

One of the more technically interesting folders is Dolibarr EDM. This is where Nextcloud and Dolibarr connect directly. Documents generated in Dolibarr — invoices, contracts, purchase orders — are automatically synced into this folder every night at two in the morning via a webhook and REST API integration. You’ll also find a Sync Log folder that records what happened during each sync, including any errors. The folder is owned by ema.

To bring it all together — every folder in this structure maps to a real business role, has defined access permissions, specifies whether encryption is required, and sets a retention period. Nothing is left ambiguous. Whether you’re fin looking for an invoice from three months ago, or dan checking a database backup log, you know exactly where to go.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.