Skip to content
RebellionTechGet Audit
What we build

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

This page is the technical argument. 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
0
Black boxes
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.

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.

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.

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 rupee 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