All posts by DAI - Data

000BCH, 09 - Agentic AI & DeFi

Agentic Ai In Defi

Welcome to the NZRT Wiki Podcast. Today we’re looking at Agentic AI in DeFi.

So let’s start with the big question: what actually makes an AI agent in DeFi different from the trading bots you might already know about? The key distinction is reasoning. A traditional DeFi bot follows fixed rules — if price hits X, do Y. An agentic AI reasons about whether to act at all. It reads the current state of the market, thinks through the situation, and decides. That adaptability is what makes it genuinely useful in fast-moving decentralised finance environments.

Let’s walk through the main roles an agent can play. First is a yield optimizer. This agent monitors interest rates across protocols like Aave, Compound, Yearn, and Morpho, then rebalances funds to chase the best returns — with built-in circuit breakers so it won’t rebalance if the gain isn’t worth it.

Second is a liquidity manager. If you’ve used Uniswap V3, you’ll know that concentrated liquidity positions need active management. This agent watches price ranges, tracks fee income, monitors impermanent loss, and repositions when the price drifts outside the target range.

Third, a risk monitor. This one watches loan health factors in protocols like Aave — collateralisation ratios and liquidation thresholds. If a position gets too close to being liquidated, it can trigger a partial repayment before it’s too late.

The fourth role is the most immediately relevant for NZRT: the Revenue Distributor for the ITE business unit. When ETH revenue arrives, this agent reads the ITSL token holder list, calculates each holder’s pro-rata share, and calls the distribute function on the smart contract — but only after a multisig approval step. More on that shortly.

And fifth, a KYC and whitelist manager. This agent processes investor applications, validates identity documents against New Zealand’s FMCA wholesale investor criteria, and either approves addresses onto the smart contract whitelist or escalates flagged cases to a human reviewer.

Now let’s talk about how these agents actually work. The most practical setup for NZRT right now is called an off-chain agent with on-chain signing. In plain terms: the AI runs off-chain as a reasoning engine powered by the Claude API. It uses read tools to pull live data — wallet balances, on-chain events, pool figures — via a service called Alchemy. It runs a decision loop, and if action is needed, it constructs a transaction and submits it to a Gnosis Safe multisig wallet for approval. A human or group of signers reviews and approves that transaction before it ever touches the blockchain. Critically, the agent never holds private keys. It cannot move funds on its own.

The reasoning pattern these agents use is called ReAct — short for Reasoning and Acting. Here is what that looks like in practice. The agent thinks: I should check the ETH balance in the ITSL distribution contract. It reads that balance. It observes there is half an ETH available. It thinks: the threshold is point one ETH, so we are good to proceed. It calculates the distribution across twelve holders. It proposes the transaction to Gnosis Safe. It observes the transaction hash. It then notifies the relevant person to approve it in the Safe interface. Think, act, observe, think again — that is the full loop.

For more complex multi-step operations — like withdrawing from one protocol, bridging to another chain, and depositing somewhere else — there is a plan-and-execute pattern. The agent builds the full plan upfront, then works through each step in sequence, verifying state at each stage before moving on.

Now, safety. This is arguably the most important part. On-chain mistakes can be irreversible, so agentic DeFi needs layered controls. There are six layers worth knowing. By default, agent tools are read-only — write access has to be explicitly enabled. Swap tools automatically reject transactions with more than half a percent slippage, protecting against MEV attacks. Each agent has daily transaction size caps hardcoded in its tool definitions, so a mistake has a ceiling on its damage. All value-transferring transactions must pass through the Gnosis Safe approval gate — that human-in-the-loop step is non-negotiable. Circuit breakers halt the agent and raise an alert if observed state moves outside expected bounds, which can signal an exploit or a compromised contract. And every single tool call is logged with a timestamp, its inputs, and its outputs — so if something goes wrong, you have a full forensic trail to work from.

For NZRT specifically, the immediate application is automating the ITSL revenue distribution process. Today that runs as a manual script. The agent version would watch for incoming ETH deposits via an event subscription, trigger when the balance clears a minimum threshold, calculate each holder’s share from live contract data, propose the distribution transaction to Gnosis Safe, and notify the finance agent and the administrator to approve it. After execution, it logs the event to Nextcloud. One important note: the agent automates execution, but it does not change the legal obligations under the FMCA. Legal review from the administrator is still required before any of this goes live on mainnet.

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

000BCH, 09 - Agentic AI & DeFi

Decentralized Ai Overview

Welcome to the NZRT Wiki Podcast. Today we’re looking at Decentralized AI Overview.

