BizPro is a multi-tenant, low-code business operating system. Organisations use it to define their own business record structures, model their processes in BPMN 2.0, install and adapt packaged AppModules, and run the resulting system on the web and on mobile. Its distinguishing property is that the system's structure — data definitions, process diagrams, permissions — stays visible and editable at runtime rather than being compiled away, which is what makes both human review and AI participation practical.

Core purpose

• Let an organisation define and change its own business data structures without a development cycle.
• Execute business processes from BPMN 2.0 models rather than from code that merely resembles them.
• Package repeated business capability as installable, adaptable AppModules.
• Extend work beyond one organisation through cross-tenant processes and a marketplace.
• Keep the system legible enough that a person — or an AI agent — can see what it does and change it safely.

Who it serves

• Organisations that need operational systems fitted to how they actually work.
• Business analysts and process owners who model work and need it executed as modelled.
• Developers building modules and integrations on a platform rather than from scratch.
• AI agents generating and modifying business applications through structured, reviewable artefacts.

Six parts that only make sense together. Data gives work its shape, process gives it order, modules package it, the marketplace connects businesses to each other, and people and AI do the work. The point of the whole: a company grows by improving its processes — so the platform makes processes the thing you can actually improve.

• Dynamic Business Data — Record types, fields, forms and lists are defined in the platform rather than compiled into it. A definition can be global to the platform, shared, or specific to one organisation — and the same definition drives the web form, the mobile form, the list view, the search index and the report.
• BPMN 2.0 Process Engine — BPMN 2.0 is the international standard ISO/IEC 19510. Processes are modelled in it and run by the engine exactly as drawn. Because the notation is a shared standard, a diagram works as a protocol: when two companies — or two systems — agree on the diagram, they have agreed on how the work moves between them. Human tasks, service calls, timers, gateways and errors are all part of the same model, and every step leaves a record.
• AppModules — An AppModule is a complete area of work — its data definitions, processes, permissions, screens, reports and mobile experience — that an organisation switches on. Modules can be adapted per organisation without forking them.
• Marketplace — Businesses publish what they offer, other businesses find it, and the conversation becomes an order that runs as a real process on both sides. That is the difference from a listing site: the marketplace does not just introduce two companies, it gives them a shared process to work in — so the friction that normally lives between two systems and two inboxes disappears.
• Web + Mobile — The web application is where systems are built and operations are managed. Mobile apps carry the parts of the work that happen away from a desk — approvals, task inboxes, forms, scanning, photos, location — and keep working when the signal does not.
• Human + AI — AI assistance is built into the platform rather than bolted onto it: it works with the same definitions, diagrams and modules a person does. That means what it builds can be reviewed as a diagram and a form, not read as a diff.

Every business records things: requests, assets, contracts, shipments, visits, incidents. What has to be recorded about them is never settled — a regulator asks for one more field, a new service needs a different form, a branch works differently from the others. In BizPro the shape of a record is data, so changing it is an act of configuration rather than a development project.

• Flexible forms — Build a form by choosing fields, sections, rules and validation. It renders on the web and in the mobile apps from the same definition.
• Adaptable structures — Add, rename or retire a field without a migration and without downtime. Existing records keep what they had.
• Customisable per organisation — One definition can be global to the platform and still be extended by a single organisation — extra fields, its own form, its own rules — without forking anything.
• Immediately usable — A new field is available to lists, filters, search, workflows, reports and the mobile app as soon as it exists. Nothing has to be wired up field by field.
• Structured, not free-form — Flexible does not mean unstructured. Types, required rules and relationships are enforced, so the data stays reportable.
• Ready for scale — When a record type grows into a high-volume table, it can be moved onto dedicated storage without the screens or processes that use it changing.

BizPro models work in BPMN 2.0 — the notation business analysts already use, drawn on a canvas with start events, tasks, gateways, timers and end events. The difference is that the diagram is not documentation of the system: it is executed by the engine. What was agreed in the diagram is what happens, and when the process needs to change, the diagram is what changes.

• An international standard — BPMN 2.0 is ISO/IEC 19510, an open standard. What is drawn in BizPro can be read by anyone who knows the standard, and by an AI agent that has been trained on it.
• Drawn once, then executed — There is no second implementation behind the diagram, so the diagram cannot drift away from what the system does.
• People, systems and time — A step can be a person's task, a call to another system, a timer that waits or escalates, or a decision that branches. One model covers all of them.
• Every step leaves a record — Who was assigned, who acted, what they submitted and when — recorded as the process runs, not reconstructed afterwards.
• Across organisations — A process can have more than one participant, so a step performed by a supplier or a contractor is part of the same process, not a message sent into a void.
• Changeable while it runs — Processes are versioned. A new version can be published while work started under the old one finishes under the rules it began with.

