Services / AI and knowledge systems

Practical AI, built on what your business already knows.

Most businesses have years of knowledge spread across documents, inboxes and people's heads. We help you organise it so people and AI tools can use it, then put AI to work where it earns its place.

A person says yes before anything is sent, spent, published or changed in production.

The problem we solve

AI is only as good as what it knows about your business.

Generic AI tools do not know your customers, your systems or the decisions you made last year. So they guess, and someone has to check everything they say.

We start by giving AI a reliable source of truth: an LLM wiki built from your own documents, with a source for every claim. Then we put agents and models to work on top of it, with people approving anything that matters.

How we work

Six steps, from idea to AI that does real work.

We use these steps to run our own business, and we use them with clients.

Our AI process: find where AI fits, use AI to build an LLM wiki from your documents, put the wiki to work, build an agent harness with human approval gates, build AI into your software, then review and improve. 01 Find the fit where AI helps 02 Build the wiki AI drafts, people review 03 Use the wiki grounded answers 04 Agent harness roles and gates 05 AI in your software models in the workflow 06 Review and improve
Our AI process: find where AI fits, use AI to build an LLM wiki from your documents, put the wiki to work, build an agent harness with human approval gates, build AI into your software, then review and improve. 01 Find the fit 02 Build the wiki 03 Use the wiki 04 Agent harness 05 AI in your software 06 Review
  1. Step 1: Find where AI fits, and where it does not

    We work with you to find the decisions and routine tasks where AI can genuinely help, and we are honest about where it will not. Workshops test ideas before you commit.

    What you get

    A short, practical AI roadmap with the risks spelled out.

  2. Step 2: Use AI to build your LLM wiki

    An LLM wiki is a company knowledge base written for both people and AI. We use AI to read your source documents and draft a structured, linked set of notes in plain Markdown files, with version history.

    Every note points back to the document it came from, and is marked as a fact, a hypothesis, a decision or a recommendation. People review changes before they are accepted.

    What you get

    Your company knowledge in one place, in plain files you keep, with a source for every claim.

  3. Step 3: Put the wiki to work

    The wiki becomes the starting point for people and AI tools alike. Before answering a question or starting a task, they read the relevant notes, so answers are grounded in your own sources instead of guesswork.

    New documents are picked up as they arrive, so the wiki keeps up with the business.

    What you get

    Faster answers your team can check, and less knowledge stuck in one person's head.

  4. Step 4: Build a custom agent harness

    We design a custom harness for each client's needs: a team of AI agents with defined roles that read the wiki first, work through tracked tasks and write up what they did, with sources. We run our own business on one.

    It has hard gates. A person says yes before anything is sent, spent, published or changed in production.

    What you get

    AI that does real work inside clear limits, with a record of every step.

  5. Step 5: Build AI into your software and data

    Where it fits, we build machine learning, computer vision and language tools into your applications, such as flagging early signs that equipment needs maintenance from sensor data, or counting people in video.

    We are model-agnostic and use whichever model is best for the purpose: open-source models running on your own servers where data sovereignty matters, or leading models from OpenAI, Anthropic and Google under business terms that do not allow your data to be used for training.

    What you get

    AI inside the systems your team already uses, not another tool on the side.

  6. Step 6: Review, measure and improve

    Before go-live we agree a set of test questions and tasks with you and measure how often the AI gets them right. AI output is checked against its sources, we keep a person in the loop for decisions that matter, and we re-run the same tests whenever a model or prompt changes.

    What you get

    AI output you can check, measured against tests agreed with you.

Predictive analytics

Predictive maintenance and analytics, from your sensor data.

We design and build predictive maintenance and predictive analytics: models that learn what normal looks like, flag when things drift, and help your team see trouble coming, so people can plan instead of react.

Engineering and industrial IoT

Predictive maintenance

