Phlo Framework
What exactly your team would be building on.
After the first system is built, the framework becomes available to you. Your own engineers and product people can build the next system on it, or we carry on. This page describes the framework itself, plainly enough for an operations head and precisely enough for the person who will have to maintain it.
The short version
A foundation with strict rules, not a toolkit of options.
Phlo is the part of an operational system that is the same for every business: how a change is recorded, who may record it, how the current figures are worked out, how people find and read them. It is written once and reused. Jetbro builds every client system on it, and its own internal HR portal as well.
What makes it something a second team can build on is that it has few ways of doing anything. There is one way to change data, one shape for a module and one place where permissions are checked. An engineer who has read one module can read all of them.
One write path
Every action is an event, and there is no second route.
A Phlo system has a single entry point for recording anything that happens in the operation. Recording a gate entry, approving a rate and correcting a weight all pass through it, in the same five steps.
- 01 · Who asksA person, the AI assistant or an outside agentA screen, a plain-language request or a connected AI agent. All three arrive at the same place.
- 02 · CheckMay this user record this action?One permission per kind of action. Refused here, nothing is written.
- 03 · WriteThe event is appendedWhat happened, who did it, when and where. Never edited, never deleted.
- 04 · DeriveCurrent state is updatedStock, statuses and balances are recalculated and saved with the event, together or not at all.
- 05 · ReadLists, reports and exportsScreens read the current state. They cannot write to it.
Two consequences matter to whoever inherits the system. First, the audit trail is not a feature someone must remember to add to a new screen: a screen has no other way to save. Second, the event and the figures derived from it are committed in one transaction, so a list can never show a state that the history does not explain. A system of events works through an example.
Modules
A new module plugs in without changing the core.
Everything specific to a business lives in modules: procurement, packing, quotations, attendance. A module declares four things.
- Its events. The things that can happen, named the way the floor names them, each with the fields it must carry.
- Its rules for state. How each event changes the current figures the module keeps.
- Its permissions. Which actions exist to be granted.
- Its screens and read-only queries. How people record the events and see the result.
The framework finds a module when the system starts and wires it in. Adding one does not change how the core works. That separation is what keeps a client system upgradable: when the framework improves, the newer version is merged in and its database changes applied, and the framework ships its own checks that flag a module which no longer meets the conventions.
Roles and permissions
A permission is the right to record one kind of action.
Permissions are not attached to screens or menus. They are attached to actions. A role is a named set of them: the gate operator may record a gate entry, the accountant may post an invoice. Menus, search results, list columns and keyboard shortcuts are then filtered by the same list, so the interface never offers what the role cannot do.
Because each module defines its own permissions, a second system adds new entries to the roles your administrators already manage. It does not bring a second user directory.
State derived from events
Extends without a migration.
In most systems the current figures are the data, and adding a process means reshaping them. In Phlo the events are the data and the figures are worked out. New processes sit on the history you already have.
| What it takes | What happens to existing history | |
|---|---|---|
| A new report | A new view worked out from events that already exist | Read as it is. A report designed next year can cover this year |
| A new process | A module: its events, its rules, its permissions and its screens | Left as it is. The new events are added alongside |
| A new site | A new location, with users and roles assigned to it | Left as it is. The new site starts its own history under the same rules |
| A second system | New modules on the same foundation | Kept, and available to the new system from its first day |
Interface foundations
What every screen starts with.
Operational software is used all day by people who are paid to do something else. These parts are built once, in the framework, so a new module has them from its first screen.
Command palette
One keystroke opens a search across every module: a vendor, an order, a screen. It lists only what the signed-in role may open.
Keyboard navigation
Tables move with the arrow keys, and a shortcut sheet shows what the current screen offers. People who enter data all day rarely reach for the mouse.
List views
Each person chooses which columns a list shows, in what order and how wide. The choice is stored against their login and follows them between devices. A column can require a permission of its own.
Files
Photos, PDFs and spreadsheets attach to the record they belong to. Attaching one is an event, and who may see it follows the permissions of that record.
Settings
Company settings, such as branding and whether the AI assistant is switched on, sit on one administrator screen. They are not scattered through the code.
Offline queue
Offline working is available in the framework and is opt-in. Actions taken without a connection are queued on the device and sent in order when it returns, each one once.
AI in the framework
An assistant and an agent connector, behind the same check.
The framework includes an AI assistant that a user addresses in plain language, and a connector through which an outside AI agent can work with the system. Both are part of the framework. The assistant is off until an administrator switches it on. The connector accepts only a signed-in user, or an access key issued to one, whose role has been granted the use of AI. Not every client uses them.
Neither has a private route to the data. The actions offered to them are generated from the same list of events a person records on a screen, and the reading they can do from the same read-only queries. Each acts as a particular user and is offered only what that user's role allows. The connector checks the permission again at the moment of writing. What it records is an ordinary event, tagged with where it came from.
The assistant also reads the written description of the operation that the first build produces. Human and AI covers where AI is used and where it is deliberately not.
Hosting
Three ordinary parts, placed where you need them.
A Phlo system is a web application, an API service and a standard open-source relational database. Staff use it in a browser on a desktop, a tablet or a phone, with nothing installed. It can run on a server we manage or inside your own infrastructure. Which applies to you, and in which region, is decided with your IT team during the first build.
The second system
What carries forward from the first.
The second system costs a fraction of the first because it does not start again. It reuses:
- the users, roles and sites already set up, with new permissions added to them;
- the recorded history, which the new system can read from its first day;
- the write path, the approval pattern, the list views and the reporting approach, unchanged;
- the model of your operation written down during the first build: its entities, events and exceptions.
The engineering group has two systems built on Phlo, one for spares operations and one for technical offers. They were built as separate systems, for different parts of the business, and share no data, so they are not an example of this reuse.
What this page leaves out
The terms are settled with you, not published here.
This page describes the architecture. It does not set out the commercial terms on which the framework becomes available, or what your team would need from us to start. Those depend on your engineers, your systems and what the first build turns out to be, and they are settled in the first conversation, scoped to the engagement.
Both routes stay open afterwards: your teams on the framework, or the same engagement again. How we work sets out the sequence.
Get started
Bring your engineering lead to the first conversation.
Tell us how your operation runs today, and we will come back with what it takes to build it: the processes, the scope, and the timeline. Every system is scoped and built with you, so the first conversation is about your operation, not a demo.
coffee@jetbro.inWhatsApp +91 90999 62227