Governed Objects
Put the business object, not an application, at the center.
Define business objects and their governed behavior independently of the applications that use them. Typed, versioned definitions establish object meaning; applicable policies and domain rules determine permitted changes; the runtime enforces supported behavior and preserves accepted history.
Build new interfaces on a shared business model, not a new interpretation of the business for every application.
Application-centered
Applications define the record
Object-centered
Applications work around the record
Dependencies remain. The distinction is what they attach to: an individual application’s implementation or an explicitly defined governed-object contract.
What this changes
Preserve object meaning beyond application code.
Bind objects to identified type versions and keep domain meaning explicit. Applications can evolve without becoming the sole definition of the underlying object.
Support multiple clients of one governed object.
Different interfaces and permissions can operate against the same accepted state through governed operations. Separate views need not become competing authoritative records.
Separate application replacement from business-model replacement.
Define identity and object semantics independently of a particular application. Runtime replacement remains a separate compatibility and preservation problem.
Reuse runtime mechanisms; supply domain behavior.
Build on supported authority, validation, revision and history mechanisms while keeping business-specific definitions and behavior outside runtime internals.
Give automated callers bounded operations.
Apply relevant authority and validation checks to automated requests. Trustworthy caller identity and authority binding remain integration responsibilities.
Preserve accepted history across callers.
Record accepted canonical changes independently of the interface that initiated them. Distinguish that history from operational logs and complete AI-interaction auditing.
A shared endpoint is not the same as a shared semantic contract.
Connecting applications to the same server is useful. But it does not, by itself, establish a reusable contract for what counts as an accepted change, how authority is checked, or what history must survive. Governed Objects makes those meanings explicit, so they are not defined only by one application’s implementation.
-
01
Share more than fields
Two systems can exchange the same date and still disagree about whether it was requested or agreed. Common semantics establish the distinction; the business type defines the particular operations.
-
02
Keep governance consistent as interfaces change
A customer portal, staff application and agent can submit different requests with different permissions. The governed boundary determines which changes may become accepted state.
-
03
Make behavior something implementations can be evaluated against
A written specification provides common requirements for authority, revisions and accepted history. It creates a basis for testing behavior rather than relying only on a product’s promises.
-
04
Build a foundation for replacement
Where compatible replacement is supported, the specification defines what must be preserved. Applications and runtimes can change without silently redefining the business record.
Common semantics, not identical software. Applications can have different interfaces; runtimes can use different storage and policy engines. Compatibility still requires support for the relevant types, versions and capabilities.
- Specification: common requirements for governed behavior and outcomes.
- Business types and applicable policies: object meaning, domain rules and authority requirements.
- Runtime: implementation and enforcement of supported behavior.
- Applications: interfaces, workflows and integrations.
The specification does not define a universal network API or make arbitrary runtimes interchangeable.
Trace a governed change
- Inspect the type definition. Identify the example’s fields and modeled operations, including behavior supplied by Python rather than YAML.
- Read the current instance. Compare the confirmed return date with any pending extension request.
- Submit an extension request. Observe the distinction between recording a request and changing the confirmed date.
- Accept or decline through the staff interface. Follow the resulting state and accepted history.
Accepting an operation is not always accepting a business proposal. Recording a pending extension request can itself be an accepted state change without approving the later return date.
This example shows multiple callers working with one business object through one local Python runtime. The object’s state and governed operations are managed by the Governed Objects runtime rather than separately implemented by each interface. This demo hosts the interfaces and runtime in one process. You can inspect the YAML type definition in the server view. Some business rules are implemented in Python rather than YAML. Cross-runtime interoperability and migration are not demonstrated here.
Full tradeoff comparison
Application-centered
Pros
- Straightforward delivery: One team can build and evolve the application and its business model together.
- Clear operational ownership: Deployment, support and business behavior sit within one product boundary.
- Effective for focused use cases: A strong fit when one application serves most of the object's lifecycle.
Cons
- Consumers depend on the application's contract: Changes to its interfaces or business model can affect connected systems.
- Shared meaning takes coordination: Other applications may need mappings and duplicated assumptions to interpret the same business record.
- Replacement can reach beyond the application: Moving to another product may require preserving identifiers, translating history and rebuilding integrations.
Object-centered with Governed Objects
Pros
- A shared business record: Applications work with the same accepted state, explicit type meaning and history.
- Governance across interfaces: Governed operations apply authority and validation checks regardless of which application submits them.
- Continuity beyond one application: Object identity and accepted history are defined independently of the applications that use them.
Cons
- More explicit modeling: Business operations, authority boundaries and changes to type meaning need deliberate design.
- A runtime to operate and integrate: Hosting, identity binding, monitoring and connections to external systems remain engineering responsibilities.
- Compatibility requires work: Applications and runtimes must support the relevant types, versions and capabilities; a common spec does not make integration automatic.
A well-designed conventional service can provide many of these behaviors. Governed Objects aims to make their meaning a reusable contract, rather than a convention defined separately by each application.
See it for yourself
Local experimental demo: synthetic data and one Python runtime. This local demo shows multiple callers working with one governed object. Vendor migration and complete AI-interaction logging are not demonstrated.
Technical details
Objects it holds: RentalAgreement rental-agreement-001. A third client, the scripted agent tool (no live AI model), runs from a terminal (see README). Here the pages and the server share one local process; the separation is in the code. Django renders and routes; every decision, revision and history record comes from the Governed Objects runtime.
Try it for yourself
The runtime is licensed under Apache 2.0. Install it, define an object, and call it from your own code.
pip install governed-objects
Python runtimeQuestions, or want to talk it through?
We’d like to hear what you’re building and how Governed Objects might fit.
hello@governedobjects.com