We design and build predictive maintenance models that learn the normal behaviour of equipment from its sensor data, such as temperatures and loads, flag drift and anomalies early, and estimate when equipment is likely to need attention where the data supports it, so maintenance can be planned instead of rushed.

Our experience: we have assessed predictive approaches for rail condition monitoring, including early modelling in MATLAB, and we built the data collection, dashboards and automated fault alerts that such models depend on. Synapse, our condition-monitoring venture, builds on that experience.

About Synapse
In development

FermentSense

FermentSense is a Jundra venture in development: a clip-on monitor designed to let small cideries, breweries and meaderies know when a tank may need checking.

Visit FermentSense

How we build predictive models

  1. Step 1: Get the right data

    We start with the question, then check the data can answer it: which sensors, how often, and what records of real outcomes exist. If the data is missing, we design a way to collect it.

  2. Step 2: Learn what normal looks like

    We build a baseline for each machine or process, including daily and seasonal patterns, before calling anything unusual.

  3. Step 3: Build the models

    We start simple, with thresholds and statistical trends, and move to machine learning where it does better.

  4. Step 4: Check against real outcomes

    We test predictions against what actually happened, such as maintenance records, and show you how often the model is right and wrong before anyone relies on it. We agree with you how many alerts a week your team can act on, and tune the model to that, so alerts lead to action rather than being ignored.

  5. Step 5: Run it at the edge or in the cloud

    The model can run on the device when it has to react quickly or work offline, or in the cloud when it needs the full history. Alerts go to the dashboards and tools your team already uses.

  6. Step 6: Monitor and retrain

    Equipment, processes and seasons change, so, as part of ongoing support, we watch the model's accuracy and retrain it when it drifts. People decide what to do about an alert.

Start with one asset. A first step on one machine or asset type, with the scope and timeframe agreed in the proposal. We check your sensor data and maintenance records, learn what normal looks like, and back-test against what actually happened.

What you get: a data-readiness report, a working baseline model, a back-test showing how often it would have caught real issues and how often it would have raised false alarms, the alert volume it would produce, and a go/no-go recommendation for a wider rollout.

Proof

Where we use it today.

Our own operations, machine learning for anomaly detection in rail condition monitoring, and a computer vision prototype with Canberra Racecourse.

How we run Jundra

Our own LLM wiki and agent team

We run Jundra on the approach described here. Our company knowledge lives in an LLM wiki, and a team of AI agents with defined roles reads it before acting.

Every change to the wiki is tracked in version history, so a person can see and undo it, and nothing is sent, spent or published without a human yes. LLM wikis and agent harnesses are new services for clients; the proof so far is our own use.

See the steps
Machine learning in rail

Sydney Trains

Since 2017, our Technical Director, Ali Khorsandian, has designed and developed the Sydney Trains condition monitoring system, including machine learning for anomaly detection on sensor data.

About our team
Computer vision

Canberra Racecourse

Canberra Racecourse wanted to know whether its existing security cameras could count the people attending its events. We reviewed the camera system and layout, then built a prototype that applied AI models to the camera feeds to count attendees in VIP rooms, and at entrances and exits by their direction of movement across a virtual line.

The prototype showed the existing cameras could be used for people counting, designed with privacy in mind.

Research and development. IntelliGut: our connected-health research and development venture (R&D), where we design our own sensor hardware and software.

How we design sensors

What you get

AI with sources, limits and a record.

Depending on what you need.

  • AI roadmap and workshops
    Where AI fits your business, where it does not, and the risks.
  • LLM wiki
    A maintained company knowledge base in plain Markdown files, with sources and version history.
  • Custom agent harness
    Designed for your needs: AI agents with defined roles, tracked tasks and human approval gates.
  • Automated routine work
    Repetitive, time-consuming tasks taken off your team.
  • AI inside your software
    Machine learning and language tools built into your applications.
  • Computer vision
    AI models that detect and count people and objects in images and video, designed with privacy in mind. We prototyped people counting with Canberra Racecourse's existing security cameras.
  • Predictive maintenance and analytics
    Models that learn normal behaviour from sensor data, flag drift and anomalies early, and help your team plan maintenance before things fail.
