1. Identify what can be reused
Solving an operational problem takes computational capabilities, workflows people can use, and infrastructure that supports operations. Omelet distinguishes three types of assets.
| Asset | What it contains |
|---|---|
| OCP | The meaning and relationships of objectives, constraints, data, and parameters, together with API usage guidance. Its supported scope is managed alongside the corresponding runtime service. |
| Application Kit | Reusable interfaces and workflows for input, review, comparison, revision, approval, and integration |
| OIP | Shared operational infrastructure for authentication, permissions, auditing, observability, and deployment |
An OCP description must match the capabilities supported by the actual API and engine. Adding a description alone does not create a new computational capability.
2. Understand the roles of assets and systems
Assets are capabilities and materials accumulated for reuse. Systems provide the working environment for creating or using them.
- OI Factory: An internal system that supports problem definition, verification, and asset creation
- OI-Studio: A system for exploring, composing, and executing decision capabilities, and analyzing their results
- OI Foundry: An internal system for building, verifying, and delivering customer applications from shared assets
These roles describe how the components fit together. The actual scope of a feature still needs to be verified against its implementation and operating environment.
3. Leave something the next person can use
A file's existence is not enough to make it reusable. Others need to find what it solves, the conditions under which it was verified, and how to use and check it.
If an important constraint is lost when a plan is revised, go beyond fixing the editing feature. Preserve a check that detects the issue and document its conditions of use. Then assess whether the same check can be applied to the next workflow.
Do not copy customer data, personal information, or contractually restricted material directly into shared assets. Check reuse rights and disclosure boundaries, and explain the approach through generalized rules and fictional examples.
What can the next person do more easily because of this experience?
Try it yourself
Choose a small problem you recently solved, or a fictional scenario, and write a five-line asset record.
- What problem does it solve?
- What inputs and supported conditions does it require?
- What evidence establishes its behavior and limitations?
- How can the next person use and check it?
- Who maintains it, and when should it be reviewed?
Assess whether it can be reused
Check whether someone can get started without an explanation from the original author. Distinguish adapting a copied implementation from using a shared asset as it is. Record both the work actually saved and the new work required.