A new business application needs its own workflows. It also needs people to sign in, records to stay within the right organization, and operations to follow access rules. Those concerns return in project after project.
Wildo places that recurring behavior in an engine that applications depend on. An application declares how it uses the engine and adds the parts that make its product specific. The shared implementation remains a dependency with an owner, so a correction has a common place to land.
This matters after the first version. Improving shared behavior does not require finding and repairing a separately generated implementation in every application. Adopting an engine update still involves choosing the version, reviewing changes and testing the application.
The same principle applies to guidance. The tools and agents building an application need to know which engine capabilities exist and how to configure them. Wildo’s framework knowledge connects that guidance to the authoring surfaces it describes.
Inheritance reduces repeated implementation; it does not remove application responsibility. The builder still chooses configuration, supplies credentials where required, writes domain logic and checks the result. An available engine mechanism is not evidence that an application has enabled or exercised it.
Example: What changes when the shared behavior improves?
A shared correction
A fix to a resource access rule belongs in the engine implementation that applications consume.
An application decision
The application adopts the updated dependency, checks its own configuration and runs the relevant scenarios before release.
A continuing product
Its task model, approval rules and custom interface remain application concerns. Sharing the engine does not turn every product into the same application.
This is the maintenance relationship Wildo is designed around.
For engineers
Engine packages provide the shared models and runtime behavior. Application packages declare their resources, register modules, choose providers and supply custom implementations or UI behavior. Scaffolding can create the starting files; the engine implementation itself is consumed as a dependency.
Identify the owner before adding code
Use a resource declaration for fields and operations, a relationship for ownership and addressing, and a UI behavior or component extension for presentation. A capability supplied through a provider also needs a compatible provider choice and its configuration. Keep business-specific decisions in the application rather than copying a framework subsystem to change one behavior.
Framework knowledge teaches application authors and coding agents these extension points. Source anchors connect selected authoring APIs to compiled guidance. That connection helps keep examples aligned; it is not a substitute for verifying that a particular creation run loaded the guidance or used the capability correctly.
Treat adoption as an application change
An engine fix is shared at its source, but a running application does not acquire it by implication. Its dependency version, generated artifacts, migration requirements and runtime configuration all need to agree. Exercise the affected workflows after adoption, including the application’s own custom operations and screens.
A configured provider slot, a package in the repository and a successful application scenario are different evidence. Check the relevant capability’s availability and boundaries before treating it as behavior the product already delivers.