What Elastbiz actually is

Elastbiz is the operating environment — language + database + HTTP layer + AI integration — that every Elastbiz product (Code, Tables, Mail, Watchcam, Home, Assistant) runs on. It's not a framework; it's a runtime substrate with a unified data model and plugin architecture.

Four pillars, all in production for years:

EPL — Elastic Programming Language. C-like OOP scripting with reference-counted GC, native C++ plugin system, multi-threading. Every application is written in EPL.
Elastic Database (DSM) — Hierarchical object store. Schema derived from EPL class attributes (no ORM). Tree-of-tables universal model. ACID transactions, binary data, references between objects.
HSRV — Multi-threaded HTTP server in EPL. Native TLS, WebSocket support, ACME challenge handling. The server you're reading this on.
Plugin SDK — Small MIT-licensed C++/EPL header set so third parties can write in-process plugins.

The plugin model — why this isn't another Monday

Every Elastbiz product is a plugin extending TT_PluginBase. Each plugin claims a command-range, owns describing objects for its partition types, and registers FM worker roles. Locked architecture as of 2026-05-29:

TT_PluginBase (base, shipped)
    ↓ extends
TablesPlugin      — owns Invoice/Project/Task/Person/Customer/Inventory descriptors
TGitHostPlugin    — owns SourceRepo/Build/Pipeline/Issue/PR descriptors
TMailPlugin       — owns Mailbox/Message descriptors
TWatchPlugin      — owns Camera/MotionEvent descriptors
THomePlugin       — owns Device/Scene/Sensor descriptors
TAssistantPlugin  — owns Session/Skill/WakeLog descriptors
TFMInstancePlugin — owns FMInstances/FMTasks (AI worker roster)

Each plugin owns a collection of PartitionTypeDescriptor rows. A partition type is a plugin describing object — no special table, no JSON schema blobs, just rows with subtables for triggers / conditions / actions / ACL rules / view affordances / business hooks / computed fields. All proper EPL classes with attrib(db, ...) columns.

Buying Tables = installing TablesPlugin + activating its built-in type descriptors. Buying Mail = installing MailPlugin. Same model for every product. Customers can write their own plugins too — that's what the MIT-licensed Plugin SDK enables.

Why "buy Tables, govern the whole substrate"

Tables exposes a generic "User Custom Type" mechanism: an authenticated user describes a new partition type in plain English, an AI worker generates the descriptor row + child rows directly (no plugin recompile). The runtime interprets it. New types appear in the org's TablesPlugin collection without any code deployment.

This is also why Tables retroactively governs Code's partitions. Once TablesPlugin is active, CHECK_PARTITION_PRIV branches on PluginTypeOid: typed partition → consult ACLRuleRow set on the descriptor; untyped → fall back to binary check. Code Starter partitions become Tables-governed the moment Tables activates.

Multi-license architecture

Elastbiz ships under three distinct licenses, chosen to match what each layer is for:

Layer	Public repo	License	Distribution
EPL interpreter	—	Proprietary EULA	Per-platform binary
ThePlatform (partition machinery, classes)	`ThePlatform`	Proprietary EULA	Binary
DSM	—	Proprietary EULA	Binary
AILib (AIRecords, planner, embeddings)	—	Proprietary EULA	Binary
HSRV (HTTP/REST bridge, web layer)	`ElastcodeHttp` + `ElastbizCode`	Elastic License 2.0	Source, public repos
Plugin SDK headers	`PluginSDK`	MIT	Source, public repo

The web layer is source-open so customers can fork it, extend REST endpoints, customize the SPA. The platform IP stays binary + proprietary so a competitor can't read 14 years of platform engineering for free and rebuild it. The Plugin SDK is permissively licensed so third parties can ship plugins without any contagion concerns.

Self-hosted by default; cloud is research

v1.0 ships self-hosted. Customer installs a Docker tarball with the binary core + ELv2 web layer source + Plugin SDK. License key activation gates the proprietary binaries at startup. Customer's data lives in customer's DSM partitions; nothing phones home.

A public cloud version is in research (target: Week 7+). Three candidate models:

Hybrid — we host AI workers (where GPU cost lives), customer hosts DSM (where data lives). Splits cost where it belongs.
Hosted single-tenant — we run a Elastbiz instance per customer on our infra. Same binary; we manage uptime.
Multi-tenant SaaS — for customers who genuinely won't self-host. Real engineering: partition isolation, tenant controls. The lane EduBlend (educational SaaS variant) is being built for.

Why this is not Monday.com clone

Monday is a hosted SaaS with one app (work management). Elastbiz is a substrate hosting many apps (Code, Tables, Mail, Watch, Home, Assistant), with the option to self-host the whole thing. Specifics:

Self-hostable — Monday is cloud-only. Elastbiz runs on your laptop, your VPS, your air-gapped network.
AI as primitive — Monday added agents in 2025 as an overlay. Elastbiz treats every action as an AIRecord row from day one; every worker is a typed FM instance with a role.
Cross-product substrate — Code, Tables, Connect, Watch, Mail, Home, Assistant all share partitions, auth, AI workers, audit. Not six apps with integrations; one substrate with views.
Plans as data — AI proposes a plan as DSM rows, human approves, system executes. The plan + every execution step audit lives in the database, not a log file.
Plugin SDK — third parties write in-process C++/EPL plugins (MIT). Monday's "marketplace" is webhook integrations.
Multi-license — Monday is closed SaaS. We expose the web layer as ELv2 so you can fork it.
EU jurisdiction — Cyprus / EU. Relevant for regulated EU customers concerned about US cloud sovereignty.
Family Space — encrypted personal partitions, optionally self-hosted on home machine, accessible across orgs via user delegation. No SaaS has this primitive.

What runs in production today

Elastbiz-the-substrate has been running production workloads for years. Existing deployments include:

Watchcam — originally an internal video-monitoring product running on the substrate; now being refactored as the WatchPlugin so it activates alongside other Elastbiz products under a unified rail
vplatform.org git hosting (~20 internal repos, Gogs + Elastbiz git host)
Elastbiz Code internal usage (we dogfood our own git platform)
A handful of customer-specific apps (e.g., Medin's astrology app — built to order by AI workers)

v1.0 (Mon 2026-06-01) is the first public release of Elastbiz Code as an activated product on the substrate. Tables + Mail follow in Week 6 (~2026-07-12). Watch / Home / Assistant follow Phase 1 the same week.

For investors

Three points to verify with us:

The substrate is 14 years old and works. Read the platform component pages. Then ask for a 30-minute architecture walkthrough.
The pricing model is honest: per-product activation, no per-user creep, Tables as the wedge. Pricing grid.
The unit economics make sense in cloud (when we ship the cloud version) because marginal cost per customer is dominated by LLM tokens, not engineering salaries.

Investment conversations: partnership@elastcode.com.

For developers

If you want to write a plugin against the Elastbiz substrate:

Read the Plugin SDK headers (MIT-licensed; coming public Week 6)
Pick a partition type domain you want to support
Subclass TT_PluginBase, declare your describing objects, register your command range
Ship as a plugin tarball that drops into the Elastbiz plugins directory
Customer installs it; their TablesPlugin sees your descriptors; they get type-aware governance for free

Full developer docs at /docs.

The plugin model + multi-license + 14-year substrate are the three things that make this venture-fundable. Without them, we'd be another Monday clone. With them, we're a different category — a privacy-aware, AI-native, self-hostable business OS that earns the "OS" suffix.

Elastbiz — the substrate