Stabilize onboarding, execution, audit, and delivery on the main chain first, then gradually expand into more capability forms.
Product Overview
Product Overview
Product SignalExecFabric is aimed at automation execution and governance for real tasks. Right now it is better understood from script governance, file handling, and local automation flows that can already land.
Separate what is already done, what is still being pushed, and what may expand later. That is how the product avoids rework.
The current best way to understand ExecFabric is this: it first turns Python and Shell scripts, file handling, and local automation flows into one unified entry so execution, confirmation, and result return are all traceable.
Under the surface, ExecFabric is still a multi-tenant governance and execution foundation that treats Python scripts as the first mature execution asset.
Starting with Python scripts does not mean the scope is small. It means Python is the most common, most real, and easiest place to form a deliverable, reusable, expandable small closed loop first.
The most mature execution asset today is still the Python script, but the long-term object under platform management is a standardized, schedulable, auditable capability unit rather than just one type of script file.
This is no longer only a concept story. The platform has already completed its first compatibility-oriented upgrade: it now has a general resource layer and an executor registry layer, and the first non-script capability sample, HTTP capability access, has already landed inside the public super-admin domain. Tenant-side users also already have a read-only ledger where they can see the summary of the HTTP resources they are currently authorized to view, the authentication style, and the write boundary. That still does not mean tenant-side self-service onboarding of multiple capability types is fully open, and it definitely does not mean the product has already become a generic API platform. Configuration, credential governance, and dry-run for this type of resource still stay inside the public governance domain.
This round also tightened the security boundary further: whitelisted tenant admins keep only a minimal cross-tenant console entry, and do not directly see platform-governance pages such as HTTP capability access. Menus, permissions, and runtime checks also no longer rely on unsafe conditions such as user_id == 1 to infer administrator status.
At the same time, the first segment of the 1.1 lower-support loop has already landed: the public order center already supports order creation, payment confirmation, activation execution, renewal-reminder scans, and expiry-shutdown scans. The personal free frontend already has the first version of the local script-slot billing center, where users can see the current order, lifecycle summary, reconciliation summary, recent callbacks, and the checkout entry. Real third-party payment gateways, auto-renewal or auto-charge, and outbound reminder channels are still being filled in.
At the same time, the shared-SaaS tenant frontend skeleton has already been built: from tenant_1003+ onward, standard SaaS customers no longer default to cloning one new frontend project per customer. They first go through the shared tenant frontend instead. It can already carry the formal tenant entry, but branding, initialization, and finer menu boundaries are still being tightened.
multi-tenant governancetrusted executionfree-path entryCLI / Agent pathHTTP sample landedshared SaaS
EXECFABRIC // PRODUCT SIGNALDOC 01
const corePosition = 'controlled_ai_execution_platform'const userPath = ['free_entry', 'local_slots', 'team_saas', 'enterprise_delivery']const executionSurface = ['web_console', 'cli_bridge', 'local_env']
REAL EXECUTION / CLEAR POSITIONING
The free experience, tenant governance, and formal delivery already share one foundation. That keeps later expansion from turning into rework.
If you are trying to judge whether the platform is still only conceptual, start with the five points below. They correspond to chains that already landed or are already in real use, not distant imagination.
Public entryRun one real execution chain from the no-login experience page first
Mature assetPython scripts are already the first onboardable and auditable execution asset
Governance sampleHTTP capability access already landed inside the
public governance domainLifecycleThe first segment of the
1.1 order, activation, renewal, and shutdown skeleton has landedStandard team pathThe shared-SaaS tenant frontend already exists and no longer defaults to cloning one new frontend per customer
How To Read It
How this product should be understood in the current stage
- Start with how it turns scripts, file handling, and local flows into a unified entry.
- Start with the execution, audit, permission boundary, and result-return chains that have already landed.
- Then move into how it expands toward team collaboration, shared SaaS, and private delivery.
- Judge fit through a real scenario first, then decide the implementation path and edition choice.
What To Watch
Do not skip these boundaries during evaluation
- Do not treat payment and the full SaaS self-serve loop as fully mature when they are still being filled in.
- Do not ignore the fact that the HTTP capability sample still mainly stays inside the
publicgovernance domain. - Do not mix shared SaaS, single-tenant delivery, and private deployment into one delivery mode.
- Do not stay only at the concept layer. It is better to judge fit through a real scenario.
Platform
Platform position
- Under the surface, ExecFabric is a multi-tenant governance and execution foundation that treats Python scripts as the first mature execution asset.
- Externally, it is currently better to enter from script governance, file handling, and local automation flows that can already land.
- The most mature capability shape today is script-shaped onboarding, execution, audit, and continuous update.
- The platform already has a general resource layer and executor registry layer. The first non-script sample is HTTP capability access in the
publicsuper-admin domain, and tenant-side users already have a read-only ledger. - HTTP resources currently move only through "fixed interfaces, explicit authentication, and write whitelists." Configuration authority remains on the
publicside, and this is not being packaged as a generic API platform. - The first segment of the
1.1order and lifecycle skeleton already exists on thepublicside, and the personal free frontend already has a real first-version billing center. That still does not mean the product publicly promises a complete general subscription or auto-renewal capability. - From
tenant_1003+onward, standard SaaS customers currently go through the shared tenant frontend first. Stronger isolation or deeper customization can still move into single-tenant delivery or private deployment later. execfabric-shellis mainly used for multi-entry aggregation, joint debugging, and sync. It is not the long-term formal runtime entry for customers.- The platform may later expand into APIs, templates, connectors, approval flows, and other capability types, but only step by step under real demand.
Current Paths
The four external paths that are currently the most stable
| Layer | Best for | How to understand it today | Suggested entry |
|---|---|---|---|
| Free path | People touching the platform for the first time | Feel the product position, execution chain, and personal-entry value first | Getting Started |
| Local script-slot expansion | People already continuing to connect scripts in personal space | This is personal-space expansion, not a formal team subscription | Billing & Membership |
| Standard team edition | Teams entering multi-user collaboration | Currently carried by the shared-SaaS formal tenant entry instead of cloning a new frontend project by default | Customer Flow / Delivery |
| Enterprise delivery | Customers that need stronger isolation, intranet access, or formal project acceptance | Continue through single-tenant delivery, private deployment, or deeper deployment control | Deployment |
Brand
Brand wording
- Brand name:
ExecFabric - Subtitle: a multi-tenant governance and execution system for real-world tasks
- Slogan: make every automation reliable and governed.
- This framing is suitable for product introduction, scenario communication, and current delivery explanation.
Method
Current usage principles
- Use
ExecFabricexternally as one unified brand rather than splitting into separate English and Chinese product naming tracks. - Governance first, execution second. Stabilize script-shaped capability first, then gradually expand into more capability types.
- The repository slug and directory path
execfabric-cli/stay in place for now, while the external command is already unified asexecfabric-cli, so the current engineering and release chain is not disrupted. - This keeps brand cognition unified without interrupting the current code, docs, and delivery rhythm.
Not Building
What the platform is not trying to become right now
Not a free-form chat system
The point is not just to expose a model. The point is to let real tasks execute stably under rules.
Not a trimmed enterprise admin panel
The free edition is not simply a complex backend menu made public. It is meant to be an independent, lighter, formal entry with room to grow.
Not a demo-script assembly site
It has to carry real delivery, platform governance, and continuous maintenance rather than a temporary collection of scripts.
Core Problems
What the platform is solving right now
Isolation for formal customers
Different customers, teams, and environments cannot be mixed together. They need an execution platform that can isolate, govern, and keep delivering over time.
Trusted AI execution
AI must not only answer. It has to execute real tasks under confirmation and rule constraints instead of calling scripts with uncontrolled privilege.
Product entry continuity
The personal free path, formal team collaboration, and enterprise delivery need one continuous journey rather than three disconnected systems.
Future Asset Types
Which capability types are likely to be added next
The directions below show where the platform is likely to expand next. They describe the expansion boundary, not a promise that every item is already fully commercialized.
API / SaaS calls
Turn third-party services, internal enterprise interfaces, and webhooks into governed capability entries. The first sample already exists as HTTP capability access in the public governance domain.
Data connectors
Turn database queries, warehouse writes, and CRM or ERP read-write operations into standardized capability units.
Document-template services
Bring contracts, reports, weekly summaries, and standard document-generation flows into one unified execution entry.
Approval / workflow triggers
Turn leave requests, procurement, tickets, and status transitions into auditable capability actions.
Specialized model services
Bring OCR, document parsing, speech recognition, image generation, and other model capabilities into the same governance chain.
Ops and notification actions
Continue bringing inspection, alerting, log cleanup, backup, and outbound notifications into the trusted-execution range.
How To Start
Where different roles should start
Individual explorers
- Start from the no-login experience page and feel one real execution chain quickly.
- After signup, users first go through the separate result page and then enter the personal path. The current valid menu set continues through My Skill Library, Script Upload, Intelligent Assistant, Execution History, Personal Space, Announcement Center, Community Plaza, and Upgrade to Formal Version, while keeping extension entries such as the HTTP read-only ledger.
- If the goal is still individual continuous usage, prioritize lightweight local script-slot expansion instead of jumping straight into enterprise-delivery framing.
- This is the right place to verify whether AI can really schedule scripts for me.
Teams and enterprises
- If the need is standard capability and lighter collaboration, evaluate the shared-SaaS shared-tenant path first.
- If the focus is standard team collaboration, start with the formal team-edition tenant entry instead of jumping directly into an enterprise project.
- If the need involves multi-user collaboration, permission control, audit, or local onboarding, continue the conversation around scenario and delivery boundaries.
- If intranet, compliance, or private deployment is involved, continue into the enterprise plan discussion.
- Clarifying the business scenario first is more effective than comparing feature tables first.
Priority Customers
The three customer groups that fit best today
E-commerce, content, and operations-data automation teams
These teams usually already have many scattered scripts, spreadsheets, and data-processing flows. They are the easiest fit for the Python-script path and the fastest to feel the value of one unified entry plus execution traces.
Technical teams doing script governance and automation ops
These teams are better prepared to accept CLI, local execution, permission boundaries, and audit trails, which matches the platform's most mature current capabilities.
Small formal customers that need intranet access or private deployment
These customers validate multi-tenant isolation, super-admin governance, and the formal delivery chain most clearly, but customization depth still has to be controlled so only platform-strengthening projects are taken.
Reading Order
Public documentation reading path
Step 01Scenarios
Start from the real business scenarios this platform solves instead of memorizing module names first.
Step 02CapabilitiesThen see how multi-tenancy, trusted execution, template distribution, announcement governance, and the CLI bridge form one closed loop.
Step 03Customer Flow / DeliveryLook directly at how customers use it, how delivery works, and how script hot updates currently close the loop.
Step 04Billing & MembershipSee separately how the personal free page handles payment, how monthly or annual team registration works, and how complete the payment line really is today.
Step 05ArchitectureUnderstand how the backend, super-admin domain, free edition, delivery frontend, and local onboarding fit together.
Step 06CLI GuideLook directly at the current landed boundary of login / register / list / run / agent.
See how the platform covers shared SaaS, single-tenant delivery, platform governance, the free public entry, and local hybrid execution.
Step 08Current StageFinish by looking at what 1.0 is doing now, what the next priorities are, and why the roadmap is intentionally not stretched too far yet.
Delivery Extension
When moving from experience to formal onboarding, add these three pages next
FilesFiles & Results
Best for file-driven tasks, report artifacts, and scenarios that need batch-state visibility. Start by making the input-file and result-file chain explicit.
DeliverablesDeliverablesBest for formal delivery discussion, where the customer needs to know which entry points, instructions, and result artifacts will actually be handed over.
ChecklistOnboarding ChecklistBest for aligning script directories, README files, sample files, dependencies, and risk boundaries together with presales, implementation, and the customer.
Why ExecFabric
The project value of this kind of platform
- The point is not to expose a model and stop there. The point is to make AI execute inside rules.
- The point is not a one-time demo. The point is a system that can keep accumulating capability assets, processes, and audit records.
- The personal free path, formal delivery, and local onboarding can all share the same trusted-execution foundation.
- The platform supports a web entry, local script onboarding, and a broader capability-bridging path that can continue later.
Good Fit
Who it fits today
- E-commerce, content, and operations-data automation teams
- Technical teams that need script governance and automation operations
- Smaller formal customers that need intranet deployment, private deployment, or stricter security boundaries
Next Step
Continue into product detail, or move directly into four-path lead routing
Continue with scenarios, CLI onboarding, and capabilities, or submit a lead directly to decide whether to stay on the free path, expand local script slots, move into the standard team edition, or enter enterprise delivery.