The rules of the game
Model, contracts, relationships, generic interfaces, controls, plans, receipts and audit. The Product defines how an operational domain is described and governed; it does not contain a customer's endpoints or credentials.
Inside CIGP
One shared model. Real systems.
CIGP's strength is not a list of scripts or a separate console for each vendor. It describes objects, relationships and rules consistently, then connects reusable technical capabilities to a customer's real systems.
The boundary that makes the product extensible
Product, Library and Instance have different responsibilities.
That is how a new technology can be introduced without becoming another vertical feature, and without confusing an available capability with permission to use it.
Reusable capability
Versioned definitions, adapters, mappings, readers, writers and templates for a technical family. It brings the specifics needed to read or change a system; it does not, by itself, enable a customer target.
The customer's reality
Systems, connections, assets, data, credential references, selections, applied rules and actual delegations. Here a compatible capability is configured and authorized for a real context.
Adding a definition does not magically create an integration. A real write requires an attested technical capability, coherent configuration and authorization for that target.
A new technology
Bring in the specifics. Keep the governance model.
Describe the domain
Define the objects, their attributes and how they relate to other objects.
Provide the translation
A library makes mappings, reading, writing or views available for that technology.
Configure the environment
The Instance connects the real system, targets, connections, credential references and rules.
Put it to work
Functions consume only what the model and installed capability actually make available.
This is not a promise of “no development”: a new technology may need integration work. That work stays focused and reusable rather than becoming yet another separate application.
The declarative model
What does “declarative” mean?
DataSource names the domain capability, DataSourceSystem the concrete system, and DataLayer the governed records. The contract describes identity, attributes and allowed operations; references declare how objects connect, including across DataLayers.
These definitions form a shared basis for functions that support them. Observing context, preparing an action, applying a rule or building a document does not require inventing the meaning of the data every time.
A description does not execute a change by itself. Acting on a target still requires an attested technical capability, a real system binding, controls and authorization.
A virtual machine in the model
Identity and attributesWhich VM, state, provenance
RelationshipsBackup job, latest result, monitoring
OperationsWhat is allowed for this kind of object
The backup job can live in another DataLayer. The link is explicit in the contract, not hidden in a text string.
Day-to-day work
One shared reality, three distinct ways to work with it.
The shape of views and availability of actions come from contracts and actual capabilities, not from a new page built for every product.
Operation Workspace
View connected assets and data, explore their context and open authorized interactive connections. It does not create, change or provision.
Actions on systems
Select one or more targets and present the mutative actions actually available for that object, with fields, a plan, checks and results.
Workflow Provisioning
Combine actions from the same model into procedures with stages and dependencies, without creating a parallel way around delegation and controls.
The model in practice
A service is more than five screens put together.
A virtual machine can be linked to its backup job, the most recent result, monitoring status and security observations derived from SIEM events. Each item retains its provenance and meaning; the relationships make the service legible.
The same references can support observation, target selection, rules, verification and documentation, according to the capabilities available in the Instance.
When action is needed
An action starts with the target, not an isolated command.
The platform resolves what is available for that kind of object and for the specific system. The operator sets the scope; the technical capability performs the intervention only after the relevant checks.
1. Context and planTarget, action, fields and impact are visible before execution.
2. Decision and delegationGrants, rules and Change where required control the act; target credentials stay server-side.
3. Execution and recordThe transaction records each target's result; receipt and state verification follow the mutation contract.
An action does not appear merely because a DataLayer is writable. Coverage, an attested writer, binding, policy and consistent authorizations are also required.
Beyond a single operation
The same definitions help teams observe, check and document.
Asset Intelligence
Collects and reconciles observations, identities and provenance so assets become part of operational context.
Policy and compliance
Rules can intervene before an action; periodic compliance assessment is a separate job.
Document Builder
Reuses data, relationships and rules for versioned, traceable documents, to be reviewed and approved by responsible people.
Let's discuss your context
Which system or process would you start with?
A conversation about a real situation is the quickest way to see how the shared model, reusable capabilities and Instance configuration work together.
Discuss a critical processAny system. Any vendor. One way. Always proven.