Skip to content

Hot Update

Hot Update

Controlled UpdateHot update does not mean a customer ships directly around the platform. It means a capability becomes effective in the current tenant only after review, registration, and authorization.

This page exists so presales, delivery, training, and customer discussions can all quote the same explanation.

ExecFabric already supports customers continuing to add or update script-based capabilities without redeploying the whole platform. But that path is still a controlled update, not an open self-serve release flow.

review and syncregister and authorizetenant isolationcontinuous delivery
EXECFABRIC // HOT UPDATEDOC 09
const updateFlow = ['review', 'sync', 'register', 'authorize']const scope = 'current_tenant_only'const publishMode = 'controlled'
UPDATE WITHOUT BREAKING TENANT BOUNDARY

What It Means

What hot update currently means

  • Adding a new script or a new script version does not require redeploying the whole platform
  • The platform still keeps control over review, sync, registration, and authorization
  • The updated capability becomes effective only inside the tenant it belongs to
  • AI recommendation scope is still constrained by tenant boundary and permission

What It Is Not

What hot update does not mean

  • It does not mean customers can ship directly around the platform
  • It does not mean an update is automatically opened to every tenant
  • It does not mean the browser reads a local folder or intranet path directly
  • It does not mean the platform has already become a fully self-serve capability marketplace

Hot Update Flow

How customer script hot update works

1. Prepare the script folder

Prepare the folder according to the agreed structure. At minimum it should include the entry script and README.md. The current default entry files for Python and Shell text scripts are main.py and main.sh.

2. Submit it into the tenant boundary it belongs to

The customer places the script into their own tenant directory. Different customers cannot mix directories, and public/ is maintained only by the platform.

3. Platform review

The platform confirms which tenant the script belongs to, whether AI can call it, whether manual execution is allowed, and whether manual confirmation is required.

4. Sync into the execution directory

The runtime uses controlled relative paths rather than arbitrary absolute paths outside the managed script workspace.

5. Finish registration and authorization

The platform completes script registration, script-version registration, Skill association, Skill-version registration, and tenant authorization binding.

6. Become formally available after permission checks

The platform verifies that the capability is visible and executable in the current tenant, invisible elsewhere, and not leaking across AI recommendation boundaries.

Hot Update Submit

What customers usually submit in one hot-update request

Submitted itemRequiredPurposeNotes
Script filesRequiredThe real execution contentAt minimum include the agreed entry file. Today the default for Python and Shell is main.py or main.sh.
README.mdRequiredUsed for platform review and later maintenanceIt should explain purpose, input, output, prerequisites, and whether files are generated.
Owning tenantRequiredDetermines the final authorization scopeDifferent customers cannot mix directories or authorization.
Business-scenario descriptionRequiredHelps the platform judge naming and integration methodIt should explain what problem the script solves and who will use it.
Whether AI can call itRecommendedDetermines whether the intelligent brain may recommend itNot every script enters AI recommendation scope by default.
Whether manual execution is allowedRecommendedDetermines whether the page opens a manual entryThis can be controlled separately from AI invocation.
Whether manual confirmation is requiredRecommendedControls the confirmation step for higher-risk actionsThis fits capabilities that rewrite data or trigger external actions.

Why It Matters

What hot update really changes

  • The platform itself does not need to be redeployed
  • The current tenant can directly see the new capability or new version
  • Other tenants are not affected
  • The platform side still keeps control over review, registration, and authorization

Misunderstanding

Misunderstandings worth clearing up early

  • Hot update does not mean customers can publish directly around the platform
  • Hot update does not mean every update is automatically opened to all tenants
  • AI recommendation is still constrained by tenant authorization and does not cross tenants
  • Local execution needs usually go through the CLI / Agent bridge instead of exposing an intranet execution path directly

FAQ

The hot-update questions that come up most often

Will a hot update affect other customers

No. After the script update is complete, it is still registered and authorized only inside the tenant it belongs to. Other tenants do not automatically gain visibility or execution permission.

Can customers upload a script and push it live by themselves

Not by default in the current 1.0 scope. The platform still keeps the review, registration, authorization, and permission-check flow and does not support direct formal release around the platform.

Can AI recommend another customer's capability

No. Recommendation scope is constrained jointly by tenant and permission. AI does not recommend another customer's script or capability across tenants.

Can local scripts and intranet resources connect to the platform

Yes, but the usual path is not to let the browser touch a local path directly. It is to use execfabric-cli and the Local Agent direction as the bridge for local execution.

Next Read

Continue checking delivery, files, and onboarding prep together

During formal delivery evaluation, it is usually more useful to read customer flow, the file path, and the onboarding checklist together than to discuss hot update alone.

Crafting the unbreakable fabric of automation.