Working with us

What you can count on.

You own the work

Everything we create for you, handed over into accounts you own. Open-source and third-party parts keep their own licences.

60-day defect fixes

We fix defects in our work for 60 days after delivery, at no charge, on top of your rights under the Australian Consumer Law.

Replies in one business day

Plus maintenance and support contracts to fit your needs and budget.

Security built in

Multi-factor authentication, code review, vulnerability scanning, a secrets manager and backups, with penetration testing by independent specialists for systems that need it.

Your data, your rules

Never put into free or consumer AI tools. Open-source models on your own servers, or commercial AI services under business terms that do not allow your data to be used for training.

Insured and prequalified

Professional indemnity, public liability and products liability insurance held. Prequalified supplier on the NSW Government ICT Services Scheme (SCM0020).

Common questions

Questions we get asked.

What is an LLM wiki?

A company knowledge base written so that both people and AI can use it. It is plain text files with links, a source for every claim and a full history of changes.

Do we have to replace our existing systems?

No. The wiki is built from the documents you already have, and AI is added to the software you already use.

Will AI send emails or make changes on its own?

Not in the way we set things up. A person approves anything that is sent, spent, published or changed in production.

What about our data and privacy?

We never put your data into free or consumer AI tools. Where data sovereignty matters, we run open-source models on your own servers, on premises. Where you want a commercial provider such as OpenAI, Anthropic or Google, we use their business services under terms that do not allow your data to be used for training, and we tell you which providers will process your data and where. Before we start, we agree with you where your data is stored and which services may process it, in line with Australia's Privacy Act and your own data rules.

How does an AI project start?

With a conversation and a written proposal. If you accept it, the next stage is a paid MVP that proves the idea on your own documents or data, with a fixed scope, timeframe and deliverables agreed in the proposal, so you can decide whether to continue once it is done.

Which AI models do you use?

Whichever is best for the job. We are model-agnostic: open-source models on your own servers, or leading models from OpenAI, Anthropic and Google under business terms that do not allow your data to be used for training, chosen to suit the task and your data rules. Because your knowledge stays in plain files you keep, the model can change later. When it does, we re-run the agreed tests first.

Do you support AI systems after they go live?

Yes. We reply to support requests within one business day. If you need more, we offer maintenance and support contracts negotiated to fit your needs and budget, as we do for Sydney Trains.

Who owns the work?

You do. You own the work we create for you and you pay for: the code, designs, trained models and documentation. We hand it over into accounts you own, not ours. Open-source components and third-party or commercial AI models stay under their own licences, and any tools we had before your project are licensed to you for use with the work. Your proposal lists both. Every project includes a 60-day defect-fix period after delivery, in which we fix defects in our work at no charge. This is in addition to your rights under the Australian Consumer Law.

What if the person who built it is unavailable?

You are not dependent on one person. Your code, documentation and accounts are in your name. Every handover includes the source code, architecture notes, a runbook for running and recovering the system, and the access details, handed into your own accounts, so another engineer, ours or yours, can pick it up.

Is this right for us?

Practical AI, with people in charge. It is a good fit if:

  • Your team spends time searching for information that should be easy to find.
  • Important knowledge lives in a few people's heads or inboxes.
  • You want AI to take on routine work, but with clear limits and a record of what it did.
  • You have sensor or operational data and want to find patterns in it, or spot problems earlier.

It is probably not the right fit if:

  • You want AI to make important decisions with nobody checking. We design for a person in the loop.
  • You are after a chatbot for your website only.

Other capabilities

Tell us what you are trying to solve.

Email us a few lines about the problem. We reply within one business day, from Sydney, Australia.

Email admin@jundra.com