Technology & AI

Custom applications, workflow automation, local and private AI, model adaptation and integration with the systems already in place.

When people call us about this

We build technology around the work that needs to be done.

What people usually describe on a first call:

  • The same information is typed into two systems because neither talks to the other.
  • A vendor is proposing something and nobody in the room can tell whether it is the right thing.
  • The work is repetitive enough to automate and specific enough that nothing off the shelf fits.
  • AI would help, and the material cannot leave the building.

What we provide

  • Custom applications
  • Workflow automation
  • Custom AI tools
  • Local and private AI systems
  • Model selection and deployment
  • Local inference
  • LoRA and QLoRA training, and model adaptation
  • Structured generation and schema enforcement
  • Knowledge and document systems
  • AI-assisted education and training tools
  • Integration between existing systems
  • Technology assessment and vendor evaluation

Something we built

TLC — Teacher's Lesson Creator.

TLC turns the decisions a teacher has already made — the topic, the grade, the length of the period — into a complete lesson: objectives, a sequence, an assessment, an answer key and the materials list. It was built for the Gemma 4 Good Hackathon, run by Kaggle and Google DeepMind, which required a working demo, a public repository and a technical write-up. All three are linked further down this page.

Two model adapters do the writing, and they both work on every phase rather than one drafting and the other editing. Hunter owns structure and rigor. Christine owns depth and engagement. What combines them at the end is not a model asked to be tactful about two drafts — it is ordinary code with fixed rules about who owns which field, which is why the same inputs produce the same lesson.

  1. Build

    Both adapters see the same teacher input and the same uploaded source, and each writes a scaffold. In parallel, so neither is anchored to the other's first idea.

    Hunter scaffold
    Christine scaffold

  2. Review

    One pass over both scaffolds together, which is where disagreements between them get flagged.

    review report

  3. Package

    Both write again, in parallel, this time with the review in front of them.

    Hunter package
    Christine package

  4. Merge

    Code, not a model. A field has one owner, and a missing required field throws rather than being quietly filled in.

    Hunter
    objective, lesson steps, assessment, answer key, time blocks, standards alignment
    Christine
    engagement, demo, teacher notes, discussion prompts, differentiation, vocabulary, misconceptions, enrichment
    Both
    materials and homework, unioned and de-duplicated by name
Every one of those model calls emits structured output against a schema. A failure is retried once with the error appended; a second failure fails the run rather than rendering something that is not a lesson.

Both adapters were trained with QLoRA on google/gemma-4-e4b-it — supervised fine-tuning over an NF4 base with bf16 compute, LoRA rank 16, alpha 32, dropout 0.05. The training data is described by the authors as roughly 250 schema-validated outputs generated by Gemma 4 31B acting as a teacher model across a K-12 topic and grade matrix. Both adapters are published under MIT.

Output is not trusted because it looks right. Vocabulary and misconception claims are checked against the Wikipedia and Wikidata APIs, and a contradiction sends the lesson back to be regenerated. Every piece of content is also labelled with where it came from — traced to the teacher's own source, shaped by it, or generated outright — so a teacher can see which parts to read twice.

On where it runs, precisely: the adapters are the published local-inference path, converted to GGUF and served through llama.cpp with both loaded so the worker can swap between them per request. The hosted demo runs against cloud Gemma 4 31B.

Typical situations

An organization whose staff spent several hours a week hunting for documents that existed, were current, and could not be found.

A training provider that wanted AI in its course development and needed to know which parts it could sensibly be trusted with.

A company being sold a platform that would have solved a problem it did not have.

How the work runs

We start with the work, not the technology. What is the task, who does it, how long does it take and where does it go wrong? Often the process needs fixing before anything is automated, because automating a broken process makes it fail faster.

Where technology is the right answer we build the smallest thing that solves the problem and hand it over with documentation, including what it will not do.

What you end up with

  • Something that runs, with the documentation to keep it running
  • A clear statement of what the system does not do
  • Data that stays where it is supposed to stay
  • No dependency on us to operate it

Read it yourself

Written down

Take these with you

Reading

Is this what you are dealing with?

Describe it in your own words. We will tell you honestly whether it is something we should be doing.

Start a conversation