Stabilize onboarding, execution, audit, and delivery first, then expand toward more capability types.
Product Overview
Product Overview
Product SignalStabilize a real execution chain first. Expand the boundary later.
Separate what is already real, what is still in progress, and what may expand later. That is how you avoid rework.
ExecGov turns scattered and risky scripts and automations into a governed entry point: you can trace who ran what, when it happened, and what the result was.
ExecGov is a multi-tenant governance and execution platform that treats Python scripts as the first mature execution asset.
Starting with Python scripts does not mean the scope is small. It means that Python is the most common, most real, and fastest way to create governance value right now.
Python scripts are the most mature execution asset today, but the long-term object of management is a standardized, schedulable, auditable capability unit, not just one type of script file.
This is no longer a concept-only story. The platform has already completed its first compatibility upgrade: it now has a general resource layer and an executor registry layer, and the first non-script sample, HTTP capability access, has already landed in the public super-admin domain. Tenant-side users can already see a read-only ledger that exposes the HTTP resources they are authorized to view, including authentication style and write boundaries. That still does not mean tenants can fully self-serve arbitrary capability onboarding, and it definitely does not mean the product has become a generic API platform. Resource configuration, credential governance, and dry-run verification remain inside the public governance domain for now.
This implementation round also tightened the security boundary: the whitelisted tenant admin now keeps only a minimal cross-tenant console entry, and will not directly see platform-governance pages such as HTTP capability access. The runtime, menus, and permission 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 low-support commercial loop has landed: the public order center already supports order creation, payment confirmation, activation execution, renewal reminder scans, and expiry shutdown scans. The personal free edition also already includes a lightweight self-service purchase path for local script slots, but it should still not be described as a fully finished payment center. Real third-party payment gateways, a user-facing billing center, and outbound reminder channels are still being added.
The shared-SaaS tenant frontend has also been established: from tenant_1003+ onward, standard SaaS customers no longer default to cloning a dedicated frontend project per customer. They first go through the shared tenant frontend instead. That frontend can already accept formal tenant entry, but branding, initialization, and finer menu boundaries are still being tightened.
Multi-tenant governanceGoverned executionFree public entryCLI / Agent pathHTTP sample landedShared SaaS
EXECGOV // 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 is what keeps later expansion from becoming a rewrite.
If you are testing whether this platform is still only conceptual, start with the four points below. They map to real chains that already exist or are being used, not distant imagination.
Public entryRun one real execution chain from the no-login experience page
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 already landedStandard team pathThe shared-SaaS tenant frontend exists, and the product no longer defaults to cloning a new frontend project per customer
Platform
Platform position
- ExecGov is a multi-tenant governance and execution platform that treats Python scripts as the first mature execution asset.
- The most mature capability shape today is script onboarding, execution, audit, and continuous update.
- The platform already has a general resource layer and an executor registry layer. The first non-script sample is HTTP capability access inside the
publicsuper-admin domain, and tenants already have a read-only ledger for visibility. - HTTP resources are currently advanced only as fixed interfaces with explicit authentication and a write whitelist. Configuration authority remains in the
publicdomain, and the product is not being packaged as a general API platform. - The first part of the
1.1order and lifecycle skeleton has landed in thepublicdomain, and the personal free edition already has a lightweight self-service local-slot purchase path, but the platform still does not publicly claim a complete self-service payment center. - From
tenant_1003+onward, standard SaaS customers first go through the shared tenant frontend. Stronger isolation or deeper customization can still move into single-tenant delivery or private deployment later. exec-gov-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 when real demand justifies it.
Current Paths
The four external paths that are currently more 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 using scripts continuously in their personal space | This is personal-space expansion, not a formal team subscription | Billing & Membership |
| Standard team edition | Teams entering multi-user collaboration | Currently handled through the shared-SaaS formal tenant entry rather than a dedicated frontend clone | Customer Flow / Delivery |
| Enterprise delivery | Customers who need stronger isolation, intranet deployment, or formal project acceptance | Continue into single-tenant delivery, private deployment, or deeper deployment control | Deployment |
Brand
Brand language
- Brand name:
ExecGov - 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
ExecGovexternally as one unified brand instead of splitting into separate English project and Chinese product names. - Governance first, execution second. Stabilize script-shaped capabilities first, then expand into more capability types.
- The repository slug and directory path
execgov-cli/stay in place for now, while the external command is already unified asexecgov-cliso the current engineering and release chain is not disrupted. - This keeps brand recognition consistent without breaking code, docs, or delivery momentum.
Not Building
What the platform is not trying to be right now
Not an unconstrained chat system
The focus is not just exposing a model. It is making real tasks execute inside rules.
Not a trimmed-down enterprise admin panel
The free edition does not simply expose a complex backend menu. It is meant to be a lighter formal entry with room to grow.
Not a demo-script assembly site
The goal is real delivery, platform governance, and sustained maintenance, not a temporary script gallery.
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 questions. It must execute real tasks under confirmation and rule constraints instead of calling scripts with uncontrolled privilege.
Continuous product entry
The personal free path, formal delivery, and local bridge should form one continuous journey rather than three disconnected systems.
Future Asset Types
Which capability types are likely to be added next
The items below show where the platform is likely to expand next. They are expansion boundaries, not promises that every item is fully commercialized today.
API / SaaS calls
Turn third-party services, internal enterprise interfaces, and webhooks into governed capability entry points. The first sample already exists as HTTP capability access in the public governance domain.
Data connectors
Turn database queries, warehouse writes, and CRM / 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, ticketing, and status transitions into auditable capability actions.
Specialized model services
Bring OCR, document parsing, speech recognition, and image generation into the same governed execution chain.
Ops and notification actions
Continue bringing high-frequency actions such as inspection, alerting, log cleanup, backup, and notification sending into the trusted-execution range.
How To Start
Where different roles should start
Individual explorers
- Start with the no-login experience page and feel one real execution chain quickly.
- After signup, enter the personal intelligent execution console and continue through the capability library, script upload, announcements, personal space, and community square.
- If you only want to continue as an individual, prioritize lightweight local-slot expansion instead of jumping straight to the enterprise-delivery narrative.
- This is the right place to verify whether AI can really help schedule your scripts.
Teams and enterprises
- If you only need standard capability and lighter collaboration, evaluate the shared-SaaS tenant path first.
- If your focus is standard team collaboration, start with the formal tenant entry for the team edition instead of jumping straight into an enterprise project.
- If you need multi-user collaboration, permission control, audit, or local integration, 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 operational-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 capability path and the fastest to feel the value of a unified entry and execution audit trail.
Technical teams doing script governance and automation ops
These teams naturally understand the value of CLI, local execution, permission boundaries, and audit trails, which aligns with the platform's most mature capability today.
Small formal customers that need intranet access or private deployment
These customers validate multi-tenant isolation, platform governance, and the formal delivery chain most clearly, but customization depth still needs to be controlled so the work feeds back into the platform instead of forking it.
Reading Order
Public documentation reading path
Step 01Scenarios
Start with the real business scenarios this platform solves instead of memorizing module names.
Step 02CapabilitiesThen understand how multi-tenancy, governed execution, template distribution, announcement governance, and the CLI bridge form one loop.
Step 03Customer Flow / DeliverySee directly how customers use the platform, how delivery works, and how script hot updates currently close the loop.
Step 04Billing & MembershipSee separately how the personal free page handles payments, how the team edition is registered, and how complete the payment line really is today.
Step 05ArchitectureUnderstand how the backend, the super-admin domain, the free edition, the delivery frontend, and local integration fit together.
Step 06CLI GuideLook directly at the current 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
Useful for file-driven tasks, report artifacts, and jobs that need batch status visibility. It explains the input-file and output-file path clearly.
DeliverablesDeliverablesUseful for formal delivery discussions when you need to clarify which entry points, instructions, and result artifacts the customer will actually receive.
ChecklistOnboarding ChecklistUseful for presales, implementation, and the customer to align script directories, README files, examples, dependencies, and risk boundaries.
Why ExecGov
Why this kind of platform matters
- The goal is not just to expose a model. It is to make AI execute inside rules.
- The goal is not a one-off demo. It is a system that keeps accumulating capability assets, processes, and audit trails.
- The personal free path, formal delivery, and local bridge can all share one trusted-execution foundation.
- The platform supports a web entry, local script onboarding, and a path toward broader capability bridging.
Good Fit
Who it fits today
- E-commerce, content, and operations-data automation teams
- Technical teams that need script governance and automation ops
- 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 you should stay on the free path, expand local script slots, move into the standard team edition, or go into enterprise delivery.