Products · three on one platform

Three products on one platform, built in a fixed order.

Nimikh Core is the substrate: tenancy, identity, messaging, payments behind an adapter, offline capture, audit and export. EduOps, AgriOps and VisionEdge sit on top of it, each specified for an industry where the same operational problems repeat at every organisation. The order they are built in is fixed, and the conditions for moving from one to the next were settled before any code was written.

None of the three is available today. EduOps is in build, AgriOps is at the paid design-partner stage, and VisionEdge is validation only. There are no customers, no pilots and no case studies behind any of the three, and the status is the first thing on each product page.

System topology

Nimikh Core, underneath all three

A school, a feed mill and a distribution hub need very different software and almost identical plumbing. Core is that plumbing, specified once. It is not sold separately.

Topology · two tiersSpecification, not running
Tier 1 · The verticalsBuilt in this order
Published module interfaces

One deployable, many modules. A product reaches Core only through an interface Core publishes, and no module reads another module’s tables.

Tier 0 · The substrate

Nimikh Core, the reusable substrate

Specified, built with EduOps

Eight primitives, specified once and shared by all three products.

  1. 01Tenancy and identity
  2. 02Messaging with a consent ledger
  3. 03Payments behind an adapter
  4. 04Offline capture
  5. 05Append-only audit
  6. 06Import and export
  7. 07Bilingual interface
  8. 08Break-glass support access
Specification, not a running system. It shows how the products relate to Core as the technical requirements specify it; none of the tiers is available today.
Tier 0 · fixed primitives

Eight things Core has to do

Selected rather than exhaustive: these are the ones a buyer can check us on later. Each is written down as a specified behaviour, and none of them is a shipped feature.

  • P-01

    Tenancy and identity

    One installation serves many institutions, and the boundary between them is enforced by the database rather than by application code. Sign-in is phone-first with a one-time code, because a phone number is the identifier most staff actually have. Roles are assigned per scope, not per person.

    Isolation enforced by the database
  • P-02

    Messaging with a consent ledger

    One router across SMS, WhatsApp, in-app and email, with templates, a consent state recorded per recipient per channel, and a spend cap per tenant. Messaging is a cost centre with a ledger attached, not an unmetered send button.

    Consent per recipient, per channel
  • P-03

    Payments behind an adapter

    At least two gateway implementations plus a manual counter method, webhooks verified by signature and made idempotent, settlement files ingested and reconciled three ways with an exceptions queue for whatever does not match. The institution is the merchant of record throughout.

    The institution is merchant of record
  • P-04

    Offline capture

    Designated flows keep working with no network and sync afterwards without loss. The queue carries one write shape per flow, deliberately, so nothing else drifts into it.

    One write shape per flow
  • P-05

    Append-only audit

    Hash-chained, and writable only forwards. A record of what happened that can be altered afterwards is not a record of what happened.

    Hash-chained, writable only forwards
  • P-06

    Import and export

    Structured bulk import with a dry run before anything is written, and a self-serve full export of every record you gave us and every record we created for you, in open formats. Export is a shipped requirement rather than a sentence in a sales conversation.

    Dry run before anything is written
  • P-07

    Bilingual interface

    Bangla and English are the same system, set in the same type scale, with the optical corrections Bengali needs — not English strings translated into a layout that was measured for Latin script.

    Bangla and English, one type scale
  • P-08

    Break-glass support access

    Support access to a tenant’s data is explicit, time-boxed, notified and recorded. There is no standing key held by anyone here.

    Time-boxed, notified, recorded

Core is not finished either. It is built alongside the first EduOps release, which means the platform and the first product become real at the same time, or neither of them does.

Specifications and gates

The three products: specifications and gates

They are not three equals in a row. One is being built now. The second starts only if a paid discovery stage earns it, and the third is a measurement before it is a product — so the page is weighted the way the work is.

01 / EDUIn build

Nimikh EduOps

Education

The core job

Builds a school’s routine, dispatches a substitute teacher when one calls in sick, records attendance offline, and reconciles fees against the payment gateway’s own settlement report.

Capacity decision gate

The first release’s scope depends on a documented capacity decision taken at the end of month one.

Four engineers
Routine, substitution, attendance and collections ship together.
Two engineers
Collections move to a second release. The first ships as routine and register.
Morning dispatch · 07:10 to 08:00A designed workflow
07:1008:00 first bell

Now 07:3426 min left