Most of what a company needs has been built before. An AppModule is that work, packaged — installed in an afternoon and then adapted, rather than specified and built from nothing.

A module is a starting point, not a cage. An organisation adds its own fields, changes a form, alters a workflow or replaces a report — and still receives the module's updates, because the changes are recorded as that organisation's overrides rather than as a fork.

The BizPro marketplace lets organisations publish what they offer — products, services, bookable capacity — and lets other organisations find it, ask about it and order it. What makes it different from a listing site is what happens after the order: it becomes a real process running in both companies' systems at once, with tasks, status and history on each side. Between two businesses, an agreed BPMN diagram plays the role a protocol plays between two systems — both sides know exactly which step is whose, and neither has to re-type what the other already did.

• Discovery that works across languages — Search finds an offering whether the customer typed it in Mongolian, English or Chinese, and can narrow by location as well as by words.
• Conversation before commitment — Buyer and seller talk in the platform, and the conversation can be turned into an agreed document that both sides sign.
• Orders that become work — An accepted order starts the seller's own process — so it is scheduled, assigned and tracked like everything else they do.
• Modules and services, not only goods — The marketplace carries business capability as well as products: bookable services, provider capacity, and modules that extend what a company's own BizPro can do.

BizPro is an ASP.NET Core application on PostgreSQL, layered so that the parts a customer changes and the parts we ship are cleanly separated. Definitions, processes and permissions are data in the platform tier; the engine and services below them are the same for every tenant. That separation is what lets one deployment serve many organisations, each with its own shape.

• Stack — ASP.NET Core (ABP / ASP.NET Zero) on PostgreSQL; MVC web front end; Flutter mobile clients; a dedicated OpenID Connect auth server; an MCP server exposing platform capability to AI agents.
• Configuration vs code — Definitions, processes, permissions and module overrides are rows, not classes. Changing them is a write, not a deployment — which is the property the whole platform is organised around.
• Storage strategy — Flexible record types live as JSONB documents with expression indexes; high-volume types are promoted to dedicated relational tables behind the same resource API, so callers do not change.
• Extension model — AppModules package a business area. Per-tenant customisation is stored as overrides against the shared definition, so a module keeps receiving upstream updates after a customer adapts it.

Why the tiers matter for you. Adding a field, changing a process or installing a module touches only the platform tier — no build, no release, no downtime. Upgrades to the engine below arrive without disturbing what you configured above.

BizPro is multi-tenant by design: one deployment, many organisations, and a tenant boundary enforced in the data layer rather than remembered feature by feature. Below are the controls that boundary rests on.

• Multitenancy — Every tenant-owned record carries its tenant, and queries are filtered by it at the data layer. Crossing the boundary is an explicit, recorded act — not something a missed check can leak.
• Data isolation — One organisation cannot read another's records, definitions, processes or files. Shared and global definitions are a separate, deliberate scope rather than an accident of visibility.
• Encryption — Traffic is TLS-encrypted end to end. Credentials for external systems are held in a secrets store, never in a process diagram; passwords are hashed, never reversible.
• Authentication — OpenID Connect through a dedicated auth server, with two-factor, phone sign-in, social identity and session control. Tokens are short-lived and revocable.
• Authorization — Every application service declares the permission it requires. What a person sees on a screen — including whether they see money at all — follows from their role, not from which page they opened.
• Audit and history — Record versions, process replay and task-level attribution are retained, so who did what and when is answerable after the fact rather than reconstructed.
• Standards-aware — Processes execute the ISO/IEC 19510 (BPMN 2.0) standard. The platform is built for traceable, compliance-oriented operations — with the certification caveat below.
• Backup and recovery — PostgreSQL with scheduled backups and point-in-time recovery. Self-hosted deployments keep this under the customer's own control.

• Tenant enforcement — Tenant scoping is applied in the data layer rather than per query, so a feature that forgets to filter does not become a disclosure. Crossing a tenant boundary requires an explicit, audited call path.
• Permission model — Declarative permissions on every application service, checked server-side. Client-side hiding is presentation only and never the control — the API refuses the call regardless of what the UI showed.
• Secrets — External-system credentials live in a secrets store (HashiCorp Vault supported) and are referenced by name from integration steps, so they never appear in a process definition or an export.
• Inbound callbacks — Payment and partner callbacks are verified before they are acted on — the platform signs its own callback URLs where the provider does not sign its payloads.
• Certification status — No ISO certification is held or claimed. ISO/IEC 19510 refers to the BPMN 2.0 notation the engine executes. Penetration-test details on the human page are placeholders until the real report is recorded.