So let’s start with the basics. What actually is Decentralized AI? You might have heard it called DeAI for short. The idea is that AI model inference, training, and governance happens outside the infrastructure of any single centralized provider — companies like OpenAI, Anthropic, or Google. Instead of your application calling one company’s API, decentralized AI spreads that computation across a whole network of independent nodes. Those nodes are economically incentivized through tokens to participate honestly, and their outputs can be verified using cryptographic proofs.

To understand why that matters, it helps to compare it with what you’re probably already familiar with — centralized LLM APIs. Think about six key dimensions. First, control: with a centralized provider, one company is in charge; with a decentralized network, control is spread across many nodes. Second, pricing: centralized systems charge in USD based on usage, while decentralized networks use token-based incentives. Third, censorship: centralized providers enforce their terms of service, meaning some requests can be blocked, whereas decentralized networks are generally permissionless — though that varies. Fourth, verifiability: with a centralized provider you’re trusting them to run the model correctly, whereas decentralized systems can use cryptographic or zero-knowledge proofs to verify outputs. Fifth, latency: centralized APIs are highly optimized and fast; distributed networks tend to be slower. And sixth, model selection: centralized providers curate the models available, while decentralized networks are more open.

For most NZRT agent tasks, centralized APIs remain the right default. Lower latency, higher quality, simpler integration. DeAI becomes relevant for specific situations: censorship-resistant inference, on-chain verifiable AI decisions, or client workloads that require decentralization as a compliance or trust property.

Now let’s walk through the key decentralized AI networks worth knowing about. The first is Bittensor, which runs on its TAO token. Think of it as a decentralized machine learning marketplace. Validators score miners who run AI models, and the best-performing models earn TAO rewards. It’s organized into subnets — specialized networks for things like text generation, image processing, or even protein folding. For NZRT’s ICS consulting arm, this is relevant when clients want permissionless LLM access without being locked into a single provider, or when TAO itself is part of an investment thesis.

Next is Ritual, which runs an inference layer called Infernet. Ritual connects on-chain smart contracts to off-chain machine learning models — so a smart contract can actually call an AI model as a native operation, through Ritual’s oracle network. For NZRT, the interesting future architecture here would be an ITSL smart contract that calls an AI model to decide things like revenue distribution timing or investor eligibility.

Then there’s Giza, which focuses on Zero-Knowledge Machine Learning, or ZKML. This is about proving that a model ran correctly without revealing the inputs or the model weights. A smart contract can accept a zero-knowledge proof confirming that a specific model produced a specific output. The NZRT use case is around the ITE business unit — specifically, auditable ITSL revenue distribution, where you could prove the allocation algorithm ran correctly before the Gnosis Safe approves a transaction.

Similarly, Modulus Labs focuses on ZK-ML proofs for on-chain verifiable neural network inference, with a particular focus on gaming, DeFi, and prediction markets where outcomes have to be provably fair. And finally, Ocean Protocol is a decentralized data marketplace where data providers earn tokens and AI models can train on licensed data. For NZRT this is lower relevance — noted mainly as a knowledge reference.

Now let’s dig into that ZK-ML concept a little deeper, because it’s the most architecturally interesting one. The flow works like this: off-chain, an AI model runs its inference and generates a zero-knowledge proof of correct execution. That proof is then passed on-chain, where a smart contract verifies it and accepts the result as a trusted input — without ever having to recompute the inference itself. This creates what’s called trustless AI decisions on-chain. The practical implication for NZRT is that an ITSL distribution agent could prove it applied the correct allocation algorithm, and only then would the Gnosis Safe approve the transaction. Worth noting though: ZK-ML is still computationally expensive. Proof generation can take anywhere from seconds to minutes even for small models. It’s production-ready for simple models but still research-stage for anything at the scale of a large language model.

There’s also the concept of AI DAOs — Decentralized Autonomous Organizations that govern AI model parameters. A DAO can vote on which model version is used, what system prompts are applied, and how outputs are acted on. Bittensor subnets already do this, with TAO stakers voting on validator quality and model standards. For NZRT’s ITE unit, this could eventually mean ITSL token holders voting on which model drives distribution decisions — but that’s firmly a post-mainnet consideration.

So to bring it all together: across NZRT’s business units, the DeAI opportunities are real but all currently low priority. ZK-ML for ITSL distribution, AI DAO governance, and Ritual-style oracle integration are all on the radar for ITE — but flagged as post-mainnet. For current operations, keep using Claude via the existing AI agents stack. DeAI is a consulting knowledge domain and a future architecture option, not an immediate infrastructure change.

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

000DOL, 07 - Document Management

Data Export Import

Welcome to the NZRT Wiki Podcast. Today we’re looking at Data Export & Import.

If you’ve ever needed to move data in or out of Dolibarr, this is the feature set you’ll be reaching for. Whether you’re migrating from another system, feeding data into a business intelligence tool, or just taking a snapshot of your records, Dolibarr’s export and import capabilities are built to handle the job. The supported formats are CSV, Excel, and XML, which covers most of what you’ll encounter in day-to-day business workflows.

