After successfully crowd funding multiple R&D core activities, we decided to share our process to be compliant and successful.
A crowd‑funded R&D platform that guides teams through best practice, captures evidence, and keeps projects audit‑ready while the community funds each milestone.
Crowd-Funded Research & Development
Build the future together. Stay compliant, fund the research that moves Australia forward.
Service R&D guides teams through research & development compliance and best practice. Capture the full scientific process, publish evidence, and stay audit-ready while your community funds each milestone.
We teach the R&D lifecycle end‑to‑end: hypothesis, experimentation, evaluation, and documented outcomes.
Built for Australia: a structured process that aligns with R&D compliance expectations.
Focus areas: clean energy, climate tech, medical science, biotech, transport, defence, resources, agriculture, AI, quantum, and advanced computing.
Community outcomes: healthy ecosystems, thriving communities, and elevated Aboriginal and Torres Strait Islander knowledge systems.
Why crowd-fund R&D?
Open innovation builds trust. Share milestones, invite feedback, and let supporters fund the experiments that matter most.
Transparent milestones
Publish progress logs and evidence so backers can see outcomes as they happen.
Community-backed impact
Align funding with projects that strengthen technology, resilience, and social good.
Teams that deliver
Build multidisciplinary teams and keep knowledge moving from concept to deployment.
Compliance-First Workflow
Everything you need to meet exact R&D requirements
The workspace is built around the same documentation and evidence trail required for compliant R&D. Every step is captured so your project stays audit-ready from day one.
Built for Tax Agents & Firms
Export complete R&D datasets in minutes—structured evidence, financial records, and activity logs—so claims are prepared quickly and consistently.
Overview
Project metadata, scope, objectives, and timelines.
Planning
Planning documents and evidence that show intent and methodology.
Experimentation
Activity records, hypotheses, experiments, and outcomes.
Financials
Timesheets, invoices, contracts, and bank statements.
Logs & Exports
Trial logs, evidence capture, and CSV exports to prove compliance on demand.
Successfully Funded & Completed
Crowd-funded breakthroughs
These projects were completed with $280,000 in community funding and delivered with full R&D compliance documentation.
Black Box Computer
A breakthrough tiny local AI processing computer.
Crowd funded
$120,000
Autonomous Streaming Agent
An AI that can do everything a human can do in front of the camera.
Crowd funded
$90,000
AI Powered Marketplace
AI that brings products to customers faster than ever before.
Crowd funded
$70,000
Intelligence Machine — Local Open-Weight Model Serving and Agent Orchestration Evaluation
4traders pty ltd
Intelligence Machine was a March-May 2026 evaluation programme that asked whether a stack of locally-hosted, open-weight language models combined with an orchestration layer could support an AI agent producing useful, proactive (unprompted) output without a hard dependence on a cloud LLM provider. The motivation was on-premises operation: the runtime documentation for the associated aurai platform states that the AI must run fully on premises on an NVIDIA A6000 / 64 GB host, and the later successor platform hard-routes all personal-data turns to a local model as its single bright line. The evaluation therefore sat at the intersection of local inference viability and data-sovereignty for a proactive agent. The system under study was a locally-served open-weight model (Qwen2.5-Coder, 7B then 14B) served by vLLM (vllm/vllm-openai:latest) over an OpenAI-compatible endpoint on the on-premises A6000 host, driven by an existing agent harness, the Codex CLI. The Codex harness itself ran on the cloud model gpt-5.4 as its configured driver; the model under test was the local Qwen served over the OpenAI-compatible endpoint. The experiment was therefore framed as 'can the local model satisfy the harness already in use', not a from-scratch harness build. The documented vLLM serving parameters reflect fitting a 14B model into the A6000 / 64 GB envelope: --dtype half, --max-model-len 32768, --gpu-memory-utilization 0.95, with --enable-auto-tool-choice and --tool-call-parser hermes. The programme carried two coupled questions. First, model capability: whether a locally-served open-weight model could drive an agent harness reliably, in particular emit tool / function calls that an execution runtime would accept and act on. Second, orchestration: whether the proactive-agent behaviour should be assembled on an off-the-shelf workflow-automation platform (n8n) or on purpose-built orchestration. The two questions were coupled because the orchestration layer is what turns a model that can tool-call into an agent that acts. The outcome could not be known in advance. At March 2026 it was not established that a locally-served open-weight model could drive an agent harness by emitting execute-ready function calls; the failure surface lay at the interface between the model's output, the serving layer's tool-call parser, and the harness's wire contract, and vLLM tool-call parsers were immature at that date. The working belief that the local model could not tool-call survived into late May and required an explicit live refutation, which places the capability as genuinely unsettled through the whole window. The orchestration question was equally open: a workflow platform and a hand-built loop were both viable a priori, and no source could settle which would carry the proactive-agent behaviour on this hardware. The intended domains were on-premises, cloud-independent agent operation for privacy-sensitive and compliance-adjacent workloads: a proactive agent that could run inference locally, keep personal-data turns on the local model as a fail-closed default, and escalate to a cloud model only by opt-in. The target hardware was the single A6000 / 64 GB box reachable at the shared hostname mu.raum.au, which appears first as the n8n proxy domain in March and later as the suggested Gemma/vLLM endpoint and Riva ASR host across May-June. Objective: determine whether locally-hosted open-weight models plus an orchestration layer could drive a reliable, proactive on-premises AI agent free of a hard cloud-LLM dependence, and decide between an off-the-shelf workflow platform and purpose-built orchestration for that agent. The programme concluded by replacement: its findings flowed into a purpose-built successor platform (Naude, which became Core), where the local-model question was resolved positively with a compact model on the same hardware envelope.
Help crowd fund a project!
Public projects seeking support
Explore live research initiatives and back the breakthroughs that matter to you.
Intelligence Machine — Local Open-Weight Model Serving and Agent Orchestration Evaluation
4traders pty ltd
Intelligence Machine was a March-May 2026 evaluation programme that asked whether a stack of locally-hosted, open-weight language models combined with an orchestration layer could support an AI agent producing useful, proactive (unprompted) output without a hard dependence on a cloud LLM provider. The motivation was on-premises operation: the runtime documentation for the associated aurai platform states that the AI must run fully on premises on an NVIDIA A6000 / 64 GB host, and the later successor platform hard-routes all personal-data turns to a local model as its single bright line. The evaluation therefore sat at the intersection of local inference viability and data-sovereignty for a proactive agent. The system under study was a locally-served open-weight model (Qwen2.5-Coder, 7B then 14B) served by vLLM (vllm/vllm-openai:latest) over an OpenAI-compatible endpoint on the on-premises A6000 host, driven by an existing agent harness, the Codex CLI. The Codex harness itself ran on the cloud model gpt-5.4 as its configured driver; the model under test was the local Qwen served over the OpenAI-compatible endpoint. The experiment was therefore framed as 'can the local model satisfy the harness already in use', not a from-scratch harness build. The documented vLLM serving parameters reflect fitting a 14B model into the A6000 / 64 GB envelope: --dtype half, --max-model-len 32768, --gpu-memory-utilization 0.95, with --enable-auto-tool-choice and --tool-call-parser hermes. The programme carried two coupled questions. First, model capability: whether a locally-served open-weight model could drive an agent harness reliably, in particular emit tool / function calls that an execution runtime would accept and act on. Second, orchestration: whether the proactive-agent behaviour should be assembled on an off-the-shelf workflow-automation platform (n8n) or on purpose-built orchestration. The two questions were coupled because the orchestration layer is what turns a model that can tool-call into an agent that acts. The outcome could not be known in advance. At March 2026 it was not established that a locally-served open-weight model could drive an agent harness by emitting execute-ready function calls; the failure surface lay at the interface between the model's output, the serving layer's tool-call parser, and the harness's wire contract, and vLLM tool-call parsers were immature at that date. The working belief that the local model could not tool-call survived into late May and required an explicit live refutation, which places the capability as genuinely unsettled through the whole window. The orchestration question was equally open: a workflow platform and a hand-built loop were both viable a priori, and no source could settle which would carry the proactive-agent behaviour on this hardware. The intended domains were on-premises, cloud-independent agent operation for privacy-sensitive and compliance-adjacent workloads: a proactive agent that could run inference locally, keep personal-data turns on the local model as a fail-closed default, and escalate to a cloud model only by opt-in. The target hardware was the single A6000 / 64 GB box reachable at the shared hostname mu.raum.au, which appears first as the n8n proxy domain in March and later as the suggested Gemma/vLLM endpoint and Riva ASR host across May-June. Objective: determine whether locally-hosted open-weight models plus an orchestration layer could drive a reliable, proactive on-premises AI agent free of a hard cloud-LLM dependence, and decide between an off-the-shelf workflow platform and purpose-built orchestration for that agent. The programme concluded by replacement: its findings flowed into a purpose-built successor platform (Naude, which became Core), where the local-model question was resolved positively with a compact model on the same hardware envelope.
View projectCore — Private Container-as-Tenant AI Agent Platform with Local Sensitivity Routing and Governed Self-Improvement
4traders pty ltd
Core develops a per-user, container-as-tenant private AI agent platform: a single, self-contained, user-owned Docker image that packages a browser chat UI, an agent/orchestration service, a code-generation (builder) service, local model routing, a module runtime, long-term memory, and an in-container development console. The project deliberately rejects the shared multi-tenant SaaS pattern with row-level tenant scoping; each user container is treated as its own world. This tenancy choice — one container per user, thin image plus two fat writable volumes, s6-overlay as a fail-loud PID-1 supervisor — drives the project's central questions in privacy routing, fleet control, secret handling, and memory design. The platform began as Naude on 2026-05-20 and was rebranded to Core on 2026-06-10 in the raum-au/Star repository lineage; the last locally recorded commit is f7a91cd on 2026-07-04. The first objective is local sensitivity routing as a privacy boundary rather than a routing hint. Every conversational turn is classified public, personal-data, or claude-opt-in. Personal-data turns are forced to a locally served Gemma 4B-class model behind vLLM and never leave the container; the invariant is stated in the platform's own words as 'the single bright line: personal-data -> local, fail-closed'. Vault keys and OAuth tokens never enter any prompt, external Claude use is opt-in only, and in the Python runtime the boundary is enforced at llm/egress_guard.py with a locked, audited caller contract. Establishing this depended on first overturning a working belief carried from the prior local-inference work that a small local model 'can't tool-call'. The second objective is natural-language module building: converting ordinary 'build me...' conversation into real, runnable, permission-scoped modules inside the user's own container. A builder service runs a claude --print CLI subprocess against a spec.json treated as source of truth, through a staging -> validate -> atomic-promote pipeline, with build sessions persisted and resumable, and the code-generating process confined so it cannot escape the target module subtree or be driven by injected untrusted text. The third objective is no-inbound master/minion fleet control. A master (gru.raum.au) holding a scope-isolated AES-256-GCM key vault governs a fleet of minion containers with no inbound connectivity to the minions at all: minions initiate 30-second heartbeats and the master delivers commands only inside heartbeat responses, so the minion always initiates (NAT-friendly). New containers enrol with a single-use bootstrap token behind a human approval gate, and secrets are delivered scoped-to-a-minion and rotated without any key ever entering a model prompt. The fourth objective is three-layer long-term memory: topic -> consolidated master memory -> original captures, with a local-model A+B->C inference engine that derives cited new facts from pairs of master memories and a citation-preserving Q&A that answers from the agent's own memories. All embedding is local-only (Qwen3-Embedding-0.6B, 1024-dim, Qdrant cosine over a PostgreSQL system of record) so personal text never leaves the container to be embedded. The open aim is whether this structured, consolidating design is both more useful and auditable than flat vector recall and whether it stays coherent as the corpus scales. The fifth objective is governed autonomous self-improvement: an architect operator identity plus a manager -> builder -> antigen loop that runs overnight and in supervised marathons to build modules and fix bugs, bounded by a hash-pinned CHARTER.md, a watchdog, a kill-switch, a measurable goal, operator pause/resume, and a god-seat model pin (fable-or-wait). Supporting this, the initial Node/TypeScript runtime was replaced wholesale mid-project by a Python 3.12 / FastAPI / LangGraph / PostgreSQL / Qdrant / APScheduler runtime against a written G1-G25 gap register. The record is faithful to evidence standing. Where commits and in-repo documents establish an event it is stated as documented; effort hours and per-activity shares are estimates; the reading that two minority git author identities are agent self-commits is a labelled inference, not a confirmed fact. Several results remained open at the end of the local record and are represented as open: the quantitative structured-memory-versus-flat-recall benchmark was never run (functional and qualitative support only); unattended autonomy safety is not confirmed; four HIGH security findings were held for the operator and the Node-minion OAuth patch state is unconfirmed; and the 2026-06-02 -> 2026-06-10 repository window sits only in un-cloned raum-au Star/Naude* repositories and contributes 0 recorded hours. The project was open — further testing required — and was not concluded successful; it continued past this local record, hence status active.
View projectOracle - Local Enterprise Memory-and-Reasoning System over Microsoft 365 Email and Teams
4traders pty ltd
Develop a local enterprise memory-and-reasoning system, Oracle, that turns an organisation's own Microsoft 365 email and Teams communication history into a grounded, cited, permission-aware knowledge base without sending any sensitive corporate material to cloud AI services. The corpus is classified internal material, so there is no cloud AI path by design; the objective was to determine whether a trustworthy organisational-memory system of this kind could be built on commodity local infrastructure using open-weight models rather than frontier hosted models. The system runs as a fully local stack: Python 3.12, FastAPI (async), PostgreSQL 16 as the system of record, Qdrant as a rebuildable INT8 vector index, Redis with an arq worker, all under Docker Compose, with every model call routed to a local OpenAI-compatible gateway. The gateway serves open-weight models only: a Qwen-72B-class answering model, a local tool-calling model (qwen-tool) for deep research, BGE-M3 embeddings and a BGE reranker. The data pipeline runs in sequence: ingestion from Microsoft 365 and normalisation; cleaning and credential/sensitive-value scrubbing; sensitivity classification; LLM claim extraction with thread context; deterministic entity resolution; memory synthesis and machine inference; and LLM conversation segmentation into topic blocks. Above this sit the retrieval and presentation layers: grounded one-shot answering through a seven-mode query engine, bounded multi-round deep research, 2D/3D graph and memory-constellation views, and an authenticated MCP deep-investigation endpoint for external AI assistants. Access control is a first-class objective, not an afterthought. Every retrieval path applies role-based visibility checks before generation, expressed as a single SQL visibility predicate AND-ed into every read path - messages, claims, entities, threads, conversation blocks, the graph API and the deep agent's tools - so that restricted material is intended never to enter an answer or visualisation for an unauthorised principal. The programme was organised around six technical questions that were not answerable from existing knowledge at the outset: (1) whether local open-weight models could produce grounded, citation-backed answers over messy live corporate data; (2) whether entity resolution could be automated accurately enough without a human review step; (3) whether multi-round agentic deep research could run on a local tool-calling model; (4) whether message-atomic vectoring was adequate for conversational data; (5) whether the ingestion pipeline could sustain high throughput under real Microsoft Graph, async-runtime and operating-system constraints; and (6) whether role-based access control could be applied before generation across every retrieval path, including mixed-sensitivity conversation blocks. Each question was pursued by a progression of hypothesis, experiment, observation and conclusion, with the AI-assisted engineering session transcripts kept as the contemporaneous experiment record. Several hypotheses were refuted by experiment and replaced. The work was operator-directed AI-assisted engineering using Claude Code as build tooling. As at the close of the local record (2026-07-14, with live-system verification on 2026-07-15) Oracle is a live, experimentally grounded system that continues to ingest and enrich data; it is presented as active and ongoing rather than finished.
View projectBlack Box Continuation - Interactive Machine Intelligence Node
4traders pty ltd
Develop an Interactive Machine Intelligence Node (IMIN) that enables a user wearing AR computer-vision glasses, including devices such as Xreal One and similar wearable displays, to remotely control desktop software through a local AI computer. The system is intended to use microphone input, chat-to-model instructions, AR-oriented desktop/session context, multi-display computer-vision capture, native mouse/keyboard actions, and hand gesture control so the user can operate remote or local computer sessions without relying on vendor-provided APIs, workflow connectors, scripts, or traditional keyboard and mouse interaction. A central project objective is to determine whether IMIN can remember how different programs and sessions behaved previously. This session-context layer is technically important because arbitrary software control requires the AI computer to recognise visual state, recall previous layouts and failures, select appropriate OS-level actions, execute them remotely, and validate the result. Unlike software-specific automation, IMIN is being researched as a wearable AR control surface for arbitrary software. The local AI computer should observe screens, interpret visible interface elements, infer application state, plan actions, perform native input, recover from unexpected dialogs or changed layouts, and report results back to the AR glasses operator. The platform is intended for remote, industrial, emergency response, defence, field-service, and hazardous environments where hands-light operation, privacy, local processing, session continuity, and control of existing desktop tools are important. Objective: create an AR-glasses-based remote computer operator that lets a user speak, gesture, and visually supervise a local AI node controlling desktop software through computer vision and session memory.
View project