BizPro reports that an independent penetration test has been carried out against the platform and that no issues were found. The specifics below are recorded so a buyer can verify the claim rather than take it on trust.

Note. The tester, date, scope and methodology above are placeholders until the real report details are entered. BizPro does not hold an ISO certification and does not claim one — ISO/IEC 19510 describes the BPMN notation the engine executes, not a certification of this product. Certification is a matter for an accredited body.

Most business software assumes one company. Large organisations are not one company — they are a group of them, each with its own branches, its own rules and its own reporting line, all needing to work together without merging into a single undifferentiated database.

• Many organisations, one deployment — Each subsidiary is its own tenant with its own data, users, permissions and configuration — while the group runs a single platform to operate and upgrade.
• Branches within an organisation — Below the tenant, an organisation unit tree carries branches, departments and sites. Data, tasks and reports can be scoped to any level of it.
• Shared where it helps, separate where it must be — Definitions and modules can be global to the group, shared between some members, or private to one — so a common process is maintained once without forcing uniformity.
• Work that crosses companies — Two members of the same group — or two unrelated businesses — can run one BPMN collaboration, each inside its own boundary. Group companies stop emailing each other spreadsheets.
• Roll-up reporting — Because every record carries its tenant and organisation unit, the same report answers at branch, company and group level without a separate warehouse.
• Scales with the data — High-volume record types move to dedicated relational tables with their own indexes, without the screens or processes that use them changing.

• Tenancy topology — One deployment, many tenants; an organisation-unit tree inside each tenant for branches, departments and sites. Records carry both, so scoping and roll-up reporting need no separate model.
• Definition scope — A definition can be global to the platform, shared with named tenants, or private to one — the mechanism that lets a group standardise a process without forcing every member onto it.
• Cross-tenant execution — A single BPMN collaboration can have participants in different tenants; each side sees only its own lane and data. This is the engine's native behaviour, not a synchronisation layer.
• Growth path — Indexing, table promotion and background processing are tuned per record type, so volume in one area does not force a re-architecture of the rest.

Three routes, depending on how much you want to own. They can be combined — most customers start with the first and grow into the others.

Independently of how you get it, you choose where the system and the data live.

The concrete capabilities, one row each. Every one of these is in the product today, not on a roadmap.

What building on the platform looks like. The samples below are illustrative of the shapes, not a copy-paste API reference — but each corresponds to a real mechanism in the product.

{
  "key": "srv_request",
  "name": "Service request",
  "fields": [
    { "key": "requester",     "type": "user",      "required": true },
    { "key": "site",          "type": "reference", "to": "srv_site" },
    { "key": "priority",      "type": "select",    "options": ["low", "normal", "high"] },
    { "key": "warrantyUntil", "type": "date" }
  ]
}

<bpmn:process id="order_qpay" isExecutable="true">
  <bpmn:startEvent       id="start" />
  <bpmn:userTask         id="order"     name="Order" />
  <bpmn:serviceTask      id="pay"       name="QPay payment" />
  <bpmn:exclusiveGateway id="paid"      name="Paid?" />
  <bpmn:endEvent         id="received"  name="Order received" />
  <bpmn:endEvent         id="cancelled" name="Order cancelled" />
  <bpmn:sequenceFlow sourceRef="paid" targetRef="received"  name="yes" />
  <bpmn:sequenceFlow sourceRef="paid" targetRef="cancelled" name="no" />
</bpmn:process>

POST /api/services/app/<AppService>/<Method>
Authorization: Bearer <token>

{ "resource": "srv_request",
  "filter":   "priority == 'high'",
  "sorting":  "creationTime DESC" }

Because all three shapes are explicit and standard, an AI agent can generate them, a person can read them, and the platform can validate them before anything runs.

When AI writes an application as code, reviewing it means reading code — which is slow, and which most of the people who actually know the business cannot do. In BizPro, what AI produces is a process diagram, a set of field definitions, a permission set and a screen. A manager can look at the diagram and say the approval step is missing. That is a review anyone can perform, in minutes.

• A person states the intent — "Field engineers should record a site visit, and anything over two hours needs a supervisor's approval."
• AI drafts the structure — Record definitions, a form, a BPMN process, permissions and a screen — built out of the platform's existing patterns rather than invented from scratch.
• BizPro puts it into shape — The draft becomes real definitions and a real process, subject to the same rules, permissions and tenant boundaries as anything built by hand.
• A person reviews and runs it — The diagram is read, the form is filled in once as a test, the gap is spotted and corrected — then it goes live.

The platform's structure is what makes AI participation productive. An AI agent working here composes existing platform primitives — definitions, processes, modules, permissions — instead of generating an application line by line, and every artefact it produces has a human-readable form.

