Wrapper layer
Entry layer
A request enters from chat, UI, API, automation, or another trusted system trigger. The wrapper exists so this request does not go straight to execution.
Wrapper
The wrapper is the control layer between a request and real movement.
In ChipOS, the wrapper is what turns a prompt, task, or trigger into governed action. It binds identity, workspace ownership, policy, approval, routing, and return before any runtime, model, or connector is allowed to move.
What it is
The wrapper is not a plugin. It is the governing shell around all serious movement.
Without the wrapper, Chip is only interface plus model access. With the wrapper, every serious task has to cross the same shell of ownership, consent, decision, execution, and return.
01
The wrapper is the control layer between a request and real movement.
02
It binds who is speaking, which workspace owns the task, what policy applies, what approval is required, and which lane may execute the work.
03
It keeps external runtimes, models, and connectors inside one governed shell instead of letting each of them invent its own rules.
04
It returns result, residue, proof, and operator trace back into the owned system instead of leaving value scattered across temporary tools.
How we build it
We build the wrapper in layers so identity, law, and execution do not collapse into one vague step.
The main design choice is separation: entry, identity, policy, decision, runtime bridge, and return each stay explicit, so the system remains inspectable as it becomes more capable.
Wrapper layer
Identity and ownership layer
Before Chip can decide anything, the system binds actor identity, workspace ownership, role, request identity, and any delegation or approval context.
Wrapper layer
Policy and consent layer
The wrapper checks what the system may do, what requires approval, what should be refused, and what must remain inside a safer boundary.
Wrapper layer
Decision and routing layer
Chip decides whether work should be denied, deferred, reviewed, or routed into a specific execution lane. This keeps judgment outside the raw runtime call.
Wrapper layer
Runtime bridge
Only after those checks does the wrapper hand the task to a model, tool, adapter, or external runtime through a smaller contract surface.
Wrapper layer
Return layer
When work completes, the wrapper brings result, audit trace, approval state, residue, and reusable memory candidates back into the system.
Why we build it this way
The wrapper exists to keep Chip ownable, reviewable, and composable.
A useful system has to be more than a smart call. It has to keep one law across many surfaces, preserve ownership across many adapters, and make future memory possible instead of throwing each task away.
Design principle
Identity before action
Chip should not act until it knows who is asking, which workspace owns the task, and what authority exists in that context.
Design principle
Decision before execution
The wrapper should decide what kind of movement is allowed before a runtime starts improvising with tools, models, or connectors.
Design principle
One shell around many engines
Different models and execution lanes can exist, but they should cross one policy and consent boundary instead of becoming separate hidden systems.
Design principle
Return before forgetting
A task should not vanish when it finishes. The wrapper should keep the residue that matters and decide what becomes audit, memory, playbook input, or reusable capability.
Before install becomes movement
The wrapper also has to know whether the machine in front of it is the real target.
This control logic starts before runtime. If the user asks for deployment, ChipOS should first confirm which environment is actually intended. It should branch cleanly into local, cloud, own-server, or guided setup until the real target is explicit.
Control branch
Local branch
If the current machine is meant to stay local, the wrapper should keep the task in the local branch and make the preview boundary explicit instead of pretending local always means production.
Control branch
Cloud or hosted branch
If the real target is a cloud or hosted machine you control, the wrapper should bind that environment clearly and treat it as a real hosted branch instead of collapsing it into a generic server fiction.
Control branch
Own server or guided branch
If the target is your own server, the wrapper can continue with real deployment. If the details are not ready yet, it should pause and collect the minimum guided-handoff context instead of improvising on the wrong machine.
Decision before movement
Before Chip can make a decision, it has to know who is speaking and what boundary it is inside.
This is the center of the wrapper. The system should bind identity and ownership first, then judge whether the requested movement is allowed, useful, and safe enough for the chosen lane.
Core distinction
The runtime executes. The wrapper decides what the runtime is even allowed to touch.
01
Receive the request through a trusted surface and confirm the target environment.
02
Branch honestly between local, cloud, own-server, or guided setup before treating the task as real production movement.
03
Bind actor, workspace, request identity, and role.
04
Load policy, rights, and approval requirements.
05
Choose deny, defer, await approval, or dispatch.
06
Select the execution lane that matches risk, cost, and readiness.
07
Collect result, side effects, proof, and residue.
08
Return what matters into task history, operator visibility, and reusable system memory.
Return and memory glue
The wrapper should not only send work out. It should decide what comes back and what stays.
This is where the wrapper becomes more than orchestration. It creates the glue between action, audit, memory, approval history, and future capability.
Why this matters
A system that never keeps useful residue is forced to pay again and again for the same intelligence.
Return layer
Task ledger
Every serious task needs a durable row or record that keeps identity, policy, route, approval state, and current status together.
Return layer
Event history
The wrapper should keep a lifecycle trail so operators can see not only what state the task is in, but how it reached that state.
Return layer
Approval memory
Approval should not be invisible. The system should keep who approved, what was approved, when it was approved, and what token or proof path made the action valid.
Return layer
Result and proof
A completed task should return more than text. It should return summary, structured proof, audit payload, and the reason the route was allowed.
Return layer
Residue promotion seam
Not every outcome becomes long-term memory, but the wrapper should create the seam where useful residue can be promoted into memory, playbooks, and reusable skills.
Return layer
Operator visibility
The wrapper should feed cockpit, audit, denial history, pending approvals, and recovery views so the system stays understandable while it grows.
Runtime boundary
Models, runtimes, and adapters belong below the wrapper, not above it.
ChipOS can use different models, different tools, and different external systems. The wrapper is what keeps them under one contract and one law instead of turning the system into many hidden products.
Boundary rule
Runtime contracts stay small
The runtime should receive a smaller, normalized task shape instead of the full uncontrolled application state.
Boundary rule
Signing and verification matter
When the wrapper crosses into a separate runtime or adapter, the handoff should be signed and the return path should be signed too.
Boundary rule
Connectors stay below the wrapper
Publishing, messaging, browsing, and other adapters should not bypass policy or consent just because they are useful.
Boundary rule
Multi-model does not mean multi-law
ChipOS can use different models and tools, but they should still operate under one governing shell.
One current implementation
Nessha is one reference implementation of this wrapper pattern.
The public definition of the wrapper should stay general. Nessha is useful because it shows how this pattern can be implemented today with real identity binding, approval, signed runtime dispatch, callback verification, and audit return.
Current truth
The pattern is broader than Nessha. Nessha is simply the clearest current proof that the wrapper should be built as a real control plane, not a metaphor.
Nessha is one current implementation of this wrapper pattern, not the wrapper definition itself.
In Nessha today, the wrapper already binds identity context, workspace ownership, approval, route arbitration, signed runtime dispatch, signed callback return, and durable audit trace.
What Nessha still shows clearly is where the design needs tightening next: policy version sync on the explicit UI path, approval-token recovery after refresh, and one remaining workspace/org drift edge.
That is exactly why the public page should explain the wrapper as a general ChipOS pattern first, then use Nessha as one concrete implementation example.
Next step
Read the model, then inspect the shell that keeps the model honest.
The model explains what Chip is. The wrapper explains how ChipOS binds identity, policy, approval, execution, residue, and return before movement becomes real.