How the layer works
Nothing moves without a record, an owner and a route.
We assemble records, work queues, permissions and handoffs around the specialist systems you keep, or stand up a complete environment where there is none. Either way your team can answer where anything is from one place.
This page is how work moves through the layer. What we deploy is what the layer is made of: the same five drawn here, drawn in full. The Blueprint shows you what changes, what stays and which responsibilities remain with you, before anything is built.
How work moves
The normal route and the exception route are both visible.
Every request gets a record, an owner and a next action, so you stop asking who has it. Anything outside the usual path goes somewhere visible, not into an inbox.
- 01Request enters
- 02Record created
- 03Owner and next action assigned
- 04Handoff recorded
What the layer includes
Records, work and authority, connected.
A component earns its place only when its role in the flow is clear. These five are what let you see, run and change the work without us. They live in the applications and automation layers of the environment, whether we lay them over the systems you keep or stand up the whole stack.
- Operating records
- The agreed fields, states, owners and decision history for the work in scope, in one place.
- Work queues
- Visible next actions and exceptions, instead of routing that lives in inboxes and heads.
- Permissions
- Who can see and do what, written down as roles and agreed before anything is built.
- Handoffs
- Named triggers and owners between the systems you keep and the records that connect them.
- Bounded automation
- Specific rules with a visible failure route and a person at every decision point.
Shared or dedicated
Shared by default. Dedicated when your requirements justify it.
Shared, the default
Managed shared infrastructure
Managed shared infrastructure is the efficient default where it fits. You operate through your own controlled accounts, workspaces, permissions and data structures inside the managed foundation, and we keep the foundation running.
- Common managed operating foundation
- Your records, permissions and handoffs
- Responsibilities stated on both sides
Dedicated, when justified
Dedicated or white-label infrastructure
A separately scoped path, for isolation, branding, security, integration, contractual, compliance, migration or support requirements the shared model cannot meet.
- Its own architecture and commercial scope
- Dependencies and responsibilities written down
- Agreed on its own, not inherited
Who does what
Deployment builds the layer. Some duties stay with you.
The agreed scope names what we perform and the decisions, access and duties that remain with you or a third party, so nobody discovers a gap later. Nothing transfers by default.
| Operating area | ScalePass does | You keep |
|---|---|---|
| Operating design | Document the agreed records, states, routing and control points. | Confirm the business rules and name the accountable owners. |
| Implementation | Configure or build the agreed scope and show that each check passes. | Provide the access needed and sign off the results. |
| Managed infrastructure | Run the technical services in the agreed scope: hosting, monitoring, backups, maintenance and updates. | Keep the duties that were not handed over in that scope. |
| Operational decisions | Route exceptions to the person you named. | Make the regulated, commercial and policy decisions. |
The accepted scope is fixed before build begins. If something material changes, it goes back through scope review first. See how the phases run
Start
Define the operating scope before choosing the technical change.
Describe the records, owners, handoffs and exceptions your work depends on. The free audit tells you which layer is worth building first.