Let’s start with exports. Dolibarr comes with a set of built-in export profiles, which means you don’t have to configure things from scratch every time you want to pull data out. These profiles cover the key data types you’re most likely to need. You can export your customers and suppliers, your product catalogue, invoices, sales and purchase orders, contacts, and even custom fields you’ve added to extend the standard data model. That last one is particularly useful if your organisation has tailored Dolibarr to capture information that doesn’t fit neatly into the default setup.

When you run an export, you choose your profile, select the fields you want included, and Dolibarr generates the file for you. The result is a structured, clean export you can open directly in a spreadsheet application or feed into another tool. If you’re connecting to a business intelligence platform, this is often your starting point for a data pipeline, at least until you set up something more automated.

Now let’s talk about imports. Importing data into Dolibarr is done through a CSV bulk import process, and there’s a field mapping wizard that guides you through it. That wizard is your friend, especially if you’re bringing in data from a third-party system where the column names don’t match Dolibarr’s internal field names. You map each column in your file to the corresponding field in Dolibarr, and the system takes care of the rest.

One thing worth knowing is that Dolibarr includes error reporting during the import process. If something in your file doesn’t match the expected format, or if a required field is missing, you’ll get feedback before the data is actually committed. That means you can fix issues and re-run without worrying that you’ve already created a mess of partial records. There’s also rollback support, so if something goes wrong mid-import, you’re not left with half a dataset loaded and half missing.

That rollback capability is especially important during migrations. If you’re moving from another CRM or ERP into Dolibarr, you’ll likely be running imports multiple times as you clean and reformat your source data. Being able to undo a failed run and try again is a significant time saver and keeps things predictable.

A quick note on field names. If you’re preparing an import file and you’re not sure what Dolibarr expects each column to be called, the Module List is your reference point. It documents the field names used by each module, and you’ll want to cross-check those against your mappings in the wizard. Getting the field names right upfront will save you a lot of back-and-forth during the import process.

Now, if you need to move data programmatically rather than through the user interface, you don’t have to use the export and import screens at all. Dolibarr has a REST API that gives you direct access to the same data in a code-driven way. That’s the route to take if you’re building an integration, scheduling automated data syncs, or working with a developer who needs to push or pull records without any manual steps. The REST API is covered in its own documentation, but it’s worth knowing it exists as a complement to what we’ve covered today.

To bring it all together. Dolibarr supports export and import in CSV, Excel, and XML formats. On the export side you get built-in profiles covering customers, suppliers, products, invoices, orders, contacts, and custom fields. On the import side you get a field mapping wizard for CSV bulk imports, along with error reporting and rollback to keep your data clean. If you need to look up field names to prepare your import file, check the Module List. And if you need any of this done programmatically, the REST API is the way to go.

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

000DOL

Km Qa Seed List All Thirdparties Projects Tasks

Welcome to the NZRT Wiki Podcast. Today we’re looking at KM Q&A Seed List — All Thirdparties / Projects / Tasks.

This document is a draft seed list for NZRT’s knowledge management system. It hasn’t been pushed to Dolibarr yet — there are currently zero records in the KM module — but this is the source material for a future seeding pass. The data was pulled live from the Dolibarr API on the tenth of June 2026, covering fourteen thirdparties, nineteen projects, and sixty-four standing tasks. TOGAF projects and tasks are intentionally left out of this list and treated as a separate concern.

Before getting into the content, let’s talk about the entry format. Each knowledge management entry has three parts. First, a question — written as something realistic that an agent or team member would actually ask or raise as a ticket. Second, a concise one-to-three sentence answer. And third, a reference pointer to the relevant memory file, configuration section, script, or wiki document where you can dig deeper.

The first major section covers the four business unit projects — the API project for NZRT’s x402 knowledge base, ICS for Internet Consulting Services, ITE for the Iteasel product, and NCS for NZRT Charitable Services. All four share the same four task types. Task one is Marketing and Promotion — pam is the responsible agent, content goes out via WordPress using the wp dot py script, and forum posts go via the forum dot py Python tool. Never use PowerShell for forum posts — session cookies break the CSRF protection. Task two is Technical Development, tracked via system-specific ticket creation scripts with code stored in the matching repository. Task three is Client Delivery, where cas creates the delivery ticket linked to the relevant project and client. Task four is Operations, handled by fin for accounting and sun for procurement.

There’s a specific note for the NCS client delivery task. If a beneficiary submits the intake form but the Dolibarr ticket ends up missing the NCS tag, the problem is in the submission flow. The form posts via AJAX to the WordPress admin handler — not a REST endpoint — and goes through the Dolibarr bridge plugin to create the thirdparty record. The NCS category tag has to be applied via a SQL helper tool because the REST category endpoint isn’t available in this version of Dolibarr.