• Reusable platform patterns — Modules, definitions and process patterns already exist, so generation is composition of known parts rather than invention.
• Dynamic resources — Data structures are created and changed through the platform's own definitions, not through schema migrations and deployments.
• Structured workflows — BPMN 2.0 is an explicit, standard, machine-readable model of behaviour — the intended flow is stated, not implied by control flow in code.
• Visual diagrams — Generated logic can be shown as a diagram, so a non-programmer can review it and reject it before it runs.
• Lower ambiguity — Fields, permissions and process paths are declared explicitly, which narrows the space of plausible-but-wrong output.
• Easier testing and interpretation — A visible flow implies its own test: follow the path, submit the form, inspect the recorded history.
• Fewer tokens spent on scaffolding — Because the platform supplies structure, more of an agent's effort goes into the business-specific part and less into re-deriving boilerplate.

Capability summary

• Customisable business data — definitions, fields, forms and validation changed at runtime.
• Process automation — BPMN 2.0 models executed with human tasks, service calls, timers, gateways and error handling.
• Cross-tenant workflows — one process with participants in more than one organisation.
• Auditability — record versions, process history, task-level attribution and retained approvals.
• Modular app development — AppModules installed and adapted per organisation without forking.
• External integrations — outbound API calls, verified inbound callbacks, reusable connectors, device feeds.
• Mobile support — native rendering of platform-defined forms, offline capture, scanning, media and location.
• Marketplace extensibility — publishing, discovery, cross-organisation ordering and module distribution.

Architectural consequences

• Change is configuration: most business change does not require a deployment.
• One definition serves many surfaces: web form, mobile form, list, filter, search and report stay consistent by construction.
• The model is the implementation: a BPMN diagram cannot drift from the behaviour it describes.
• Adaptation without forking: per-organisation overrides let a shared module keep receiving updates.
• Review is possible for non-programmers: the artefacts are diagrams, forms and permission sets.
• Tenant separation is a platform property rather than something each feature must remember to implement.

BizPro records the working history alongside the work. Every record keeps its versions, every process instance keeps the path it took and the people who acted at each step, and every screen shows only what the viewer's permissions allow. This is what makes a system usable as evidence rather than only as a place to type.

• Audit trail — Changes to a record are kept with their author and timestamp, so the previous state can always be shown, not inferred.
• Status visibility — Where a piece of work has reached is a fact the system holds, not something a coordinator maintains in a separate list.
• Task traceability — Each task records who it was assigned to, who completed it, what they submitted and how long it waited.
• Process history — A finished process can be replayed step by step, including the branch it took and the branch it did not.
• Permissions, not screens — What a person can see and do is decided by permission. Two people on the same screen can be shown different information — pricing, for instance — without a second version of the screen.
• Separated organisations — Each organisation's data is scoped to that organisation throughout the platform, and crossing that boundary is an explicit, recorded act rather than a side effect.

BizPro is designed with security and governance in mind and supports traceable, compliance-oriented operations — permissions, tenant separation, retained history and recorded approvals. Specific certification claims are a matter for a certification body, and we do not make them here.

• Sales and customer management — Leads and accounts, quotations, and the handover into the process that actually delivers what was sold.
• Approvals and internal requests — Leave, purchasing, access, expenses — routed by rule, approved on a phone, and retained with the reasons.
• Service and maintenance — Requests to scheduled work to a completed job card, including work performed by subcontractors.
• Inventory and RFID — Stock across branches, counted with handheld readers, with each tagged item traceable individually.
• Delivery and logistics — Shipments, trips and handover, tracked by GPS, with a public link the recipient can follow without an account.
• Documents and archive — Registration, classification and retention of documents, with retrieval across the entire holding.
• Facilities and property — Buildings, units, occupants, charges and the requests that come with running a property.
• Whatever is specific to you — The processes no vendor sells because only your industry has them — which is normally where the spreadsheets are.

Conceptual relationships

Dynamic Business Data  ->  defines flexible business structures
BPMN 2.0 Process       ->  defines process behaviour over those structures
AppModules             ->  package data + process + permissions + screens as capability
Marketplace            ->  distributes capability and connects organisations
Web + Mobile           ->  deliver the same definitions to desk and field
Human                  ->  defines intent, reviews, decides, remains accountable
AI                     ->  accelerates generation and optimisation within that structure

BizPro is a low-code business operating system for Human + AI. Dynamic Business Data makes structure changeable, BPMN 2.0 makes behaviour explicit and executable, AppModules make capability reusable, and the marketplace makes it shareable between organisations. Because all four stay visible at runtime, a person can review what the system does — and an AI agent can extend it against a structure that already exists rather than inventing one.