Skip to content
RebellionTechGet Audit
What we build

Six layers, engineered in-house, diagrammed end to end

This page is the technical argument, and it includes a retriever running live on this site's own content so you can test the claims rather than take them. If you want to know exactly what you would be paying for, and exactly where most AI projects fall apart, it is all here.

6
Layers owned
4
Core pipelines
Live
Working demo
8
Failure modes
Layer by layer

What each layer actually involves

The claims on the home page, with the engineering underneath them.

01

Custom Model Development

Models built for your problem, not adapted to it.

Architectures chosen and trained against your data and your failure modes. Where a general model genuinely wins, we say so and use it — but the decision is made on evidence, not on convenience.

Fine-tuningCustom ArchitecturesDistillation
In practice
  • Baseline first: we measure what an off-the-shelf model already achieves before proposing anything custom.
  • Training runs are versioned, logged and reproducible — you get the recipe, not just the weights.
  • Distillation and quantisation where latency or unit cost is the binding constraint.
02

System Architecture

The part everyone skips, and the part that decides whether it works.

Routing, state, tool execution, failure handling, cost control. Designed for the load you will actually have, with no black boxes and no component you cannot replace.

OrchestrationState DesignCost Modelling
In practice
  • Every external call has a timeout, a retry policy and a defined degraded state.
  • Cost per request is a design constraint from day one, not a bill you discover in month three.
  • Components are swappable: changing model provider should be a config change, not a rewrite.
03

Retrieval & Knowledge Engineering

Getting the right context in front of the model, every time.

Hybrid retrieval, reranking, chunking strategies tuned to your documents, and a domain ontology that encodes how your field actually reasons. Most "hallucination" problems are retrieval problems.

Hybrid SearchRerankingOntologies
In practice
  • Chunking and embedding strategy is chosen by measurement on your corpus, not by blog-post default.
  • Access control lives in the retrieval layer, so a user can never be shown a document they cannot see.
  • Every answer carries citations back to source spans — unsupported claims are blocked, not softened.
04

Multi-Agent Orchestration

Many specialists, one chain of command.

Agent systems that stay debuggable: one orchestrator owns control flow, specialists never call each other directly, and every decision leaves a trace you can replay.

PlanningTool UseTraceability
In practice
  • Bounded autonomy: agents get an explicit budget of steps, tools and spend.
  • A critic agent must sign off before anything reaches the user or writes to a system of record.
  • Full execution traces, so a bad answer can be reproduced and diagnosed months later.
05

Evaluation, Safety & Red-Teaming

We try to break it before your users do.

Benchmarks built from your real cases, adversarial suites, slice-level scoring, and hard gates in the deploy pipeline. If it cannot pass, it does not ship.

Eval HarnessesAdversarial TestingQuality Gates
In practice
  • Evaluation sets are drawn from your real traffic and edge cases, not from public benchmarks.
  • Scores are reported per slice — aggregate accuracy hides the failures that actually hurt.
  • Refusal behaviour is tested as rigorously as correctness. Knowing when to stop is a feature.
06

Production & MLOps

Running it is most of the work.

Deployment, observability, drift detection and retraining loops. Shadow and canary releases, instant rollback, and dashboards that tell you what changed and why.

ObservabilityDrift DetectionRetraining
In practice
  • New versions run in shadow against live traffic before anyone depends on them.
  • Drift alerts are tied to business metrics, not just model statistics.
  • Rollback is one command, and it is tested on a schedule rather than assumed to work.
Retrieval

How a question becomes a cited answer

Almost every hallucination we are asked to fix turns out to be a retrieval failure, not a model failure. The model answered faithfully — it was handed the wrong context.

Architecture

Retrieval and grounding pipeline

Understandquery → intent01• Normalise, expand, and classify• Reject what we cannot answerRetrievehybrid search02• Dense vectors + keyword (BM25)• Metadata filters, access rulesRerankprecision pass03• Cross-encoder scoring• Drop weak evidence entirelyAssemblebuild the context04• Budget tokens by value• Order by relevance, not recencyGenerategrounded answer05• Domain-tuned model• Structured, typed outputVerifyprove it, or refuse06• Claim-to-source checking• Abstain when unsupportedUNSUPPORTED → REGENERATE OR ABSTAIN
Understand & fetchSelect & composeAnswerProve
Stage 06 is the one that separates a demo from a system. If a claim cannot be traced to a retrieved span, the answer is regenerated or withheld — it is never shipped with a confident tone and no evidence.
Chunking is measured