The second major section covers twelve system and infrastructure projects. For the Obsidian vault, you must read the instructions and schema files before writing any vault note — frontmatter, naming conventions, and cross-linking rules are non-negotiable. For GitHub, you use the gh CLI for GitHub-specific operations and plain git for local commits — never force-push without explicit confirmation. For cPanel and infrastructure, SSH access uses a specific key file and port, restricted to certain network addresses, and on a shared hosting environment you don’t have service restart permissions via SSH — use the cPanel interface instead. For WordPress, content edits go through the REST API via wp dot py, while plugin and theme file changes go through WebDAV. For Dolibarr, the REST API comes first, but for anything it can’t reach — like category tagging or dictionary entries — you drop to SSH and run MySQL directly on the production database. There is no local Dolibarr instance. For Nextcloud, public share links use the OCS sharing API with share type three and read-only permissions, and when uploading TOGAF documents the correct path goes through the Governance subfolder — not directly under the Obsidian root, which is a common mistake. For the Flarum forum, always use Python for posting — a CSRF error is the sign someone used PowerShell instead. For the agent framework, before writing any new script, search the agent repository for an existing ticket creation script first — there are purpose-built scripts with dry-run support for almost every system. And when someone says run pam or run agents, that means cla acts as that agent persona directly, pulls their open Dolibarr tickets, and does the work inline — the run-agents script is deprecated. For Windows operations, PowerShell only — Bash mangles environment variables and path formats. And remember, environment variable values set in one PowerShell call don’t carry over to the next, so set the Dolibarr API key at the top of every command chain that needs it.

The third section covers three vendor and financial projects. BNZ bank transactions are reconciled by fin using Dolibarr’s bank module — currently manual with no automated feed. Bunnings purchases are recorded by sun as supplier invoices against the Bunnings thirdparty. PayPal is treated as a virtual bank account in Dolibarr and reconciled against the payment platform configuration.

On coverage: nineteen of nineteen projects are documented, all sixty-four standing tasks have entries, and fourteen of fifteen thirdparties are covered — The Open Group is excluded because TOGAF is out of scope here. About twenty-five entries are based on documented incidents and existing memory files, and around ten are anticipatory entries based on domain knowledge rather than prior incidents — those are flagged inline. The whole list remains in draft and needs review before any push to the Dolibarr KM module via API.

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

000K8S, 10 - Kagent

Kagent Agents Tools

Welcome to the NZRT Wiki Podcast. Today we’re looking at Kagent Agents & Tools.

This page covers the built-in tools available inside Kagent, some real example agents configured for NZRT, and how you actually talk to those agents once they’re running.

Let’s start with the built-in Kubernetes tools. These come from something called the kagent-tool-server, and there are eight of them. Think of each one as a kubectl command wrapped up so an AI agent can use it. The first lets an agent list all available resource types in the cluster — similar to running kubectl api-resources yourself. Next there’s a tool for describing a specific resource, giving you the same detail as kubectl describe. There’s one for fetching pod logs, one for listing cluster events, and one for testing service connectivity from inside the cluster — similar to running curl internally. On the write side, you have a tool for applying a YAML manifest, a tool for patching a specific field on a resource, and finally a tool for deleting resources — though the docs flag that last one as something you should leave out of most agents.

Beyond the core Kubernetes tools, there are four extended MCP servers you can bolt on. Helm gives you install, upgrade, and rollback capabilities, enabled by setting a helm flag during install. Prometheus lets you run metric queries but requires Prometheus to already be running in your cluster. Argo CD adds GitOps sync, diff, and rollback and needs Argo CD installed. And Istio gives you service mesh configuration and traffic management, which requires Istio.

Now let’s look at three example agents NZRT has defined.

The first is the SRE Agent, built for read-only diagnostics. Its configuration marks it as a Declarative agent living in the kagent namespace. The system message tells it it’s a read-only SRE agent covering the nzrt-prod, nzrt-staging, nzrt-dev, monitoring, and kagent namespaces. It’s instructed to diagnose issues, explain pod failures, recommend fixes, never apply changes, and never expose Secret values in responses. The tools it gets are all read-only — resource listing, pod logs, describe, events, and service connectivity. You’d use this agent by asking things like why a pod is crashing in production, checking service connectivity for Nextcloud, or reviewing what events happened in staging over the last hour.

The second is the Staging Deployment Agent, which has controlled write access. Its system message scopes it strictly to the nzrt-staging namespace — it can apply and patch Deployments and Services there, but is explicitly told never to touch production and never to delete resources. It also has a rule to confirm with you before applying anything. On top of the read-only tools, it gets the apply manifest and patch resource tools as well. This is the agent you’d use for rolling out a new WordPress image to staging, scaling the Nextcloud deployment to two replicas, or pushing an updated ConfigMap.

