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.

• Data you can change — Fields, forms and record types are configuration, not a release. A field added in the morning is in use by the afternoon.
• Processes you can see — Work is described as a BPMN 2.0 diagram that a manager and the engine both read. The diagram is the process, not a picture of one.
• Modules instead of blank pages — Inventory, service work, requests, archive, delivery and more already exist as AppModules. You install one and adapt it, rather than starting from nothing.
• One record, many places — The office screen, the phone, the public link and the report all read the same record. Nothing is copied between systems and nothing goes out of date.
• Open at the edges — External systems connect as steps inside a workflow. Other organisations connect through the marketplace and cross-tenant processes.
• Built for Human + AI — AI can draft what it would take a person days to assemble — and what it produces is a diagram, a form and a permission set, which a person can read, test and correct.

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.

The web application is where systems get built, configured and managed. The mobile apps carry the work that happens elsewhere — on a site, in a vehicle, on a shop floor, in a customer's building. They render the same forms from the same definitions, so a form built once works in both places, and they hold what was entered until there is a connection to send it.

• Flutter, one codebase — The apps are Flutter — Android and iOS from one codebase, with a shared component package so every BizPro app looks and behaves the same.
• Forms render natively — The Form.io renderer is already built: a form defined on the platform is drawn with native widgets in the app. It is not a web page in a wrapper, and it does not have to be built twice.
• Native where it earns it — Where a job needs the device rather than a form — RFID handhelds, sustained scanning, background location — that part can be built native and still talk to the same services.
• Work offline — Actions taken with no signal are stored on the device and sent when the connection returns, with safeguards against sending something twice.
• What a phone is actually good at — Scanning a code, taking a photo, capturing a location, signing with a finger — the parts of a record that are painful at a desk.
• A task inbox that matters — Approvals and assigned tasks arrive on the phone, so a process is not waiting three days for someone to open a laptop.
• Customise it, or build on it — Tabs, theme, branding and which modules appear are configuration. Beyond that the app is ordinary Flutter — a new screen, a new flow or a whole industry app is normal development, not a fight with a framework.
• One app, the whole span — Finding a business, chatting to it, ordering from it, and then running the work that order creates — the marketplace, the conversation, the process and the task inbox are the same app and the same records, not four products stitched together.

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. An independent white-box penetration test and vulnerability assessment (January–February 2024) found no issues; the report is available on request.

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. 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.

BizPro exposes a machine-facing surface as a first-class part of the platform, not a bolt-on: a Model Context Protocol server that an external AI agent connects to in order to read the platform by meaning, validate a proposed change, and propose it for a person to confirm. It runs as its own process, so it can be restarted, disabled or removed without touching the web application — and it serves the same catalogue the assistants inside the product use.

• Transport — Model Context Protocol over HTTP. Deployed as a separate host on its own name, sharing the database and job queue with the web application but running independently.
• Authentication — Bearer tokens only — the same JWTs the API host issues, with the same signing key, issuer and audience, so no second credential system exists. The server refuses to start without a signing key.
• Identity — Taken from the validated token's claims and used as the session every tool's tenant filtering keys off. Identity arguments are rejected outright: a call cannot name the tenant or user it wants to act as.
• Contract — A declared tool catalogue with input and output schemas. The dispatcher refuses any name not in it, so a handler cannot become reachable by accident; each tool also declares its toolset, its surfaces and whether a person must confirm.
• Discoverability — A knowledge tool searches BizPro's own skills, their reference files, agent role definitions, the tool catalogue and the per-module guides, returning excerpts — so an agent can find out how the platform does something before proposing a change, rather than inferring it.
• Resources — Beside the tools, the server serves the Concept Contracts (the ontology), the module guides, the published skills, the platform catalogue and a JSON-LD export as MCP resources — so an agent reads what a record means before it asks for one.

The catalogue today — 99 tools, grouped by what they are for:

Every tool declares two independent things — what it does, and what it costs to be wrong. They are separate axes because two write tools can sit at very different levels, and the operator reading an audit page cares about the second question:

• ReadOnly — Nothing to reverse.
• SafeWrite — Writes something a person still has to approve.
• PrivilegedWrite — Moves real platform state, or state shared beyond one tenant.
• Destructive — Removes or overwrites something not trivially recoverable.
• HostOnly — Never reachable from a tenant session.
• Confirmation — Declared separately from both: a proposal tool writes nothing itself — the change happens only when a person confirms it in the browser — and a tool at PrivilegedWrite or above with no confirmation is refused by the dispatcher.