The window the product is built around

  1. 07:12

    Absence reported

    A physics teacher’s absence arrives by WhatsApp and affects four periods. It can also arrive in the app, by phone call, or as planned leave.

    Four routes in
  2. Target ≤ 3 s

    Ranked substitutes, each with its reason

    Subject match, free period, fairness rotation, “14 of 22 this week”. The ranking is rules-based, not learned, and an exclusion shows why a candidate lost.

    Rules-based
  3. Before send

    Dispatch messages priced first

    Messages ৳ 7.20 across 13 parts, from a wallet holding ৳ 2,140.00 — shown before anything is sent, not after the bill.

    Wallet shown
  4. 08:00

    Resolved before the first bell

    The wireframe has six of seven periods covered at 07:34, and the seventh states the constraint that blocked it. Delivery is recorded per recipient, so there is a record of who covered what.

    Recorded
Suggestions
≤ 3 s target
Whole dispatch, overrides included
≤ 15 min target
A designed workflow drawn from the EduOps wireframes, not a customer screenshot. Names, times and amounts are illustrative; the 3-second and 15-minute figures are design targets, not measurements.
02 / AGRIDesign-partner stage

Nimikh AgriOps

Agriculture

The core job

Captures field data inside a shed with no signal, tracks a production batch from placement to close, and settles contract farmers against records both sides can read.

Design-partner gate
Starts if
Integrators and feed mills find the discovery work worth paying for.
Otherwise
It does not start. The gate is a measured one, not a date.
Offline capture queue · shed to settlementA designed workflow

In the shed, with no signal

  1. 01

    Captured one-handed

    Feed, mortality with a cause code, water and environment readings, weight sampling, medication and photographs. About forty seconds is the target.

    No network call
  2. 02

    Validated on the device

    The form does not need a signal to know whether what was entered is valid.

    Offline
  3. 03

    Held in a local queue

    Capture keeps working with no network at all for at least 72 hours. The queue carries one write shape, so nothing else can drift into it.

    One write shape

When the network returns

  1. 04

    Synced without loss

    Batch metrics sit on the device rather than arriving after the cycle ends, with threshold alerts while there is still something to do about them.

    Batch ledger
  2. 05

    A settlement the farmer can read

    A statement the contract farmer can read and dispute line by line, so the argument is about a number both sides can see.

    Line by line
Capture target
about 40 s
Offline retention
at least 72 h
Network calls in capture
zero
Specification, not measurement. Nothing here has run in a shed; the figures are design targets from the requirements document.
03 / VISIONValidation only

Nimikh VisionEdge

Security and video

The core job

Runs detection on a box at the site, sends events rather than video, and produces evidence a dispute can actually be settled with.

Measurement gate
Measured first
A 30-day shadow trial on the customer’s own cameras: detection runs, no alert is sent, and the site’s own baseline is the only number ever quoted for it.
If it is not earned
The product does not ship.
Edge-only event flow · camera to evidenceSpecification only

At the site

  1. 01

    Cameras the site already owns

    ONVIF or RTSP. Nimikh does not replace a camera and does not sell one.

    Existing cameras
  2. 02

    Detection on a box at the site

    A detection is filtered by class and validated over time before anyone is told. In shadow-trial mode it runs without raising an alert.

    Edge only

What leaves the site

  1. 03

    Events, not video

    Only events, metadata and short clips ever leave the site. Continuous video does not.

    Events only
  2. 04

    Evidence with a chain of custody

    Every export carries a hash and a chain-of-custody record. No role holds a permission to delete evidence.

    Hash + custody
Stopped recording is raised
within 15 min target
Shadow trial
30 days, no alert sent
Performance figures published
none
Specification, not measurement. No accuracy, false-alarm, bandwidth or camera-count figure is published for VisionEdge before it has been measured at a customer’s site.
Serial sequencing

Why they are built in this order, and what stops each one

Each line carries gates with thresholds written down in advance. A roadmap with no stopping conditions on it is a wish list, so these are published rather than explained later.

  1. 01

    Education first

    Three things line up there that do not line up in the other two: the problem is described in detail, the buyer is private and pays for their own software, and it is the work this team is closest to.

  2. 02

    Agriculture on paid design partners

    It follows on paid design partners rather than on free goodwill, and it starts only if the discovery stage earns it.

  3. 03

    Video last, validation only

    Its central claim is a measurement nobody here has taken yet, so it is a measurement before it is a product.

What kills a product line

A gate that fails twice kills or re-scopes the line it belongs to. The named kill triggers in the requirements document are these three.

  • Trigger ANo paid conversion at the pilot price.
  • Trigger BMore than 35% of the codebase becoming tenant-specific.
  • Trigger CA payback period beyond 14 months.

How a problem becomes a requirement

Start here

Which of these is your problem?

If one of the three describes a morning you recognise, tell us what actually happens on it, in your own words. If none of them does, we build custom systems as well, and we would rather say so than push you at a product that does not fit.