The third is the Monitoring Agent, which combines Kubernetes logs and events with Prometheus metrics. Its system message tells it to query Prometheus and pod logs, identify performance issues, and deliver plain-English summaries flagging anomalies. It pulls tools from two MCP servers — the standard kagent-tool-server for pod logs and events, and a separate Prometheus MCP server that adds two more tools: one for instant metric queries and one for querying metrics across a time range.

Finally, let’s cover how you actually reach these agents once they’re deployed. There are three options. The first is the dashboard — you run the kagent dashboard command, open your browser to localhost on port 8082, select an agent, and start chatting. The second is the command-line interface, where you run a kagent chat command and specify the agent name and namespace — for example, targeting the nzrt-sre-agent in the kagent namespace. The third is a direct HTTP API call, where you post a JSON request to a local endpoint that includes the agent name in the URL path. The message body just contains the text of your question, such as asking it to list all pods in nzrt-prod.

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

000K8S, 07 - Monitoring

Monitoring Overview

Welcome to the NZRT Wiki Podcast. Today we’re looking at Monitoring Overview.

If you’re running workloads on NZRT’s Kubernetes cluster, you need to know how the observability stack is put together. Observability is really just a fancy word for being able to see what’s happening inside your systems — measuring performance, viewing logs, and checking whether your services are healthy. Today we’ll walk through the tools involved, how health probes work, and some quick commands you can use to check on things at any time.

Let’s start with the tools. NZRT uses six components to cover observability end to end. First, there’s Prometheus, which handles metrics scraping and storage — think of it as the thing that constantly collects numbers from your cluster, like CPU usage, memory, and request counts. Second is Grafana, which sits on top of Prometheus and turns all those numbers into dashboards and alerts you can actually read. Third is Loki, which handles log aggregation — it gathers log output from across your cluster so you can search and query it in one place. Fourth is Promtail, also known as Alloy, which is the log shipper that runs at the node level and feeds data into Loki. Fifth is kube-state-metrics, which exposes cluster state as metrics — things like whether a deployment has the right number of replicas, or whether a pod is pending. And sixth is metrics-server, which powers the kubectl top command so you can see live resource usage on pods and nodes.

Now, five of those six tools — Prometheus, Grafana, Loki, Promtail, and kube-state-metrics — all live in a namespace called monitoring. The last one, metrics-server, lives in kube-system, which is the core Kubernetes namespace reserved for system components.

Next up: health probes. These are a critical part of running production containers, and NZRT requires you to add them to every production container you deploy. There are two types, and they serve different purposes.

The first is a liveness probe. This is Kubernetes asking the question: is this container still alive and worth keeping around? In the example configuration, the liveness probe makes an HTTP GET request to the slash health path on port 80. It waits 30 seconds after the container starts before making its first check, then checks every 10 seconds after that. If the container fails to respond three times in a row, Kubernetes will restart it.

The second is a readiness probe. This one asks a different question: is this container ready to receive traffic? It’s similar in setup — it checks a path called slash ready on port 80 — but it starts checking sooner, after just 10 seconds, and checks more frequently, every 5 seconds. The failure threshold is still three. The key difference is what happens on failure: a failed readiness probe doesn’t restart the container, it just removes it from the load balancer rotation until it recovers. That’s an important distinction. Liveness failures restart. Readiness failures pause traffic.

Together, these two probes give Kubernetes the information it needs to manage your containers intelligently without any manual intervention from you.

Now let’s talk about quick checks — commands you can run at any time to get a fast read on what’s happening in the cluster.

The first command shows you resource usage across all pods in the production namespace. You’ll see each pod’s CPU and memory consumption at a glance. The second command is similar but zooms out to the node level, showing you how much each underlying machine is using overall.

The third command pulls recent events from the production namespace and sorts them by timestamp, so the most recent things that happened in the cluster are at the bottom. This is a great first stop when something seems off — events will often tell you about failed pulls, scheduling issues, or restarts before you even go looking.

The fourth command lets you describe a specific pod by name. When you run it, pay particular attention to two sections in the output: Conditions and Events. Conditions tell you the current state of the pod — whether it’s initialized, ready, and scheduled. Events tell you the history of what’s happened to it, including any probe failures, restarts, or errors. Between those two sections, you can usually diagnose most common pod issues without needing to dig any further.

If you want to go deeper from here, the wiki also covers Logging in its own article, and there’s a Cluster Overview page that gives you the broader picture of how the NZRT Kubernetes environment is structured. Both are worth reading alongside this one.

