One current movement.
The selected object, purpose and boundary are visible before action begins.
Common operating metakernel
MMK — MetaMasterKernel.
Keeps a common direction across intent, work fronts, capabilities and results while applications, models and projects can change.
MMK is an operating form developed through three years of daily use. Its first private incarnation lives in the local TM9 kernel, while MMK identity remains distinct from the application, model and executable version that incarnate it. It is not an installable repository or a central authority: every project, runtime and surface retains its own sources and gate.
SystemFront Aown state
InstanceSession Bbounded task
SystemFront Cdifferent capabilities
ProjectSituated Kernelown boundary
common metakernelMMKorients and coordinates
common directiondistinct responsibilities
Reason
Coordination must survive the passage between sessions and instruments.
When an activity passes between applications, models, instances or people, each passage can have different tools and state. MMK keeps a common operating frame: intent, responsible owner, involved capabilities and returned result.
ASystemlocal state
BInstanceactive task
CProjectown boundary
MMK
- intent
- responsibility
- return
Operating relation
When multiple systems or instances must participate in the same work.
MMK coordinates the passages without absorbing the work: each system keeps its own state and every movement stays assigned to a recognizable responsible owner.
SystemFront Aown state
InstanceSession Bbounded task
CapabilityTool Cselected function
MMK
N0situated stewardship
Selected workowner and boundary
- 01Source and intent
The operator signal and verified content identify the work.
- 02Active front
The current work is bounded before adjacent surfaces enter.
- 03Responsible instance
One owner acts for the front with explicit authority and boundary.
- 04Selected faculties
Skills, completeness and tools serve the work that requires them.
- 05Result and re-entry
The useful result, evidence and next state return to the project.
Operating relation
MMK, MAIOS and RepoKernel perform different functions.
In the current composition, MMK understands and orients the movement; MAIOS governs, operates and learns in the user’s system; RepoKernel compiles a bounded portable form for an individual project. This is a relation between functions, not repository ownership or containment.
One explicit owner.
Coordination does not silently transfer authority between instances or projects.
Capabilities enter by function.
Their availability does not imply activation; the selected front determines their role.
State returns to its source.
Result, evidence, boundary and next state remain readable after the handoff.
Current state and boundary
First private incarnation; no background authority.
MMK has a locally verified operating grammar and contracts. Other hosts require their own adapters and evidence; the local incarnation does not establish universal availability.
Boundary. MMK does not run in the background, observe every system, impersonate the operator or gain material authority by proximity. A selected action still requires a separate owner, evidence, authorization, validation and receipt.