Lepton · Reality Kernel programmeProduct vision · PRD companion · 2026·06·25

Network Access Platform

A project is a
document,
not a deployment.

SmartProject proved the shape: a live BharatNet PMO that is, underneath, a generic engine in a fiber skin. We paid to hand-build it once, for one vertical. This is the platform that builds the next one — and every one after — from configuration. An ontology, a workflow, gates, screens, rollups: declare them, and a SmartProject-class program appears.

Config-drivenOffline-first Reality Kernel ontologyDynamic workflow engine Web + phone SDUIMulti-tenant
01The generator

One declarative bundle. Every surface, generated.

The configurator authors a program bundle. The platform instantiates a whole multi-actor system from it — and changing the program means editing the document, not shipping code.

Fig. 01config in · a complete program out
program.bundle ontology.yamllifecycle.yaml workflows/screens/ gating.yamlrollups.yaml SmartProjects Platform ontology · workflow · gating SDUI · rollups · federation interprets the bundle → Phone app · field crew offline capture · SDUI screens Web app · managers grids · inbox · approvals · forms Dashboards · executives rollups over the ontology API · agents · integrations MCP / OpenAPI nodes · SSO
02The stack

Six declarative layers — each already built, badly factored, somewhere.

We are not inventing these. We are naming and re-factoring a pattern that already exists across SmartProject, the SMP engine, and FiberSure.

L1

Ontology — the nouns

Entities, typed traits (type · unit · enum · control), links, spatial containment, parties.

Reality Kernel · SmartProject NodeAttributes generalized
L2

Workflow — the verbs

Task-type DAGs · 5 node kinds incl. SCREEN · status state-machine · typed ports · offline sub-flows.

SMP × wfb converged engine
L3

Gating & approvals

Module × role × verb · status→role→order approval chains · scope predicates (action-on-me, partner, geo).

StatusRoleApprovalMapping as config
L4

Experience — SDUI

Web grids/inbox/forms + phone capture screens from one schema · shared renderer state online/offline.

FiberSure renderer, de-verticalized
L5

Insight — derived

Every metric = an aggregation over the ontology, declared in config. No bespoke reports.

SUM(leaf attr) up the tree
L6

Federation — the edges

SSO across facets · telemetry as event streams · doc stores · MCP/OpenAPI nodes · agents.

AppLauncher → one identity, one graph
03The artifact

What a configurator actually ships.

# program.bundle — versioned, content-hashed, tenant-scoped
ontology:     # entity types + typed traits + containment
  node: { tree: State›District›Block›GP }
  traits: [ rkm:number/KM, class:enum(Green,Brown) ]
lifecycle:    [ Scope, HOTO, Plan, Survey, Build, Ops ]
workflows:
  Construction:
    statuses: [ Pending*, YTS, WIP, Invoiceable ]
    nodes:    [ SCREEN, HUMAN_TASK, ASYNC ]
    offlineCapable: true
gating:
  approval: Construction › WIP › role=ZM › order=2
  modules:  { Task: [read,write,edit] }
screens:      [ survey.capture, approve.modal ]
rollups:      SUM(rkm_completed) by stage, geo
integrations: [ hdd.telemetry, sharepoint, sso ]
theme:        vinxi

It is a document, versioned like code

DRAFT → PUBLISHED → DEPRECATED, content-hashed so a device knows exactly which bytes it cached — no phantom "update available" loop.

Typed, not stringly-typed

Traits and screen payloads carry real Kernel types, validated at publish time by an edge checker — not $node[...] string lookups that fail at runtime.

The acceptance test

SmartProject/NCC must be expressible as one of these bundles with zero bespoke code, reproducing the live behaviour we captured. If it can't, the layer isn't generic enough yet.

Changing the program = editing the document

Move a gate, add a trait, retune a rollup — published, not deployed.

04One definition, two profiles

The same workflow runs in the cloud and in a pocket with no signal.

The decisive, expensive bet: a single definition, two execution profiles, one renderer state — so a crew works a sub-flow fully disconnected and syncs back clean.

Fig. 04server profile · device profile · renderer parity
One workflow definition typed nodes · ports · status machine Server profile Temporal · Spark · Postgres — durable, parallel • topo-sort fan-out · retries · DLQ • partitioned run / node lineage • HUMAN_TASK approvals · MCP / OpenAPI nodes • encrypt-at-write secrets · org budgets Device profile on-device interpreter — offline sub-flows • runs SCREEN / LOCAL nodes disconnected • content-hash cache · min-app-version gate • UUID-idempotent capture · topo replay • same RunnerState → renderer parity one schema → identical screens whether online or off · synced exactly once, no dupes
05The proof of generality

Two programs. One engine. Zero vertical code.

Generality isn't a claim — it's a test. Re-derive the fiber program we reverse-engineered, then stand up a wholly different one from the same engine and a different bundle.

Bundle A · validated by revenue

BharatNet fiber rollout

Ontology
State›District›Block›GP · Green/Brown · UG/OH
Lifecycle
Scope → HOTO → Plan → Survey → Build → Ops
Workflow
Construction · Survey · HOTO · *_rkm traits
Gating
AM → ZM → QC → PH
Rollup
Σ rkm_completed by stage / district
Capture
fiber depth · videography · RTK
same engine
Bundle B · a different world

Gas pipeline construction

Ontology
Region›Spread›Section›Weld · onshore/offshore
Lifecycle
ROW → Trench → Weld → Hydro-test → Commission
Workflow
Welding · NDT · joints/km traits
Gating
Foreman → QC/NDT → Engineer → Client
Rollup
Σ welds, test pass-rate by spread
Capture
weld X-ray photo · gauge OCR
If both run on one engine with no bespoke code, the platform is real — and "carry forward SmartProject" becomes a migration, not a rewrite.
06Outcome-first roadmap

Six epics, each shippable and de-risking.

A
Ontology + bundle MVP

A project authored as a document, instantiating a live entity tree.

B
Engine · gating · approvals

A task moving Pending→AM→ZM→QC→PH with a real audit trail.

C
Config-driven web UI

SmartProject's dashboard + task list, regenerated from config.

D
SCREEN + offline phone

A crew capturing offline, syncing clean. The expensive bet.

E
Two verticals, one engine

Fiber + a non-fiber program, zero vertical code. The proof.

F
Federation · agents · hardening

Telemetry, MCP nodes, SSO, secret-safe, multi-tenant.

Each epic declares: what the CEO sees · what presales demos · what's production-deliverable · what it de-risks.