To summarise: NZRT’s monitoring stack uses Prometheus for metrics, Grafana for dashboards, Loki for logs, and a set of supporting tools to make all of it work. Every production container gets a liveness probe and a readiness probe. And when something goes wrong, you’ve got four quick commands to start your investigation — pod resource usage, node resource usage, recent events, and pod describe.

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

00 - Overview, 000LLM

Llm Overview

Welcome to the NZRT Wiki Podcast. Today we’re looking at LLM Overview.

So, what exactly is a Large Language Model? At its core, it’s a neural network that’s been trained on enormous amounts of text. We’re talking billions of web pages, books, articles, code repositories — you name it. The model learns statistical patterns across all of that data, and what makes it interesting is that after training, you can point it at all kinds of language tasks without having to retrain it for each one specifically.

Let’s talk about how one of these models actually processes your input, because understanding the flow helps a lot. You start with whatever text you type in — your prompt. That text gets broken down into tokens, which are small chunks of text, sometimes whole words, sometimes just parts of words. Those tokens then pass through a series of transformer layers, which use a mechanism called self-attention. Self-attention is what lets the model relate any token to any other token in the input — so it can understand context across the whole passage, not just word by word in sequence. After that, the model predicts the next token, and then the next, and the next — building up its response one piece at a time until it’s done. That overall design — the transformer architecture — was introduced in a 2017 paper and is the foundation of every major LLM you’ll encounter today.

Now let’s look at some key properties you’ll see referenced when people talk about these models. There are six worth knowing. First, parameters — these are the learned weights inside the model, and they’re what the model actually “knows.” Sizes range from about one billion parameters on the smaller end up to over a trillion for the largest models. Second, the context window — this is the maximum amount of text the model can hold in mind at once, measured in tokens. Older models handled around eight thousand tokens; newer ones go up to two million or more. Third, temperature — this controls how random or creative the outputs are. Set it to zero and you get very consistent, deterministic responses. Push it higher and the outputs get more varied and creative. Fourth and fifth are top-p and top-k, which are sampling filters — they give you finer control over how diverse the model’s word choices are. And sixth, RLHF — Reinforcement Learning from Human Feedback — which is a technique used to tune the model so it follows instructions well and behaves in line with human preferences. There’s also quantization, which is a compression technique that reduces the size of model weights so the model can run more efficiently.

Training one of these models happens in phases. The first phase is pre-training, where the model learns next-token prediction across that massive corpus of text — web content, books, code, all of it. The second phase is supervised fine-tuning, where the model is trained on curated question-and-answer pairs to get better at following instructions. The third phase involves RLHF or a similar technique called RLAIF, where a reward model and optimisation process align the model’s outputs more closely with what humans actually want. And finally, the model gets evaluated against benchmarks — standardised tests like MMLU for general knowledge, HumanEval for code, HellaSwag for commonsense reasoning, and MATH for mathematical problem-solving.

When it comes to what these models can actually do, the range is broad. They can generate text across formats — prose, poetry, code, structured data. They can summarise long documents down to the key points. They can classify and categorise content, including sentiment analysis. They can extract structured fields out of unstructured text, answer questions based on context you give them, and work through multi-step reasoning problems. They can write, explain, refactor, and debug code. They handle translation between languages. And increasingly, they can use tools — meaning they can call external APIs and functions as part of completing a task.

But there are real limitations you should keep in mind. Hallucination is probably the most important one — models can generate text that sounds completely plausible but is factually wrong, and they won’t always flag it. Second, there’s a knowledge cutoff — the model only knows what was in its training data, so recent events won’t be reflected. Third, the context limit means you can’t just feed it an arbitrarily large document and expect it to handle the whole thing. Fourth, models have no persistent memory by default — every time you start a new conversation, the model starts fresh, unless you’re using retrieval tools or external memory systems. And finally, models can be quite sensitive to how you phrase things — a small change in your prompt can meaningfully shift the output.

Those limitations aren’t reasons to avoid LLMs, but they’re important to design around. Knowing where the edges are is half the battle.

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

000LLM, 01 - Core Concepts

Tokens Context

Welcome to the NZRT Wiki Podcast. Today we’re looking at Tokens & Context.

Let’s start with the basics. What exactly is a token? A token is the fundamental unit of text that a large language model works with. Before a model can process anything, your text gets broken down into tokens — chunks that map to numbers in the model’s vocabulary. The process of doing this is called tokenization, and one popular method is called Byte Pair Encoding, or BPE for short.

So how big is a token in practice? Here are some useful rules of thumb. A single token is roughly four characters of English text, or about three quarters of a word. One hundred tokens works out to around seventy-five words. And a full page of text will typically cost you somewhere between five hundred and seven hundred and fifty tokens. One thing worth knowing: code, non-English languages, and special characters tend to use more tokens per character, so they’re less efficient from a token budget perspective.

