Let your project adopt OOP by copying this instruction into your AI tool:
execute https://github.com/organizationorchestrationprotocol/oop/raw/main/dist/entry.jsonThe AI is replaceable. Your organization is not. OOP supports long-lived work with AI without making your company, project or professional activity depend on one chat, one model, one vendor or one AI's memory.
OOP keeps your project from living only inside one AI's memory. It preserves the information needed to continue work in a standardized, machine-readable format with a verifiable structure, reduces unnecessary rework, and helps another compatible AI resume without depending on the previous AI's chat memory.
Some package properties can be checked automatically, but those checks do not prove that an AI has interpreted every rule correctly or safely carried out actions in a real environment.
It becomes useful when AI work stops being only a conversation and starts becoming ongoing organizational work.
OOP is a vendor-neutral operating protocol telling capable AI tools how to work on a long-lived project in a durable, verifiable and resumable way. It applies to companies, non-profits, independent professionals and autonomous projects.
Build a business that keeps its knowledge as your tools change. OOP explores Organization as Code: your goals, responsibilities, decisions and work become versioned information that people and compatible tools can inspect and continue. operations provides one canonical source of digital organizational knowledge, including references to authoritative systems you already use. That shared source uses CI/CD mechanisms and available automations to coordinate and synchronize the whole organization, following the domains affected by each task. From that foundation, AI is an external tool you can replace; your organization retains its knowledge and authority when a model or AI service is replaced or unavailable.
For the Solopreneur: bring product research, development, marketing, personnel needs and investor communication into one coherent picture, even when you wear several hats yourself. When a task needs several functions, OOP connects their dependencies so they can communicate, collaborate and create useful synergy. Coordination stays proportionate: a product description need not create departments or trigger an investor update.
For established and new organizations: the same rules preserve real managers, staff, boards, budget approvals, locations and authoritative business systems. A proposed structure stays a proposal until authorized, applied and verified. One person may cover several functions where policy permits; AI assistance never inherits that person's office or approval power.
Change once, coordinate the consequences. OOP uses CI/CD beyond software delivery to connect shared digital knowledge with the organization's actual work. CI checks a proposed change and identifies dependencies and inconsistencies. CD coordinates authorized updates, task-relevant communication and collaboration, then checks whether affected functions and systems agree with the canonical plan. Available automations can support these steps; approvals, human responsibilities and real-world constraints still govern execution. CI/CD here does not require a hosted pipeline or make every activity an automated deployment.
These short examples illustrate the proposed coordination model, not installed integrations. R&D, marketing, personnel and investor communication are one simplified example among many:
- A research result changes the roadmap: check launch, staffing and investor-message dependencies; coordinate approved product, marketing, personnel and investor updates; verify that they reflect the same roadmap.
- You change a price: check margin, tax and contract constraints; synchronize the authorized catalog, checkout and sales material; verify displayed prices and a permitted test transaction.
- A supplier slips a delivery: check stock, production and customer commitments; coordinate the revised plan and authorized notifications; verify schedules and track customer follow-up.
- Someone joins the team: check role, budget and access eligibility; coordinate approved onboarding, accounts and payroll instructions; verify scoped access and readiness with the responsible owners.
Only the functions required by the task participate. Synchronization may involve staged updates and human actions; unfinished differences remain visible and tracked. The commercial hypothesis is less manual chasing, fewer inconsistent promises and more useful synergy from the same shared knowledge.
The 60-second explanation: You tell the AI what you want. OOP provides rules and reference artifacts that help it determine which project it is in, which rules matter, what it may change, what must be verified and what must be preserved so another AI can continue later.
Where time and money may be saved: OOP aims to reduce organizational friction and avoidable AI-work cost. It may reduce time spent re-explaining a project, duplicated work across sessions or tools, mistakes from lost or stale context, avoidable rollback and rework, and human time spent reconstructing decisions, responsibilities and current state. Keeping work portable can reduce dependence on one AI vendor. Free-First / Zero-Cost Convergence can also avoid unnecessary SaaS and cloud spending; OOP does not directly generate profit or guarantee savings.
The commercial opportunity to explore: a Solopreneur could spend more time developing an offer, reaching customers and delivering value if less effort goes into reconstructing context and reconciling disconnected work. A growing organization could reuse the same knowledge across R&D, marketing, human resources and investor relations, potentially shortening handoffs and reducing conflicting messages. These are business hypotheses to test in practice; their value depends on adoption effort, actual integrations and measured results. OOP is a software engineering research and development project with a proposed path to commercial value.
OOP prefers capabilities you already have, local tools and free/open infrastructure before introducing paid services. It asks only for unavoidable meaningful decisions, remembers valid approvals for their exact scope and resumes authorized work after checking your answer. You do not need to choose cryptographic algorithms or automation internals; required identity and safety checks still apply. Real-world time and cost savings require observation.
For example: After three months with AI Tool A, you hit usage limits, change your subscription, prefer another tool or find Tool A unavailable. Without durable project state, you may have to rebuild the context, decisions, architecture, open work and constraints by hand. With OOP, AI Tool B reconstructs what it needs from durable project sources, verifies its own access and compatibility, and continues without depending on Tool A's chat memory. This can avoid hours of manual reconstruction and duplicated work; any benefit depends on the actual project and runtime.
How tools stay aligned: each compatible AI tool verifies its own private integration and adopted OOP revision. Updates use one migration contract for shared private data, the active tool and canonical operations. A tool checks work another actor already completed before reusing it, so a shared update does not silently upgrade every AI. Current compatibility instructions can cover supported prior states even after OOP history is amended or rewritten. These rules require actual runtime capabilities and evidence; package tests do not establish support by every vendor.
OOP helps when one or more of these describe your work:
- Work continues beyond one conversation, over days, weeks or months.
- Several AI tools contribute, or you want to change tool or vendor without rebuilding the project context manually.
- Decisions and approvals need to survive chat history and remain reconstructible for another human or AI.
- AI can make real changes to repositories, infrastructure or external systems, and verified progress needs to be distinguishable from plans and attempts.
- Session or context limits may interrupt active work, leaving a later session to continue.
One-off factual questions, translation, disposable brainstorming or a single draft or email with no durable state normally need little of this machinery. The same applies to tasks with no meaningful continuation or external consequence. OOP becomes relevant when the work itself needs to survive the conversation.
This compares chat-only work with work applying OOP; other workflows can also provide durable state and controls.
| Without OOP | With OOP |
|---|---|
| The chat may be the working memory | The project has durable state outside the chat |
| Decisions may live only in conversation history | Decisions and accountable state remain reconstructible |
| "Done" may blur plans, attempts and results | Desired, attempted, applied and verified remain distinguishable |
| Changing AI can require rebuilding context | Another capable, authorized and compatible AI can resume from durable state |
| Each AI may reconstruct the project differently | AI tools use the same protocol and canonical project state |
| Context exhaustion can break continuity | Continuation is prepared before the session becomes unusable |
OOP = how AI is expected to operate
operations = what the organization knows, has decided and is doing
.priv = private technical/runtime state for this project
AI runtime = a replaceable worker, with its own capabilities and authority
The detailed Where truth lives table below distinguishes these sources and their authority.
Company: "Launch a commercial offering." OOP helps a capable AI account for relevant work, dependencies, approvals, authorized execution and verification instead of treating the request as one isolated task.
Independent professional: "Deliver this client engagement." Decisions, deliverables, blockers and verified progress remain reconstructible across sessions.
Solopreneur: "Turn this prototype into a marketable offer." Link the research evidence and product work to the positioning, launch material and any relevant personnel or investor communication. Shared knowledge helps keep the offer coherent while AI tools remain replaceable. A shorter path to market is a potential benefit to evaluate.
Independent project: "Turn this idea into a usable product." Process and infrastructure stay proportionate while the project preserves durable work state.
Explore practical examples → for concrete prompts and fuller workflows, including hybrid organizations.
AI sessions are temporary. Organizations are not. Decisions, state, evidence, repository identity, authorization context, verification, next actions and handoff/recovery context need to survive outside the chat. Another human or AI should be able to understand what happened and continue without the original conversation.
The AI chooses the language for its replies in this order:
- your explicit instruction for the current scope;
- a reliable current preference shown by accessible earlier conversations;
- the presentation language of your user account;
- the presentation language of the app you are using;
- another valid saved language preference;
- the language of your own natural-language request;
- the generic runtime locale;
- the operating-system locale.
It checks only available authorized sources and explains material uncertainty without inventing access to your history or settings. A pasted command, such as the instruction at the top, is not a language choice. Some applications expose neither history nor language settings; the AI then records what it checked and uses an explained provisional fallback. You do not need to choose a language or fill in a questionnaire to proceed; saved operational documents stay in English.
New AI-created commits require the AI name ai-coworker and email [email protected]; genuine verified human authors keep their attribution, with the fixed AI committer. A push separately requires an authorized provider account mapped to ai-coworker, using eligible shared project credential references. The email spelling and Git configuration do not prove account ownership or permission. Existing valid credentials and historical commits stay in place. A shared worker name gives no additional repository access: each use still needs its own authorization and checks.
Creating automatic controls is an intermediate setup step. The AI continues available authorized work and reports readiness only after required checks pass. If it truly needs your input or a tool restart, it explains the exact action and preserves a continuation point; automatic resumption depends on the tool's actual capabilities. These are protocol requirements, not proof that every AI product implements them.
A capable AI can recover durable project state, understand work already in progress, identify relevant scope and dependencies, and determine what it is allowed to do. It preserves material decisions and accountable work, distinguishes attempted actions from verified outcomes, and leaves a continuation point for a later session or another compatible AI without rebuilding the project from scratch.
The AI must not behave correctly only because it happens to remember the right rules from earlier in the chat.
Under OOP, semantic judgment may depend on AI reasoning, but neither governance execution nor the availability and freshness of the normative context required for that judgment may depend on the AI remembering it.
Governance correctness must not depend on accidental conversation-context retention.
Conversation context is an execution cache, not a source of normative authority. Reopening an old chat, replacing a model or compacting context does not automatically preserve the right rules. The AI verifies current OOP and reloads only the missing or stale rules and facts it needs before continuing.
Where supported, a verified runtime can assemble small, up-to-date instructions for the current action from OOP and authoritative project state, while independently checking what effects the AI is actually permitted to perform. This reduces reliance on remembered chat context without pretending AI reasoning becomes deterministic. The runtime can reject unauthorized effects and verify outcomes through its real controls; unsupported paths and remaining semantic uncertainty must be disclosed. Unchanged verified rules and evidence are reused rather than rebuilt for every step.
Less repeated work, without fewer safeguards. When its AI tool supports the necessary controls, OOP can reuse rules and checks that are still valid instead of repeating them for every small action. The AI must still respect the authorization and safety checks for what it actually does. For example, preparing ten product descriptions can reuse the same approved constraints; publishing them requires the appropriate separate authorization. This can reduce wasted AI usage and rework, but actual savings depend on the tool and task.
You describe the outcome you want. A sufficiently capable, authorized AI checks the project and current rules, recovers relevant decisions and open work, performs and verifies the work, and preserves what another compatible AI needs to continue.
A reopened chat follows the same checks. The project's saved state carries continuity; remembering an earlier conversation does not establish that its rules are current.
OOP does not apply the same process to every task. Asking a question should stay simple. Changing production infrastructure calls for stronger controls.
Maximum rigor with minimum ceremony. Governance follows effective scope, risk and material consequences. A domain change may also require DNS, TLS, OAuth, email and monitoring work. G0–G4 define minimum controls; a level never grants authority. Small authorized reversible remote branch writes may stay G1: network transport alone does not make them controlled publication. Release publication, deployments and critical operations need their applicable stronger gates. Load required governance before effects; splitting a risky operation into subtasks cannot remove its safeguards.
desired ≠ approved ≠ attempted ≠ observed ≠ applied ≠ verified
For example, an AI running a deployment command does not prove that production is healthy. OOP keeps the attempted action, observed result and verified outcome distinct.
A successful command does not automatically prove the desired outcome. Evidence Compression reuses one durable authoritative object for the facts it actually proves. A PR can establish approval, CI and merge; production deployment still needs its own verification. Keep a minimal identified projection when portability, volatility, history or recovery requires it. Fresh material and verified claims need attributable observation time, checked identity, expected/actual result and a usable verification basis; lightweight work keeps lightweight references.
| Location | Contents and authority |
|---|---|
PROTOCOL.md |
Sole normative OOP authority, read in full by maintainers; AI tools using OOP read the derived distribution instead |
| README and examples | Non-normative explanations and illustrations |
| Derived artifacts | Distribution generated from canonical authority |
| Release evidence | Verified observations and provenance, never new semantics |
Consumer operations |
Canonical organizational knowledge, policies, decisions, accountable work state and history |
Project consumer .priv |
Private technical coordination for one project/workspace; authorized runtimes share only within that verified scope |
Runtime-specific .priv |
Tool-specific execution data and independent adoption checkpoints |
operations is the organization's documentary and operational brain: one logical canonical source of organizational knowledge and coordination across all relevant functions. It contains tool-independent knowledge and state, or canonical references to authoritative external sources of record; it does not require copying every business record into one repository. It supports analysis, decisions and authorized execution with verified outcomes. Runtime caches and chat history do not become competing knowledge authorities. Tool integrations, secrets and runtime configuration stay private. Free, open, local and portable solutions are preferred when adequate.
Project A: operations + .priv + project-local OOP/runtime state
Project B: operations + .priv + project-local OOP/runtime state
Project-local private/runtime state never crosses the boundary.
Each consumer project/workspace has its own logical private root, canonical operations state and OOP checkout. Runtimes can share project-private resources only within the same verified workspace. A project-agnostic global sentinel discovers current-workspace governance without carrying project state; supported runtimes apply the lightweight current-OOP gate on every interaction, reusing valid same-day context. Old chats receive no exemption.
Durable Git-backed ticket openings and state transitions are signed, signature-verified, pushed immediately and read back from the canonical remote before they are reported as canonical success. Users are notified when a ticket opens, at each state transition and when publication is blocked.
As a human, you do not need to learn the full protocol before using it. Start with the CTA above and describe the outcome you want. OOP is designed primarily for the AI runtime to read and apply. Use the practical examples to understand the workflow in concrete terms.
At the start of each full bootstrap, the AI explains the setup actions, what .priv and operations contain, how they are organized, what you can do after setup and which missing information or provider-side actions it may need from you. During every bootstrap action it briefly explains what it is doing and why, with a small practical example when useful. It asks only for information actually missing at that step, never private credential values.
The first time OOP is used with a new AI tool or environment, the AI may need to configure local automatic controls. Configuration and effective protection are separate: initial installation checks what was configured, while necessary evidence of protection is reused or established later before relying on it. This initial setup can require more work than normal project use. When those generic capabilities remain valid, later OOP projects in the same compatible environment should reuse them instead of rebuilding them. You normally do not need to understand or configure hooks, callbacks or validators; the AI should ask only when a genuinely human-only action is required. Incomplete setup alone is not a blocker: actionable work continues automatically.
For example, Project A can establish the generic configuration once. Project B reuses it while its dependencies remain valid, then establishes its own isolated binding, adoption and necessary project-specific evidence. Opening another project does not by itself repeat unchanged installation or hook tests. B never inherits A's operations, private state or authority. A second workspace alone does not repeat the first-time notice.
OOP is a research and development protocol/specification, provided AS IS under its license. Third-party AI runtimes and models are outside OOP's control: they can misinterpret instructions, stop prematurely, misclassify states or implement an integration incorrectly. Deterministic controls where available, evidence and verification reduce risk; they cannot eliminate all errors or guarantee third-party behavior, absolute protection, profit or savings.
What happens after adoption: A sufficiently capable AI identifies the current project/workspace, verifies current OOP, reconstructs relevant durable state and determines which rules apply. It materializes and validates its applicable controls, checks whether it can provide full OOP governance, performs and verifies authorized work, and leaves the project resumable by another compatible authorized AI. This is explanatory orientation, not a second bootstrap specification.
Use exact context-integrity evidence and the Semantic Routing Index; reroute at interaction, pre-effect, state changes, recovery and completion. Establish suitability before claiming full governance. Establish your own verified adoption and applicable context before governed work.
A control is verified through authoritative readback of its authorized registration and effective enablement within the declared scope; observed allowed and denied actions provide optional empirical assurance and are not required by BOOT-12. A passing isolated script is insufficient if the runtime launches it differently. Missing mandatory coverage stops dependent actions; the AI can continue independent safe work and must explain the gap. OOP specifies these outcomes without requiring a particular key type, shell or AI product.
OOP is a self-materializing governance protocol: it defines what must be true, while the active environment discovers capabilities, derives and installs its strongest applicable controls, validates them and refreshes them when OOP or the environment changes. Native deterministic, external deterministic, persistent semantic and transient semantic enforcement describe actual guarantees; residual gaps remain explicit. Actual access and authority still determine executable actions.
The compact Semantic Routing Index is derived metadata bound to the adopted OOP repository commit. Requests, planned and actual actions, state, risk, authority and recovery contribute a conservative union of facets; module selection and dependency closure then follow deterministically. A local edit that becomes a push loads repository rules before the push. If it becomes a deployment, execution and verification rules join before deployment. Completion repeats routing against what actually happened.
Full OOP Runtime Suitability requires verified interception at applicable project/session/resume/interaction, pre-effect, post-effect, completion and context-recovery paths, durable private state, local validation and any required operations/delegate controls. Native or external deterministic mechanisms can qualify. A tool without necessary per-interaction or completion blocking is not sufficiently capable to implement OOP in full. It reports missing capabilities, practical consequences and usable limited scope; semantic fallback is not full enforcement. A previously verified control that disappears invalidates dependent readiness: repair and revalidate, or block and disclose it. No silent governance degradation is allowed.
The first authorized successful bootstrap can establish a persistent non-secret workspace binding in the discovered shared private area. A supported runtime installs/verifies a minimal activation pointer to that binding and the current verified bootstrap. OOP is bound to the workspace, not to the lifespan of a chat; binding does not establish any runtime's adoption.
New chats, reopened old chats, recovery and runtime re-entry resolve the binding, reuse or obtain due freshness, establish their own verified adoption/context, reconcile relevant private and canonical facts, and show a compact localized alignment attestation before substantive work. Old conversation memory cannot prove current alignment. Future rules flow through verified adoption and realignment, rather than copied static instructions. The attestation distinguishes remote freshness, adoption/content identity, shared private state, owned runtime state, activation health, canonical operations, migration disposition and request route—even when no update exists.
Persistent project instructions, workspace memory and startup interception are possible integration capabilities. OOP requires no particular instruction file or event API. Unsupported entry paths require explicit limitations and usable recovery instructions; this specification does not claim every product automatically activates every historical chat.
user request → AI bootstrap → discover organization/runtime/protocol/work
→ load relevant rules → work → persist state/evidence when needed
→ verify material outcomes → continue or hand off
Full first environment bootstrap covers private workspace protection, authentication, project and operations access, current OOP instructions, capabilities, materialization and a scoped PASS/FAIL attestation. Later refresh compares identities and repairs only changed components. Current canonical OOP prevails over conversation history; copied configurations are disposable derived state.
After cloning OOP, the consumer runtime reads its compact distribution instructions (dist/entry.json and only the modules the current step needs, never the full PROTOCOL.md) and starts bootstrap without verifying the OOP repository or testing its release. No signatures, checksums, file-to-commit comparisons, inventory audits, publisher checks or release tests are part of consumer bootstrap, adoption, refresh or recovery, even through optional policies. Maintainers perform repository/release verification separately. Consumer bootstrap checks its own applicable adoption, migration and installed controls; its success establishes readiness only for that scope.
Minimum Safe Bootstrap identifies enough trustworthy context to begin. Progressive Bootstrap expands that context when work needs additional rules, capabilities or authority. An analysis can finish with a useful response; a small reversible correction can use an inspected diff and existing Git evidence. Meaningful features account for dependencies; production or critical effects require stronger controls.
Continuity is proactive rather than reactive. When a runtime can reliably measure remaining usable active-session capacity, OOP preserves room to persist state and prepare continuation before the session becomes unusable. A reliable comparable remaining usable budget of 15% or less triggers the Hard Continuity Reserve: stop new non-essential work, warn the user and prepare verified continuation. Without a reliable comparable metric, use explicit exhaustion signals without inventing percentages. The source packages work for an unknown future AI without raw secrets; the destination independently bootstraps, filters resources, resolves credentials and verifies the next permitted action before resuming.
On first adoption, the AI discovers organizational facts before asking only material unresolved questions. An empty operations repository undergoes Foundational Organization Intake, with domain coverage recorded as verified, partial, unknown or deferred and supported by canonical references rather than an invented percentage. Identity, mission, roles, processes, assets and operational status are modeled when relevant.
Each project keeps separate operations, private state and identity even on the same computer/account. Same-project runtimes can share purpose-named credentials and topology references; adapters and adoption remain runtime-owned. Legacy vendor-named shared resources are classified and preserved without blind renaming. Product/source repositories, operations and OOP are distinct references; if .priv holds no source reference, the AI asks you once for its address (or "none"), without guessing it, and saves your answer in .priv so no AI tool asks again.
The official full install requires operations readiness. For other work, when durable repository persistence or integration becomes necessary, resolve provider/instance and namespace, then discover the intended canonical repository. Distinguish found, confirmed_absent, inaccessible and unknown: failed discovery is not absence. Reuse existing operations; request private creation settings only when creation is required, absence is confirmed and authority exists. Private visibility is not checked or used as a bootstrap readiness criterion. Verify identity, control, canonical local/remote binding and both read and write capability through the active runtime's previously selected/prepared project credentials. If manual creation or credential attachment is needed, make one consolidated request with the exact provider/account/repository target, safe public enrollment material from .priv/common and minimal read/write permissions; recheck access after the user's action. Anonymous reading or another actor's access cannot prove this credential's readiness. A missing checkout never justifies another remote repository. The contract supports APIs, connectors, CLIs and equivalents without a mandatory host or transport.
Use an identity explicitly authorized for this project, destination and operation. A personal login that happens to work is not project permission. The AI isolates inherited settings, verifies the effective actor and keeps authentication, write permission, attribution and required signing separate. For each new AI-created commit, AI attribution must be exactly ai-coworker / [email protected], with required legitimacy independently verified; genuine human authorship is preserved and the fixed AI identity remains the committer. The system checks effective metadata before creation and the resulting commit before publication, including when existing keys are reused. A push independently requires the authorized provider principal mapped to ai-coworker through an eligible shared project reference. A mismatch blocks publication; existing keys are not needlessly changed. If enrollment genuinely needs you, it first completes safe preparation, shows only public enrollment information and explains the exact next step. It never substitutes another project's credential after denial.
Discover and reuse the authorized canonical private credential source before acquisition. A new runtime, vendor-named key or unconfigured adapter does not justify credential duplication or rotation. The ai-coworker key files used for operations live in the project's .priv/common folder, so every AI tool of the project uses the same ones. A key kept only somewhere else, such as a system keychain, is not used for operations: the AI creates a new ai-coworker key in .priv/common instead and never copies, exports or moves the old one. Configure the active adapter and verify its own required access. Authentication, read, write, commit signing and tag signing remain separate facts and purposes. Optional credential-reference and repository-access profiles contain non-secret metadata and secure references, never raw secrets.
prepared ≠ delivered ≠ accepted ≠ resumed. A ready package proves preparation; observed destination acknowledgment and verified first action prove later facts.
AI A starts → state and evidence persist → AI B resumes → AI C can verify
A formal handoff preserves effective scope, decisions, governance, authorization, blockers and the next permitted action. Preparation, delivery, destination validation, acceptance and verified resumption remain distinct; a generated package proves no destination action. Recovery inspects actual effects before retrying and keeps previous verified checkpoints separate from partial or uncertain work.
Use the same optional repository-access profile or equivalent authoritative references to preserve canonical identity/endpoint, required capabilities/permissions and credential purposes. Shared-root destinations reuse secrets by reference; separate roots/machines use path remapping and a separate authorized secure transfer only when necessary. Normal handoff/recovery excludes raw keys, tokens, passwords, cookies and decryption secrets.
The destination verifies its own binding, required access and signing. Reconcile remote/credential mismatches before writes. Historical/lightweight strings remain readable; new material destination_validated, accepted or resumed continuation needs verified structured access or an authoritative structured pointer with resolved facts and attributable destination resolution checks. Schema validity cannot prove those facts.
available ≠ downloaded ≠ compatible ≠ target ≠ applied ≠ verified. A downloaded release is not active; a selected target grants no execution authority.
Each runtime owns its verified adoption checkpoint and distinguishes available, downloaded, compatible, target, applied and verified versions. A shared checkout, shared credentials or another runtime's adoption does not establish that runtime's own adoption. Only successful applicable verification advances the checkpoint; failed attempts preserve prior verified knowledge and record actual partial effects separately.
Canonical organizational migration is separate from runtime adoption. Records belong in operations or its authoritative source of record; no global organizational version counter is required. Evaluate scoped read and write compatibility independently before version-sensitive access. A runtime may safely analyze while writes wait. Joining runtimes verify already-applied organizational effects and complete remaining local actions without blind replay. Partial failure blocks unsafe scope/dependencies while independent safe work continues. Preserve or grandfather historical facts under explicit policy; recovery and concurrent non-idempotent effects require their applicable authority and verification.
Discover existing private layouts and shared references. Shared records are append-oriented, normally immutable, with explicit supersession and conflict-safe metadata/CAS updates. Preserve concurrent conflicts and active referenced chains; atomic rename alone does not prevent lost updates. Check scope, provenance and freshness. Hints cannot replace operations, explicit user instructions, approval or verified facts. Personal preferences remain in authorized global instructions outside repositories.
At the first user prompt of each day, use the user's timezone and shared same-day success/failure evidence to check configured OOP freshness with bounded synchronization. Preserve local work and failures; stop on quota/access/conflict instead of retrying. No scheduler or background polling is required. Re-enter bootstrap and selectively realign owned instructions, caches and loaded rules against the runtime's verified identity; synchronization alone is not adoption.
Each AI tool records the full Git commit hash available for its configured OOP revision. Remote/local version comparison tracks updates and synchronization without auditing repository content or certifying the release. Each tool separately records its verified consumer adoption; that checkpoint proves neither repository integrity nor release quality. Offline remote freshness remains unknown. No distribution manifest is needed.
The instruction at the top starts setup for your current project: the AI prepares private local state, identifies the project, reuses authorized access, connects or legitimately creates operations, and configures the controls its environment supports. Most of the work needs no help from you. At most, the AI asks you two things during the first installation:
- Your project's address, once, if
.privdoes not already know it. For example: "What is the address of this project's source repository? Answer 'none' if there is no separate one." Your answer is saved, so no AI tool asks again. - One combined request about
operations, only if the AI cannot do it alone. For example: "Create the private repositoryoperationsin your account and add these public keys with write permission: authentication keyssh-ed25519 AAAA… ai-coworker(fingerprintSHA256:…), plus the signing key when your provider needs it." The AI shows only public keys, never private keys or passwords, and gives the steps for your actual provider.
After you act, the AI checks the real result itself, because your confirmation alone is not proof, and then resumes. A necessary restart of the AI tool is explained separately if it is ever needed.
Configure once, reuse what remains valid. The AI selects the needed controls, reuses an equivalent configuration where possible, writes only what is missing and reads it back. Compatible functions can share one integration instead of requiring a separate registration each. Initial installation runs no active hook behavior tests or producer test suites; this is intended to reduce repeated setup work, without promising a measured installation time or credit saving.
A one-pass example: a supported environment configures one shared integration for session entry and recovery, plus a preventive control for the actual write path; it reads back the configuration and reports: “Installation and effective enablement verified; the control is functioning by OOP policy. Actual interception has not been observed.” This is an illustrative plan, not a claim that every AI product provides those facilities.
Formal enablement counts as functioning. The AI verifies the correct project/runtime, selected control, authorized active registration, enabled state, configuration readback and any required restart. OOP then regards that control as functioning within its declared scope, even without observed invocation or allow/deny tests, during setup and later sessions. This intentionally reduces empirical assurance: an enabled control may still have an integration defect. Existing ACTIVE_VERIFIED records may express this policy finding; they must not claim an unobserved interception. A configuration file or an AI assertion alone is insufficient. Each action still needs independent permission; disabled, wrong-project or unauthorized registrations and actual failures retain their blocking consequences. After BOOT-12 verifies installation, BOOT-13 publishes its non-secret record on operations and checks the actual remote result before bootstrap completes. A failed push preserves installation and resumes publication. Avoiding repeated tests is intended to save effort; no time or monetary saving has been measured.
OOP generates a cross-platform enforcer for AI runtimes. It reuses reviewed routing, bootstrap guards and evidence checks, while preserving complete applicable rules and unresolved semantic judgments. A runtime-owned thin adapter reuses or obtains the script, maps the reviewed activation vocabulary to actual available capabilities, and connects compatible functions through a shared dispatcher. It must turn deny, unknown and error into prevention of dependent effects; the reference planner and dispatcher do not themselves install provider hooks or prove native coverage.
Start with the controller and adapter guide. Version/adoption still use the full OOP Git commit, with one active controller and at most one temporary candidate.
The fixed ai-coworker / [email protected] worker identity applies to AI runtimes using OOP in a consumer project. A human or AI maintaining the OOP repository uses an independently authorized Git and publisher identity that accurately reflects its role and authorship. Maintaining OOP does not require the consumer worker identity or its shared credential mapping. This distinction grants no extra permission and waives no applicable signing or security checks.
PROTOCOL.md is the Canonical Normative Prompt and single source of organizational norms. Read it completely before normative changes, including tables, examples, exceptions and unnumbered material.
Before resolving problems, proposing additions, changing the source or generating the distribution, follow the appendix's mandatory alignment assessment against the current Abstract, Vision and Goal. Preserve the research purpose and keep this README's commercial explanations consistent with it; potential savings, faster delivery and business opportunities remain hypotheses until evaluated. The overview provides purpose, while the applicable rules establish operational requirements and authority.
Normative edits start in the source. Derive Core and on-demand modules from complete semantic analysis, with no fixed parser, heading-to-module table or required programming runtime. Reassess module/schema sets, dependencies, routing, bidirectional traceability, migration, validation and permanent regression coverage.
Canonical REL-01–REL-11 require an AI-first distribution: typed JSON contracts, a non-empty entry, compact semantic routing and dependency closure, explicit lifecycle transitions, selective context/reuse, applicable local controls and measured maintainer acceptance. Human-oriented release readability must not increase consumer cost or latency; required user explanations and organizational history remain. Performance improvements are measurements, not assumptions about serialization. Consumer bootstrap never validates the OOP repository or executes release tests.
The structured distribution starts at dist/entry.json. It provides a small routing index, explicitly referenced JSON modules, complete source-qualified semantic clauses, guards for the listed bootstrap steps (removed step IDs such as BOOT-02 and BOOT-09 are never reused) and lifecycle/interface contracts. Producer evidence under build tools records exact source reconstruction/coverage, the applicable structured schema profile, artifact references, dependency closure/routing, particular guard/transition invariants exercised by existing tests and measured selected-context bytes. These deterministic producer checks do not establish complete formal semantic correctness, independently authenticated authority/evidence, installed runtime enforcement, remote-provider outcomes, cross-runtime interoperability, end-to-end cost savings, publication authenticity or consumer adoption; each consumer establishes its own scoped readiness. Node, CEL and MCP are not consumer-wide prerequisites. Isolated single-contract fixtures remain explicitly non-installable reference examples.
Reuse valid freshness evidence during bounded upstream synchronization; preserve local work. Persist English content and localize interaction to the user's language. This README provides orientation; the canonical source defines the protocol.
The repository maintainer appendix in PROTOCOL.md contains the complete technical audit instructions and commands available to the repository maintainer:
- Technical audit: read-only repository audit and consolidated corrective recommendations, to be executed after reading this file if you have been instructed to act as maintainer of this repository.
- DIAGNOSE: analyze requests or problems and propose changes.
- FORMALIZE: return a complete English implementation prompt with the decision dossier and one canonical commit message, without a download or required final message display.
- PREPARE: invoke FORMALIZE first, append only the executor's final message-display instruction, and save the resulting downloadable Markdown. PREPARE itself makes no implementation or Git changes and never previews the message.
- VERIFY: check implementation and current regressions, accounting for independently requested surrounding commits and explaining actual normative source changes with two before/after examples when present.
- APPLY: invoke FORMALIZE first and execute its prompt unchanged without saving it, then commit and push the selected authorized changes. With direct filesystem access, use the current HEAD branch; with API-only access, create a new dedicated branch. After successful publication and exact remote readback, run VERIFY on that actual branch/commit. No external publication lock or prior VERIFY is required. Failed publication preserves actual work and is reported without automatically invoking the post-publication VERIFY. Signing, scoped checks and separate authority for force pushes or administration remain required. No terminal message display is required.
- REPORT: consolidate supported findings using the mandatory complete reporting contract.
Invoke DIAGNOSE, FORMALIZE, PREPARE, VERIFY, APPLY or REPORT with the relevant input from your chat. The first five commands run only when invoked. FORMALIZE returns instructions, with REPORT data inside the English prompt and localized process reporting before its return; this is not completed implementation. Completed PREPARE, VERIFY, APPLY, DIAGNOSE and ordinary maintainer audits apply localized REPORT. Direct REPORT consolidates existing findings without starting an audit. The maintainer appendix remains separate from organizational runtime requirements and consumer lifecycle.
Build scripts, tests, schemas and producer evidence live in tools. Maintainer commands follow the repository maintenance guidance and the canonical requirements in PROTOCOL.md.
Producer artifacts use reviewed source-content identities without embedding their own future commit SHA. Maintainer acceptance checks the actual current committed source and exhaustive inputs independently of parents, an initial root or old Git objects. Comparative regression evidence is separate and needs an independently trusted comparable content checkpoint; unavailable evidence is NOT VERIFIED. A precommit candidate is not committed release readiness. Publication requires its own authority and remote readback; producer checks never replace consumer adoption or organizational migration.
OOP revisions are identified by their full Git commit IDs. Review and validate changes before publishing them to the configured repository. Assess compatibility and any migrations required for runtime adoption.
Uppercase normative keywords follow canonical BCP 14 conventions. Licensed under Apache-2.0, copyright 2026 Marco Vasapollo; see NOTICE. The license covers the specification, documentation, schemas, machine-readable artifacts and examples.
The generated installation manifest describes what each controller function needs. Your runtime maps it once to a complete plan for the current workspace, then BOOT-12 installs or reuses the selected controls and reads back their effective enablement. It does not repeat the coverage analysis or run synthetic hook trials. A small runtime-owned bridge lets compatible OOP updates reuse the same native registration; new events or permissions can still require an authorized setup change. BOOT-13 publishes the verified installation record before bootstrap is complete. A missing preventive path limits dependent work; the manifest alone cannot establish host support. No measured time or cost saving is claimed.