Customer Flow & Delivery
The customer path, the delivery boundary, and the update mechanism all need to be defined clearly if the project is going to run stably.
The most important questions ExecGov needs to explain first are what the customer receives, how the customer uses it, and how the platform delivers it. The script hot-update flow already has its own page. This page focuses on the standard team edition and enterprise delivery stage and explains what the real delivery path looks like end to end.
Delivery Package
The point is not just to hand over a backend account. The point is to deliver an isolated AI execution space that can run, update, and continue to expand for the customer.
Boundary
Shared SaaS Boundary
Standard SaaS customers can already enter through the shared-tenant frontend. Runtime isolation still happens through Host-to-schema binding, so each customer still sees its own menu, account space, capabilities, and data boundary.
This does not mean every customer owns a cloned frontend codebase. What is shared is the formal frontend package and release rhythm. Heavier customer-specific frontend work, branding, and deep customization still require formal iteration or separate delivery.
End To End
Confirm the business problem, the capabilities that need to be delivered, which tasks need AI recommendation, and which still need manual confirmation.
The platform opens a dedicated tenant, access URL, initial account, and permission boundary for the project.
The platform completes review, sync, registration, and authorization so the customer can see the first capability set immediately after login.
The customer either triggers capabilities manually through the page or describes the request in the intelligent brain, where the platform recommends capabilities inside the current tenant.
Based on results, announcements, and actual usage, the customer asks for script updates or new capabilities.
The customer supplements the script directory, README, tenant attribution, whether AI may call it, and whether manual confirmation is required.
The platform continues with review, sync, registration, version recording, authorization binding, and permission verification without redeploying the whole platform.
The updated capability becomes visible only inside the owning tenant. Other tenants do not gain visibility or execution rights, and AI recommendations do not cross tenants.
Delivery Checklist
| Delivery item | What the customer gets / sees | What the platform owns | Notes |
|---|---|---|---|
| Dedicated tenant | Their own tenant space | Create the tenant and isolate data plus permission boundaries | One customer, one tenant |
| Dedicated URL | Their own access entry | Open the access address and login entry | This is true for both single-tenant delivery and shared SaaS. Shared SaaS currently binds tenants by Host. |
| Login account | Account, initial password, or initialization method | Initialize the account and baseline permissions | Permissions are delivered per project |
| Customer-specific capabilities | The capability list visible inside the current tenant | Review, registration, and authorization binding | Not shared across tenants |
| Announcements and result viewing | Announcement entries, execution results, and related outputs | Announcement publishing, result display, and download-entry exposure | Always controlled by current tenant visibility rules |
| Hot-update notes | The onboarding process for new or updated scripts | Directory rules, review flow, and authorization rules | Review remains platform-controlled by default |
| Menu extension | Entries for existing pages, external links, or iframes | Configure the menu, validate boundaries, and control release rhythm | New formal frontend pages still require development, packaging, and deployment |
| Local hybrid execution | CLI / Agent is added when needed | Bridge capability is added according to project needs | Not included in every standard delivery by default. See the CLI Guide. |
Path Matching
| Current demand | Better-fit path | Current state | Notes |
|---|---|---|---|
| You want to feel the real execution chain first | Public experience page + signup / login | Available now | Useful for feeling AI recommendation, confirmation, execution, and result return before deciding whether formal delivery is needed. |
| You only want to keep onboarding scripts personally and have not entered multi-user collaboration yet | Start with local script-slot expansion under Billing & Membership | Available now | This is personal-space expansion, not the main formal team / enterprise delivery path of this page. |
| You already need multi-user collaboration, but the demand is still relatively standard | Standard shared-SaaS tenant path | The shared-tenant skeleton already exists and is still being tightened | This is a better fit for standard capability and lighter collaboration. Runtime still binds each tenant by Host and does not share data or permissions. |
| You already have a real customer and need formal go-live delivery | Single-tenant delivery | Mainline today | Best for customers that need stronger isolation, dedicated pages, custom branding, or formal acceptance. |
| You need to operate multiple customers in one platform | Platform governance + single-tenant delivery | Composable now | public owns governance while each customer tenant stays isolated and announcements, templates, logs, and ledgers are centrally managed. |
| The script depends on local environments or intranet data | Hybrid execution + the CLI / Agent path | Partially established now | The control plane stays on the platform side while the execution side is integrated per project instead of exposing the intranet path directly to the browser. |
| You want to buy a standard team product directly | Evaluate the shared-SaaS tenant path first, then check whether it is sufficient through Editions | The shared-tenant skeleton already exists and is still being tightened | If the need is mostly standard capability and light collaboration, shared SaaS should be tested first. If the work needs dedicated pages, branding, or stronger isolation, then move into single-tenant delivery or private deployment. |
Menu Rules
Customer Usage
After delivery, the customer receives an access URL, login account, and either an initial password or an initialization method. After login, they enter their own isolated tenant space.
Customers see the list of capabilities authorized inside the current tenant rather than raw script paths or another customer's data.
Customers can trigger a capability directly, or they can describe a request in the intelligent brain and let the platform recommend a capability inside the current tenant and permission scope.
Manual Run
AI Assisted
Notice & Result
Safety Rule
Local Execution
These scenarios are usually not handled by exposing an intranet directory directly to a web page. They are handled through the CLI / Agent bridge. The platform keeps the entry, planning, permission, and audit logic, while the local environment handles execution.
Who Owns What
Hot Update
The details of how a customer prepares a script directory, supplements submission information, enters review, completes registration, and goes live inside the current tenant have been split into a dedicated page so presales, delivery, and training can quote it separately.
Read directory preparation, review and sync, registration and authorization, and tenant-boundary activation in one place.
FilesFiles & ResultsBest for file-driven tasks where the user uploads input files, processes reports, and downloads result artifacts.
ChecklistOnboarding ChecklistBest for presales and implementation conversations that need the script directory, README, examples, and boundary information aligned in one pass.
Related Reading
Best for tasks that require file upload, report processing, or downloadable output artifacts.
DeliverablesDeliverablesBest when you need to define exactly which URL, account, instructions, and result entry the customer will finally receive.
ChecklistOnboarding ChecklistBest for presales and implementation conversations that need the script directory, README, example files, and risk boundaries aligned in one pass.
FAQ
Not necessarily. The better first step is to look at the data boundary, customer scale, and execution location, then decide between single-tenant delivery, platform-governance composition, or a hybrid-execution route.
No. Even after the update lands, the script is only registered and authorized inside the owning tenant. Other tenants do not automatically gain visibility or execution rights.
Not in the default 1.0 path. The platform keeps review, registration, authorization, and permission verification in place instead of allowing direct production publishing.
No. Recommendation scope is constrained by both tenant and permission boundaries. AI does not recommend another customer's scripts or capabilities across tenants.
Yes, but normally not by exposing local paths to the browser. The normal route is to use execgov-cli and the future Agent line as the local execution bridge.
No. They share the same trusted-execution foundation. What changes is the entry semantics, delivery boundary, and target user group.
Acceptance
One Sentence
ExecGov delivers more than a login entry. It delivers an isolated AI execution space that can run, update, and continue to expand for the customer. Hot updates are not platform redeploys, but formal review, registration, and authorization steps that take effect inside the current tenant.
Next Read
Continue with Capabilities, Deployment, and Architecture. If you already have real script capabilities and a real customer scenario, bring the directory structure and requirements directly into the conversation.