Chunk size and overlap are tuned on your corpus against a labelled question set. The default from a tutorial is almost never right for legal text and contact-centre transcripts at the same time.

Hybrid beats pure vector

Dense embeddings miss exact identifiers — part numbers, case codes, names. Keyword search catches them. Running both and fusing the results consistently outperforms either alone.

Permissions live here

Filtering by entitlement at retrieval time means the model is never handed a document the user cannot see. Enforcing it in the prompt is not enforcement.

Running right now, in your browser

Do not take our word for it — interrogate the system

Everything above describes how we build retrieval. Rather than assert it, here is a working BM25 retriever indexed over this site's own content. Ask it something. Then ask it something it cannot know, and watch it decline instead of inventing an answer.

Loading the index…
No server, no model call

The index is built in your browser from static passages. Nothing you type leaves the page, and there is no API behind it to bill anyone.

Extractive on purpose

Answers are spans lifted from source text, never paraphrased. It is the strictest form of grounding, and it makes every citation checkable.

The gate is real

Refusal is not a scripted response to a magic word. It triggers when retrieved evidence fails a coverage threshold — the same rule we ship to clients.

Lexical, on purpose

A dense semantic layer was built for this and measured. On a corpus of 46 passages it made answers confidently wrong, so it was cut. Client systems run hybrid retrieval because their corpora are large enough to justify it.

Orchestration

Multi-agent systems that stay debuggable

Agents calling agents freely produces systems nobody can reason about and nobody can fix. We keep control flow in one place and make every decision replayable.

Architecture

Agent orchestration topology

Researchergathers evidenceAnalystreasons over itBuilderproduces the workCritictries to break itBUSOrchestratorowns control flow · assigns work · resolves conflictNO AGENT-TO-AGENT CALLSShared Memorystate across turnsGuardrailspolicy & limitsTool LayerAPIs, code, dataVerified Outputcited · typed · loggedREJECTED → REWORK
SpecialistsOrchestratorSupport servicesVerification
Specialists never address each other directly. Every message passes through the orchestrator, which means every run has a single ordered trace — and a bad output from three months ago can still be reproduced exactly.
Bounded autonomy

Each run gets an explicit budget: steps, tool calls, wall-clock time and spend. Exceeding any of them stops the run and reports, rather than quietly looping.

The critic has teeth

A separate evaluator must pass the output before it reaches a user or writes to a system of record. Rejection routes back to rework, not to a retry of the same prompt.

Tools are typed

Every tool has a schema, a permission scope and a dry-run mode. An agent cannot invent a call signature, and destructive actions require an explicit confirmation path.

Build loop

Training is a loop, not a launch

The interesting arrow in this diagram points backwards. What the system does in production is the raw material for the next round of curation.

Architecture

Data and training pipeline

01Collectraw signalSource auditRights & consent02Curatemake it usableClean, dedupeVersion the set03Labelteach the targetExpert + syntheticInter-rater checks04Trainfit the modelSweeps, not guessesFull run logs05Evaluatetry to break itHeld-out + adversarialSlice-level scores06Deployship behind gatesShadow, then canaryInstant rollbackPRODUCTION BEHAVIOUR → NEXT TRAINING SETQUALITY GATE
Data workTrainingEvaluationRelease
Nothing crosses from evaluation to deploy without clearing the quality gate, and nothing clears the gate on aggregate accuracy alone — the slices that matter to your business are scored separately and can each veto a release.
Datasets are versioned artefacts

Every training run names the exact dataset version it used. Reproducing a result six months later is a lookup, not an archaeology project.

Synthetic data is labelled as such

Generated examples are useful and are marked. Mixing them invisibly into a gold set is how teams end up measuring their own generator.

Rollback is rehearsed

Reverting to the previous model version is a single command, and we exercise it on a schedule. A rollback path that has never been run is a hypothesis.

A network, training, in your browser

Everyone says they train models. Watch one learn.

This is a neural network written from scratch — forward pass, backpropagation, Adam — running on your machine with no server involved. Pick a dataset, choose an architecture, and watch the decision boundary form. Then take the hidden layer away and watch it fail.