Alongside the tools, the platform ships its own written knowledge: 17 skills, each routing to the reference material for one area of the system, and 14 agent role definitions naming the skills a given role must load before it works. This is what an agent reads to become competent here — the same material a new engineer reads. Two roles are mandatory rather than advisory: anything touching accounting, audit history or tenant isolation loads the compliance role, and anything touching authorization or tenant scoping loads the security reviewer.

• Structural — Core architecture, dynamic entities and resources, the BPMN engine, AppModule development and per-tenant customisation.
• Boundaries — Permissions and security, cross-tenant collaboration — the two areas where a wrong answer is a breach rather than a bug.
• Surfaces — MVC pages and grids, the Flutter apps, SQL and PostgreSQL, testing.
• Written output — Developer documentation, user manuals, and live-tenant support diagnosis.

What an agent cannot do, structurally rather than by policy:

• Write to a platform row directly. Every mutation is a change set, or a proposal a person confirms.
• Approve its own work. Approval and confirmation are browser actions: neither is in the agent tool set, and there is no confirm endpoint on the API.
• Read a concept the asking person could not open on a page. Semantic reads are authorized per concept and per tenant, and audited.
• Act as another tenant or user. Identity comes from the token; identity arguments are refused.
• Reach a tool that is not in the catalogue, or a host-only tool from a tenant session.
• Read a platform-owned store through the generic resource API — those keys are refused on both the read and the write path.
• See credential values. Connector metadata is exposed; secrets are not.

Connecting an agent:

1. Obtain a JWT from the API host — the same token the REST API accepts.
2. Point the MCP client at the server host with that token as a bearer credential.
3. Call get_system_version to confirm protocol revision and tool counts; read bizpro://ontology for what the records mean.
4. Call get_module_context first — ids, keys and module codes must come from it, not be guessed.
5. Read before writing: semantic_resolve, then semantic_describe and search_bizpro_knowledge.
6. Validate, then propose — a change set for structure, semantic_execute or start_process for data — and hand it to a person to confirm.

The design assumption is that an agent is capable and fallible. So the platform makes the useful things easy to discover and the dangerous things impossible to reach, and puts a person at the single point where a proposal becomes reality.

Every AI feature in BizPro — the setup assistants, the module agents, the support chat, the MCP server for outside agents — runs on one stack. Six layers, each with one job, and none of them takes over another's.

• Ontology governs meaning. DynamicEntity governs state. BPMN governs execution. — MCP exposes capability, skills govern procedure, and the model interprets and composes. No layer does another's job — which is what keeps a wrong answer from becoming a wrong write.
• No agent writes business data. — Every change is a proposal or a change set that a person confirms. The confirmation is a browser action with no API behind it, so a token an agent holds cannot confirm its own work.
• Identity is never an argument. — Tenant and user come from the session. A tool cannot name the tenant it wants to act as, and every semantic read is scoped to the person asking — the same rows they could open on a page.
• The first customer is our own accounting. — The accounting setup assistant reads a chart of accounts from Excel, maps it to the standard chart, proposes opening balances and posting defaults — and a person confirms each card. The hotel module lands a tenant from a recipe with no hotel code in the engine.

Every layer above is in the product today, with its tests — not on a roadmap. The design is documented phase by phase in the platform's development plan.

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.

We learn from real projects and keep improving the platform from what they teach us.

An outside system can be called from inside a BizPro process. Wire it up once and every later process reuses it.

• Calls to other systems — A step in the process calls an external API — an ERP, a financial system, a tax service, a bank, a partner's system — with its credentials held centrally and never in the diagram.
• Events and callbacks — Another system tells BizPro that something happened, and a waiting process continues. Callbacks are verified before they are believed.
• Reusable connectors — Common integrations are packaged so they can be configured rather than built, and reused by any process that needs them.
• Devices and data feeds — GPS units, scanners and handheld readers report into the same records that people work on, so a status can change on its own.

Three areas under active work.

• AI Accounting — An AI-assisted accounting module — Transactions, documents, journals and reporting connected to the process and to AI. Compliance and the audit trail are being built as part of the architecture, not bolted on.
• Logistics — A logistics process that continues between companies — Orders, warehousing, transport, delivery and documents connected across the organisations taking part.
• PMS — Time-based property management — Availability, booking, service and payment for rooms, units and spaces, run as a process.

An environment where one organisation's business process continues directly into the next organisation's process.

• An order does not end at one organisation.
• It goes to the supplier. From there to logistics. The payment to the bank. The receipt to the tax system.
• BizPro sees all of that not as separate applications but as one business process that keeps going.

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.