SmartProjects

SmartProjects is the works-execution component of the Network Access Platform — the config-driven generator (on the Reality Kernel) that turns a project from a deployment into a document. The platform reads the document; SmartProjects is the program it runs.

Open the visual one-pager →

Two halves of one bet. This page is the generation side — how a program is authored on the platform. Its client-side companion, The Everything App, is the single dynamic shell that runs the programs the platform generates.

The thesis

We reverse-engineered SmartProject — a live BharatNet construction PMO used by customers with thousands of crew on the ground — and found it is not a fiber product. It is a generic engine wearing a fiber skin. A “task type” is a trait schema plus a status state-machine; the approval chain is rows in a table; the dashboard is a rollup over a spatial ontology; the field app is config-driven capture. Customers paid for the fiber program, but what was built was a declarative program-execution engine — hand-coded once, for one vertical.

Generalized and built well, that engine is the Network Access Platform: a system where a new vertical is configuration, not code. Declare an ontology, a lifecycle, a workflow with gates and approvals, the web and phone UIs, and the rollups — and the platform produces a complete application for fiber, gas, power, water, roads, or any field-heavy infrastructure program. SmartProjects is its first program — works execution — and the proof the platform is real.

flowchart LR
  B["program.bundle<br/>ontology · workflow · gating<br/>screens · rollups · integrations"]
  B --> P{{"Network Access Platform"}}
  P --> Phone["Phone app<br/>field crew · offline capture"]
  P --> Web["Web app<br/>managers · inbox · approvals"]
  P --> Dash["Dashboards<br/>executives · rollups"]
  P --> API["API · agents<br/>MCP / OpenAPI · SSO"]

Why this is a small, evidenced bet

Signal	What it proves
SmartProject is live and paid for (MP + UK; 316 blocks / 22,896 GPs)	The shape of the product is validated by real money and real feet on the ground.
It is already meta-modelled in four config tables (`NodeAttributes`, `taskTypeAttributes`, `StatusRoleApprovalMapping`, `RoleModuleMapping`)	The generalization is small. We are re-factoring a pattern that already exists, not inventing one.
Two in-house workflow engines (SMP’s typed-port DAG + FiberSure/wfb’s SCREEN-node + offline subsystem) nearly meet	The runtime to power this largely exists already.
FiberSure’s KMP app is ~70% of the dynamic-shell vision for one vertical	The phone client is mostly built; it needs de-verticalizing, not inventing.

The expensive insight from SmartProject: the same config drives the field app, the approval inbox, the manager grids, and the executive dashboard. There is no separate reporting model — the executive number is SUM(leaf task attribute) rolled up the ontology. Get the config layer right and everything above it is derived.

The six declarative layers

A program is the composition of six layers. Each maps to machinery that already exists.

	Layer	What it declares	Maps to
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 · five node kinds incl. `SCREEN` · status state-machine · typed ports · offline sub-flows	The converged SMP × wfb engine
L3	Gating & approvals	Module × role × verb · status→role→order approval chains · scope predicates (action-on-me, partner, geography)	`StatusRoleApprovalMapping` as configuration
L4	Experience — SDUI	Web grids/inbox/forms + phone capture screens from one schema · shared renderer state online & offline	The FiberSure renderer, de-verticalized
L5	Insight — derived	Every metric is an aggregation over the ontology, declared in config — no bespoke reports	`SUM(leaf attribute)` up the containment tree
L6	Federation — the edges	SSO across facets · external telemetry as event streams · document stores · MCP/OpenAPI nodes · agents	`AppLauncher` SSO → one identity over one graph

A project is a document

The artifact a solution engineer ships is a versioned, content-hashed, tenant-scoped program bundle — not an app build.

program.bundle
  ontology.yaml      # entity types, typed traits, links, containment, parties
  lifecycle.yaml     # ordered stages (e.g. Scope → HOTO → Plan → Survey → Build → Ops)
  workflows/*.yaml   # task-type DAGs, node kinds, status machines, offlineCapable flags
  screens/*.yaml     # SDUI schemas — web grids/forms/inbox + phone capture, with bindings
  gating.yaml        # module×role×verb, status→role→order approvals, scope predicates
  rollups.yaml       # aggregations over the ontology → cards, grids, exports
  integrations.yaml  # SSO peers, telemetry streams, doc stores, MCP/OpenAPI nodes, webhooks
  theme.yaml         # Vinxi brand tokens + per-program accenting

Two properties keep it a platform rather than another vertical:

Ontology-typed, not stringly-typed. Tasks, entities, and screen payloads carry real Kernel types, validated at publish time — not $node[...] string lookups that fail at runtime.
One definition, two execution profiles. The same workflow runs server-side (durable, parallel) and on-device (an offline interpreter), sharing one renderer state — so a crew works a sub-flow fully disconnected and syncs back exactly once.

The acceptance test for “generic and well-designed”: SmartProject/NCC must be expressible as a single bundle with zero bespoke code, reproducing the behaviour we captured. If it can’t, a layer is not yet generic enough.

Generality is a test, not a claim

Re-derive the fiber program we reverse-engineered, then stand up a wholly different one from the same engine and a different bundle:

Fiber (BharatNet): node tree State→District→Block→GP; lifecycle Scope→HOTO→Plan→Survey→ Build→Ops; Construction/Survey/HOTO task types with *_rkm traits; AM→ZM→QC→PH approvals; rollups = sums of task attributes; capture = fiber depth + videography + RTK.
Gas pipeline: ontology Region→Spread→Section→Weld; lifecycle ROW→Trench→Weld→Hydro-test→ Commission; Welding/NDT task types with joints-per-km traits; Foreman→QC/NDT→Engineer→Client approvals; rollups = welds and test pass-rate; 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.

Non-functional commitments

Offline-ready by design (built online-first, per ADR-0013) — field surfaces designed to run fully disconnected, with renderer parity online and off.
Multi-tenant — org_id everywhere; strict per-tenant isolation (no cross-tenant data leaks).
Secret-safe — secret manager and encrypt-at-write; never a credential in client code.
Audited & deterministic — definition snapshots, immutable run lineage, who/what/when on every transition.
On-brand — all generated UI uses the Vinxi design system.

Open decisions (ADR-pending)

These are deliberately not settled as canon yet; they will be recorded as ADRs once decided:

One engine or one contract — a full SMP × wfb code-merge versus a shared node/port/screen spec with two runtime profiles (server + embeddable device interpreter). The embeddable device profile is the costly part and gates the offline experience.
De-verticalizing FiberSure — its entity types are a hardcoded enum today; they must become data-driven from the bundle.
Config-driven vs truly-dynamic widgets — the renderer’s component set is compile-time; “a new widget as data on the fly” may be a v1 requirement or YAGNI.
Kernel reconciliation — whether the Reality Kernel already implies a node/port model the workflow engine must conform to.

Relationship to canon

This page is the product framing; it composes the Reality Kernel and the existing workflow-engine work rather than superseding any of it. The engine-convergence decision (open #1) will be filed as an ADR once chosen.