Next up is the context window. This is the total number of tokens a model can handle in a single call, and that includes both what you send in and what the model sends back. Think of it as the model’s working memory. If you exceed the limit, the model simply cannot see what falls outside it.

Different models have very different context windows. Looking at some current examples: Claude Haiku, Sonnet, and Opus all offer two hundred thousand tokens. GPT-4o and Llama 3.3 70B each come in at one hundred and twenty-eight thousand. And Gemini 1.5 Pro sits at the top with a massive one million tokens. But bigger is not always better. Longer contexts increase both latency and cost, and not everything in a long context gets equal attention from the model.

That brings us to attention and position. The mechanism behind how models process context is called self-attention. It lets every token look at every other token in the context, but this gets computationally expensive fast. Specifically, it scales quadratically — so if you double the context length, you roughly quadruple the compute required.

Position also has a real effect on recall. Content placed at the very start or the very end of your prompt tends to be remembered most reliably. Anything buried deep in the middle is more likely to get overlooked. This is sometimes called the lost in the middle effect. The practical takeaway: put your most critical instructions at the beginning or end of your prompt, not sandwiched in the middle of a long document.

Now let’s talk about temperature and sampling — this is how you control the way a model generates output. Temperature is the most commonly used control. Set it to zero and the model becomes fully deterministic, always picking the most likely next token, giving you consistent repeatable output. Push it up to around zero point five and you get a balance of consistency with some variation. At one point zero you get the full sampling distribution, and above one the output becomes more creative and random, though it can start to lose coherence.

There are two other sampling controls worth knowing about. Top-p, sometimes called nucleus sampling, restricts the model to only sampling from tokens that together account for a certain share of the probability mass. Top-k does something similar but simply limits the choice to the most likely K tokens at each step. And max tokens is a hard cap — the model stops generating output at whatever number you set, regardless of whether it has finished.

The rule of thumb here is straightforward. If you need factual or structured output, keep temperature at zero or close to it. If you are brainstorming or want creative variety, something in the range of zero point seven to one point zero works well.

The last area to cover is how prompts are structured in a conversation. There are three roles. The system role is for instructions, persona setup, and constraints — it gets set at the start of a session and tells the model how to behave. The user role is for your actual input — questions, tasks, documents you want the model to work with. And the assistant role represents the model’s response, which can sometimes be pre-filled to guide the direction of the output.

One thing to keep in mind during multi-turn conversations is that all previous turns accumulate in context. Every message you send and every reply the model gives adds to the token count. Over a long session this eats into your token budget, so it is worth staying aware of how much context you are building up as a conversation grows.

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

000NCL, 06 - Administration

Logging Monitoring

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Logging & Monitoring.

Nextcloud generates logs constantly in the background, and understanding where those logs live and what they’re telling you is a core part of keeping the system healthy. At NZRT, logging ties directly into security auditing, performance monitoring, and catching issues before they become outages. So let’s walk through how all of this fits together.

First, let’s talk about where the logs actually are. There are five main log files you need to know about. The primary one is the Nextcloud application log, sitting at var www nextcloud data nextcloud dot log. This captures all Nextcloud events and is your first stop when something goes wrong. Next is the Apache access log at var log apache2 access dot log, which records every HTTP request hitting the server. Then the Apache error log at var log apache2 error dot log, which captures web server errors specifically. You also have the PHP-FPM log at var log php-fpm dot log for PHP-level errors, and finally the MySQL error log at var log mysql error dot log for anything going wrong at the database layer.

Now, how is logging configured? Inside Nextcloud’s main configuration file, there are a handful of settings that control this. The log type is set to file, so everything writes to disk. The log file path points to that nextcloud dot log location we just mentioned. There’s a log level setting that runs from zero to four — zero being debug, which logs everything including very verbose output, one for informational messages, two for warnings, three for errors, and four for fatal events only. NZRT runs at level two, so warnings and above get captured. The timezone is set to UTC for consistency, and there’s an automatic rotation setting — once the log file hits ten megabytes, it rolls over automatically so you’re not filling up your disk with a single enormous log file.

Next up is health checks. Nextcloud exposes a server info endpoint you can call to get a snapshot of system health. When you query that endpoint with admin credentials, the response tells you the current Nextcloud version, which PHP version and modules are loaded, the database connection status, current disk usage figures, how many users are active, and the state of background jobs. This is your go-to for a quick system pulse check, and it’s also something you can script to run on a schedule.

Speaking of schedules, let’s talk about monitoring thresholds. NZRT watches six key metrics. Disk usage triggers a warning at eighty percent and goes critical at ninety percent. Active concurrent users above one hundred is a signal to think about upgrading your plan. Database connections above eighty percent of the configured maximum need attention. Failed logins exceeding ten per hour are flagged as a potential attack. Background job queues with more than one hundred pending jobs indicate something is backed up. And Redis memory usage above eighty percent of its allocation means your cache is under pressure.

