Platform · core IP · MVP in production on AWS
Verify before it acts. Rehearse before it runs.
Two layers that sit on top of whatever agent stack you already run. Nikash decides whether an agent's output is safe to act on. Adhva lets you simulate a plan against a model of the business before anyone runs it.
Where it sits
A layer at the action boundary — not another agent framework.
Orchestration frameworks give you control flow and role-play. None of them knows what your business is, or whether an output is safe to act on. We wrap the boundary where an agent's output becomes a filing, a payment or a write — no rewrite of your stack.
↺ outcomes flow back to the gate days or weeks later
Nikash · verification & outcome learning
Nothing crosses the line until it has been rubbed against the stone.
Nikaṣa is the touchstone — the black stone you rub gold against to see whether it is real. Gate verifies, blocks, escalates and attests before an action. Loop learns from what the real world said afterwards.
The AI proposes claims. It never evaluates a check.
Checks are deterministic code or a solver. An LLM may draft a check — but at runtime it does not decide compliance. That is what makes an output defensible in front of a regulator.
1 · Pick what the agent got wrong
Everything consistent
2 · Agent's claims
SHP-88213 · Bill of Entry- hs_code
- 8471.30.10
- goods
- Portable laptop computers, 14-inch, with charger
- invoice_value
- USD 48,200
- duty_payable
- ₹11,22,867
- incoterm
- CIF / CIF / CIF
- coo_issued
- 2026-06-02
- arrival_date
- 2026-09-21
- licence
- —
Illustrative data and rates. Checks are deterministic functions — the model never judges.
3 · Deterministic checks · customs.in.import@2026.03
- Importer code is well-formed
- HS code consistent with goods
- Duty arithmetic reconciles
- Incoterms agree across documents
- Certificate of origin valid on arrival
- Licence present for restricted goods
Verdict appears here — pass, block or escalate — with a signed attestation.
Gate — the pre-action half
- Claim
- An atomic assertion the agent makes — subject, value, unit, as-of date, provenance. Not prose.
- Evidence
- A pointer to the exact source span: document, version, page, extracted value.
- Fact
- A trusted, time-versioned value from a system of record — tariff schedule, formulary, sanctions list.
- Check
- A pure, deterministic function of claims and facts. Individually testable, side-effect free.
- Verdict
- Pass, fail, escalate or inconclusive — with a reason code and the exact inputs it saw.
- Attestation
- A signed, immutable record of action, claims, evidence, verdicts and approver. The audit artefact.
Loop — the post-action half
- 01
Trace
Every decision point, claim, verdict, cost and latency from one run is recorded.
- 02
Correlate
A business key — Bill of Entry no., claim ID, well ID — lets a late outcome find its trace.
- 03
Outcome
Cleared, queried, rejected, charged back — arriving hours to weeks later.
- 04
Improve
Reward is computed, credit assigned, and policies roll out shadow → canary → ramp.
Deliberate v1 scope: Loop optimises the decisions around the model — routers, thresholds, escalation rules — rather than fine-tuning it. Cheaper, safer, and it works when your model is a black box behind an API.
A domain pack, as a domain expert reads it
checks:
- id: duty_arithmetic
severity: block
assert: |
abs(claim.duty_payable
- (shipment.assessable_value * tariff.bcd_rate
+ shipment.assessable_value * tariff.igst_rate)) <= 1.00
explain: "Computed duty differs from declared duty by more than Rs 1."
- id: incoterm_agreement
severity: block
assert: all_equal(invoice.incoterm, po.incoterm, bill_of_lading.incoterm)
gates:
- action: file_bill_of_entry
require: all(severity == block) == pass
on_escalate: { route_to: customs_broker_queue, sla: 4h }
attest: true
outcomes:
- name: customs_disposition
correlation_key: bill_of_entry_no
expect_within: 10d
values: [cleared, query_raised, rejected, seized]Packs are versioned and pinned per tenant — a regulation change is a pack release, not a code deploy. Every reference-data lookup is as_of a date.
Adhva · world-model runtime
Stop writing graphs of prompts. Declare the world.
Entities, the states they can be in, the moves that are legal, what must never be true, and how long things actually take. Agents then act, plan and rehearse inside it — and one model gives you a validator, a planner, a simulator and a test-case generator.
Our mark is the damaru: two cones meeting at a single point. It is what a world model does — compress what is, expand what could be. The bindu at the waist is the latent point.
Goal
clear_before_demurrage
Shipment SHP-88213, two containers, 6 days out at sea.
95%
cleared in free time
1.5d
median clearance
3.0d
P90 clearance
$22
expected demurrage
action file_bill_of_entry:
duration: lognormal(mu: -0.4, sigma: 0.5, unit: days)
failure_modes:
- query_raised: p: 0.03 # claims gated by Nikash
- rejected: p: 0.004
event vessel_delayed:
rate: poisson(lambda: 0.08/day)
goal clear_before_demurrage:
before: shipment.free_time_ends # 4 daysIllustrative parameters — in production, durations are fitted from your own traces.
- Entity
- Typed things with a lifecycle — Shipment, Container, Well, Claim.
- State machine
- The legal states of each entity, and the transitions between them.
- Action
- Preconditions, effects, cost, a fitted duration distribution, and failure modes.
- Event
- Exogenous change from the real world — a vessel delay, a price move.
- Invariant
- A predicate that must hold in every reachable state. Violation is a bug in the plan.
- Reconciler
- Continuously diffs expected against observed reality. Divergence is the alarm.
world: freight.crossborder
version: 2026.03
entity Shipment:
states: [booked, in_transit, arrived, under_clearance, cleared, held]
invariants:
- name: no_clearance_without_boe
expr: shipment.state == 'under_clearance'
implies exists(doc: type == 'bill_of_entry')
action file_bill_of_entry:
pre: [shipment.state == 'arrived', exists(doc: type == 'invoice')]
eff: [shipment.state := 'under_clearance']
duration: lognormal(mu: 1.4, sigma: 0.6, unit: days) # fitted from traces
failure_modes:
- query_raised: p: 0.11 -> shipment.state := 'held'
goal clear_before_demurrage:
achieve: shipment.state == 'cleared'
before: shipment.free_time_ends
minimise: [cost.money, cost.human_minutes, risk.hold_probability]The LLM is a proposal distribution, not the decision-maker: it suggests candidate actions, and MCTS or beam search scores them by simulated rollout. Preconditions are re-checked at execution — the world moves.
What is new
Industry-specific, auditable, already running.
Industry-specific by design
Built around one vertical's documents, rules and failure modes — not a general toolkit.
The AI proposes. It never judges.
Checks are deterministic code or a solver. That is what makes an output defensible in front of a regulator.
Auditable by default
Every gated decision leaves a signed trail a regulator or client can inspect.
Sits on top of your stack
Wraps the action boundary of whichever agent framework you run, or a bespoke agent — no rewrite.
Rules pinned to a date
Reference data is bitemporal: you're checked against the rule that applied then, not today's.
Already in production
MVP runs on AWS. Enhanced GPU version planned on Google Cloud.
Verticals
Same runtime, different world file.
Built around one vertical's documents, rules and failure modes at a time — starting where an AI output becomes an action and the answer arrives days later.
Flagship vertical
Freight forwarding, customs & trade documentation
Next
Oil & gas
Focus
Banking & fintech
Focus
Healthcare
Curious how this is researched? Read about our research →
Have an agent whose output becomes an action?
We are onboarding design partners in freight forwarding and customs first, then oil & gas. Bring us a workflow; we'll show you what the gate would have blocked.