Foundation layer
Multi-tenant isolation, permissions, announcements, template distribution, logs, and audit are common platform foundations. They do not exist only for scripts.
Architecture
Architecture
Architecture ThesisLet different entries share one governance core first. Otherwise the product becomes harder to control every time a new surface is added.
The goal is not to spread into more endpoints. It is to let the free entry, formal delivery, and local onboarding reuse one logic so a single-maintainer system does not drift apart.
ExecFabric is a multi-tenant capability-governance and execution platform that treats Python scripts as the first mature execution asset.
The platform currently uses a single-repo, multi-frontend setup with one unified backend capability center. The real point is not how many modules exist. It is that platform governance, tenant isolation, the free entry, and local onboarding are pulled into one architectural logic.
Unified backendpublic governancetenant frontsCLI bridge
EXECFABRIC // ARCH LAYOUTDOC 04
const core = 'unified_python_backend' // capability control centerconst governance = 'public_admin_console' // platform governanceconst entries = ['tenant_fronts', 'free_entry', 'execfabric_cli']
ONE CORE / MULTIPLE ENTRY SURFACES
1.0 Standard
Where the current architecture actually lands
Abstraction layer
A Skill is the capability unit. It defines inputs, outputs, risk, approval, and visibility boundary. It should not be understood only as a script file.
Implementation layer
Python scripts are still the first mature execution asset today, so upload, registration, runtime, and the CLI remain script-first for now.
The platform has already moved one step beyond script-only thinking: the general resource layer and executor registry layer have landed, and the first non-script capability sample, HTTP capability access, has already been validated in the public super-admin domain. That means the foundation is no longer limited to "run a script file," even though tenant-side delivery is still most mature and most stable on the script path.
This round also tightened the governance boundary: configuration, credential governance, and trial execution for HTTP capability access stay only in the public governance domain. Whitelisted tenant admins keep only a minimal cross-tenant console entry, while tenant-side pages stay read-only instead of exposing platform-governance pages directly.
From the 1.1 point of view, orders, payment confirmation, renewal-reminder scans, and expiry shutdown scans have already been pulled into the public governance domain first. That avoids scattering pricing and lifecycle logic into tenant-facing pages too early. Self-serve user paths and real payment gateways still come later.
Administrator identification has also been tightened: the platform no longer relies on risky conditions such as user_id == 1, and instead recognizes only explicit admin usernames or super-admin markers.
System Map
What the system is made of
Unified backend capability center
The unified backend carries core services such as authentication, tenancy, capability catalog, execution assets, logs, and templates.
Governance console
This domain handles platform-level configuration, templates, logs, and operational governance without being mixed into ordinary business entry pages.
Formal customer frontends
These are the real customer-facing environments that carry business access and execution entries.
Multi-tenant delivery sites
These frontends support different customers or environments. The product now clearly splits single-tenant delivery and shared-SaaS tenant fronts instead of cloning a new frontend project for every customer by default.
Personal experience entry
This path faces individual users and early explorers and carries the experience, growth, and free lead-generation flow.
Integration and sync layer
This layer is used for multi-entry aggregation, integration testing, and final sync. It is not the formal customer-facing entry.
CLI / Local Bridge
This is the local onboarding and Local Agent skeleton entry that connects the platform control plane with the local environment.
docs
The public explanation site, version roadmap, and entry pages help both customers and internal work stay aligned quickly.
Governance Domain
What public owns
- Platform super-admin
- Customer ledgers
- Tenant management
- Order center and tenant lifecycle governance
- Platform audit
- HTTP resource access, credential governance, and write-boundary control
- Template distribution governance
Tenant Domain
What each tenant schema owns
- Users, roles, menus, parameters, and announcements
- Capability onboarding, Skill binding, and tenant authorization
- Read-only summaries of authorized HTTP resources
- Execution records and scheduling logs
- Business extension tables
- That tenant's own access boundary and data boundary
Concept 01
A Skill is the capability unit
A Skill is user-facing and AI-facing. It describes the capability name, input and output, visibility, risk level, approval requirement, and audit boundary.
Concept 02
An execution asset is the concrete integration target
An execution asset describes what the capability actually connects to. Python scripts are still the most mature path, and the platform is already using HTTP-resource samples to validate how API-style assets enter the same governance chain.
Concept 03
The executor owns runtime adaptation
The executor decides how different asset types are called, how input and output are validated, and how results return into one audit chain. Runtime is no longer hard-coded only around scripts.
Runtime Boundary
How the runtime boundary is established
One customer, one URL
In standard delivery, each customer receives a dedicated access URL, a dedicated tenant space, and a set of customer-specific capabilities.
The Host binds the tenant
The runtime binds the tenant and switches schema by Host, so "one customer, one URL" is part of the runtime boundary rather than just a sales phrase.
public is not an ordinary tenant
public owns platform governance and the shared foundation. Customers do not use it as if it were their own business tenant.
Shared Tenant Front
Shared-SaaS tenant frontend
- Starting from
tenant_1003+, standard SaaS customers first enter the shared-tenant frontend skeleton - What is shared is the frontend project and release rhythm, not tenant data, menu permissions, or execution results
- Runtime still switches into the corresponding schema by Host
- This path fits standard capabilities and lighter team collaboration
Shell Role
The real role of execfabric-shell
- It mainly exists for multi-entry aggregation, integration testing, and final sync
- It is not the long-term formal customer runtime entry
- For formal customer usage, the source of truth remains the formal single project or shared-tenant frontend
- This reduces the risk that the shell becomes the "truth" while the formal projects drift away
Delivery Package
What standard delivery usually includes
- One dedicated tenant
- One dedicated access URL
- A set of customer-specific capabilities, currently still centered on script-based capabilities
- Platform accounts and baseline permissions
- Customer usage guidance and script hot-update instructions
Acceptance Check
What matters most during customer acceptance
- Can the customer log in through their own URL
- Can they see only their own capabilities
- Can they execute those capabilities and view results
- Can they keep submitting script updates through the formal path without redeploying the whole platform
Architecture To Delivery
Key material for architecture in practice
FilesFile Upload & Result Delivery
When a project depends on input files, batch status, and result files, this path is part of the architecture in practice rather than just a frontend detail.
DeliverablesDeliverables / Doc EntryIf customers will use the platform continuously, the formal architecture must also carry documentation, result entries, and delivery boundaries instead of stopping at a diagram.
ChecklistOnboarding ChecklistWhen a real capability is about to be onboarded, preparing the script folder, README, sample files, and dependencies is more effective than continuing to argue over module boundaries in the abstract.
Architecture Rules
Implementation and isolation rules
Rule 01Tenant isolation comes first
Data, capability, and permission boundaries between customers need to be clear before broader operations and expansion are discussed.
Rule 02Governance and business entries stay layeredUnified governance capability and customer-facing business entries need clearly separated responsibilities so permission and messaging do not get mixed up.
Rule 03Validate a change before scaling it outCapabilities, processes, and frontend changes should first prove stable before they expand into a wider scope.
Rule 04Delivery boundary and platform boundary stay explicitThe platform must support customer delivery while still preserving unified governance and operations. One side should not crowd out the other.
Rule 05execfabric-cli connects the local environment with the platform control planeLocal script onboarding, manifest generation, machine identity persistence, and the minimal Local Agent claim-execute-complete loop already run along this bridge. Heartbeat, status, and deeper scheduling remain later enhancements.
Rule 06The file path belongs inside the formal architectureIf a project truly depends on input files and result files, upload, batches, and result entry points are part of the formal delivery architecture rather than a temporary upload feature.
Why This Works
Why this structure fits the current phase
It can directly support enterprise delivery
Tenant boundaries and platform-governance boundaries are both real first, so delivery does not depend on ad hoc stitching.
It preserves platform-governance capability
The public side can keep customer ledgers, tenant state, template distribution, and audit logs without building a second separate system.
It can also carry the personal free growth entry
The free edition is not a side branch. It is one formal entry and can keep accumulating leads and usage samples.
It leaves room for more asset types later
The control plane, execution side, and capability unit already have baseline boundaries, so expanding later to APIs, templates, Agent paths, and more asset types costs less.
Next Read
After architecture, move into delivery details
What usually turns architecture into real project material is not repeating concepts. It is explaining the file path, deliverables, and onboarding boundary clearly together.