For alerting, there’s a bash script that runs on a cron schedule. What it does is check the current disk usage percentage for the Nextcloud data directory. If that number is above eighty, it sends an email alert to the admin address. It’s a simple but effective early warning for one of the most common failure modes — running out of space.

Now, how do you actually look at the logs day to day? You have two options. Through the web interface, you go into Settings, then Logging, and you’ll see the last entries displayed right there in your browser — no terminal needed. If you prefer the command line, you can stream the log live as events come in using tail, which is great for watching what’s happening in real time during a troubleshooting session. You can also search the log file for error entries and pull just the most recent twenty, which is usually enough to identify a pattern quickly.

To put this all in NZRT context — logging and monitoring aren’t just housekeeping. Failed background jobs can mean the Dolibarr sync isn’t running. A spike in failed logins could be a brute force attempt on the platform. Slow database queries show up in logs before they become user-facing problems. That’s why Dan, our DBA, reviews the logs on a daily basis. Catching something early in the logs is almost always cheaper than dealing with the downstream consequence.

If you want to go deeper, check out the related wiki notes on Administration Overview, Audit Logs, and the occ Command Reference. Those give you more detail on how to act on what the logs are telling you.

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

000OBS, 02 - Interface

Graph View

Welcome to the NZRT Wiki Podcast. Today we’re looking at Graph View.

If you’ve ever wanted to see your entire Obsidian vault laid out as a visual map, Graph View is the feature for you. It takes every note you’ve written and displays it as a network — each note becomes a dot, called a node, and every link between notes becomes a line connecting those dots. Notes that are heavily linked to other notes cluster together near the centre, while notes that don’t connect to anything float out on the edges on their own.

There are two ways to open Graph View, and they serve different purposes. The first is the Global Graph, which shows your entire vault all at once. You can open it by pressing Control and G together, or by clicking the graph icon in the ribbon on the left side of the screen. The second is the Local Graph, which is much more focused — it shows just the note you’re currently looking at, plus all of its direct connections. To open that one, click the three-dot menu on any note and choose Open Local Graph. You can also configure how deep the local graph goes, so it shows not just direct connections but connections of connections as well.

Once you’ve got a graph open, navigating it is pretty intuitive. You scroll to zoom in and out, or hold Control while scrolling if you prefer that. To move around the graph, click and drag to pan across it. And if you want to jump straight into a note, just click on its node and it’ll open right up.

Now let’s talk about filtering what you see, because a full vault can get quite busy. You access the Filters panel by right-clicking the graph or using the settings cog. There are a handful of useful options here. First, there’s a Search filter — you type in a query and the graph narrows down to only show matching notes. This supports special prefixes too, like typing “tag” followed by a colon and a tag name, or “path” followed by a colon to target a specific folder. Next, you can toggle Tag nodes on or off — these are the tag bubbles that appear alongside your notes in the graph. There’s also an option to show or hide Attachments, which covers things like images and other files you’ve linked in. If you’re seeing ghost links — those are links pointing to notes that don’t actually exist yet — you can hide those using the Existing Files Only option. And finally, there’s an Orphans toggle, which lets you show or hide notes that have no links at all. Hiding orphans is a great way to focus on the connected core of your vault.

Beyond filtering, you can also change how the graph looks through the Display Settings. Node size can be scaled based on how many connections a note has, so the more linked-up a note is, the bigger its dot appears. Similarly, link thickness can be scaled by link count. There’s a Text Fade Threshold setting, which controls the zoom level at which note names actually appear — useful if you don’t want labels cluttering the view when you’re zoomed way out. And then there are Groups, which let you colour-code nodes based on a search query. So for example, you could set all notes tagged with “project” to appear in blue, making them easy to spot at a glance.

Finally, there’s the Forces section, which controls the physics of how the graph arranges itself. Think of it like gravity settings for your nodes. The Center Force pulls all nodes toward the middle of the screen. The Repel Force pushes nodes apart from each other, which helps prevent everything from clumping into one big mess. The Link Force pulls connected nodes closer together, reinforcing those relationships visually. And the Link Distance setting lets you control the target spacing between connected nodes. If you have a really dense cluster that’s hard to read, you can adjust these forces to spread things out. Or if you want related notes to sit tightly together, you can increase the link force to pull them in closer.

That covers everything you need to get started with Graph View — from opening it and navigating around, to filtering your vault, tweaking the display, and adjusting the forces that shape the layout. It’s a powerful way to understand the structure of your notes and spot gaps or unexpected connections you might never have noticed otherwise.

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