Initialising weights…
Real backpropagation

Weights are initialised with He or Xavier scaling, gradients come from the chain rule, and Adam applies them. No recorded animation, no precomputed frames.

Remove the hidden layer

Press minus until no layers remain, then train on XOR. It plateaus near chance, because a linear model cannot separate that data. That failure is the proof the maths is real.

Capacity is a decision

Four units cannot fit the spiral however long you wait. Sixteen can. Choosing capacity against a problem is exactly the judgement a custom build is paying for.

To be clear about scale. This is a few hundred parameters on two input features, which is what can be drawn honestly in two dimensions. Production work runs many orders of magnitude larger on real data. The mechanics on display here — initialisation, gradients, optimiser, capacity, the loss curve flattening — are the same ones that decide whether that larger work succeeds.

Guardrails

Nothing ships on the model’s say-so

Four independent checks run on every candidate output. Any one of them can veto a release, and the veto carries a reason rather than a silent retry.

Architecture

Evaluation and release gate

Candidate outputnot yet trustedALL FOUR RUN IN PARALLELGroundednessclaim → source spanEvery assertion tracedPolicypermitted & entitledScope and access rulesQualityscored per sliceNo hiding behind averagesSafetyadversarial probesRed-team suite, every buildRelease GateANY CHECK CAN VETOShipcited · logged · reversibleBlock & reworkwith the reason attachedREGENERATE OR ESCALATE
GroundednessPolicyQualitySafety
The checks run in parallel, so adding one costs latency but not architecture. The dashed return path matters as much as the gate itself: a blocked output goes back with its failure reason attached, which is what makes the next attempt better rather than merely different.
Refusal is a passing grade

An output that declines to answer because the evidence is not there has behaved correctly. We score refusal quality deliberately, because a system that never abstains is a system that confabulates.

Checks are independent

No check can be satisfied by the component it is checking. Groundedness is verified against retrieved spans, not against the model asserting that it was careful.

Vetoes are logged

Every block is recorded with its reason and inputs. That log becomes the adversarial set for the next training round, so failures compound into improvement.

Failure analysis

The section most proposals leave out

Every architecture audit we write contains this: where the system breaks, who feels it, and what it costs. Here are eight failures we design against on every build. Pick one.

Quiet · Degrades without alerting anyoneOriginates in Knowledge

Retrieval returns the wrong context

The retriever surfaces passages that are topically close but do not actually answer the question. The model then answers faithfully from bad evidence.

Blast radius
InterfaceOrchestrationReasoning◉ KnowledgeData
Why it is worse than it sounds

This reads as a hallucinating model, so teams spend months tuning prompts and swapping providers. The defect is one layer down and no amount of prompt work reaches it.

How we detect it

Coverage scoring on retrieved spans, plus a standing eval set drawn from real queries. A drop in retrieval precision shows up before users complain.

How we design against it

Hybrid retrieval with reranking, chunking tuned on your corpus, and a gate that withholds an answer when evidence coverage falls below threshold.

Boundaries

Things we will not do

Constraints are easier to verify than promises. Hold us to these.

Ship something we cannot explain

If we cannot describe why the system produced a given output, it does not go live. That rules out some techniques that would otherwise score well.

Take a project that does not need us

If the audit says a SQL view and a scheduled report solves it, that is the recommendation. We would rather lose the contract than bill for theatre.

Build on data you do not have rights to

Provenance and consent are checked before ingestion. A model trained on data you cannot defend is a liability wearing the costume of an asset.

Promise a fixed price before the audit

A number quoted before we understand the data is either padded or wrong. We quote after phase 01, and then we hold to it.

Make leaving expensive

On build engagements everything transfers. No key escrow, no hosted component you cannot self-host, no clause that punishes you for walking.

Claim capabilities we have not tested

If a benchmark was not run on your data, we will not cite it at you. Vendor marketing numbers are not evidence about your problem.

Start here

Find out what you actually need
before you spend a dollar building it.

Send us the problem in whatever form you have it — a paragraph, a deck, a half-working prototype. You get a written architecture audit back in 72 hours.

A written read on what you are actually trying to build
The architecture we would use, and the two we rejected
Where this fails in production, and what that costs
A realistic budget range and timeline — or a reason not to start
Request the auditaurindesai@gmail.com

No discovery call required · No obligation · You keep the document either way