7lens Product Definition

Canonical copy

Copied from the 7lens app repository, docs/product/7lens-product-definition.md at 012d434, on 2026-11-11. Document version 2.0, dated 2026-10-31. The app repository is the source of truth. Do not edit this page here; change the source and re-run npm run sync:reference.

This is a strategic source document: why 7lens exists, who it is for, what it is, how it works, and its boundaries. The canonical model is in Data model.

---

Why 7lens

The shift

Companies will soon be operated by people and AI agents together.

The problem

AI can act safely only on a company it understands: what exists, what each thing is, how things relate, and what AI is allowed to touch. Today that knowledge is scattered across cloud, security, finance, inventory, and operations tools, described in different words, and partly held in people’s heads. An agent given access to that landscape is guessing.

Preparing a company for AI means describing it once, in a form both people and machines can read. That description is an ontology: the model of the enterprise. It is the missing foundation for AI that operates inside a company.

The pressure on the people accountable

The people who run technology are getting harder jobs at the same time.

• The CISO secures more technology against more vulnerabilities and more attackers, and now also against AI agents acting inside the company’s systems.
• The CFO faces rising costs everywhere: licences, cloud, AI, and operations.
• The CTO is accountable for the resilience of a company with more systems and more dependencies than anyone can hold in their head.
• The CIO is accountable for the strategy that connects all of it.

The risk of waiting

If the enterprise is not described before AI starts operating in it:

• AI acts on a company nobody can fully govern.
• Costs grow that nobody can explain.
• Attack surface grows that nobody has mapped, including the AI itself.
• When something fails, nobody can say quickly what breaks or who is affected.

The answer

Describe the enterprise once (the Ontology). Fill it with the customer’s real facts, inside the customer’s own environment (the Context). Then let every person and every AI agent read that same picture through the lens that fits their role (the seven lenses).

7lens does not replace the tools that hold the facts, does not require a data lake, and does not copy the customer’s data out of their environment.

Who it is for

Primary buyer: IT leaders accountable for security, cost, and resilience: CIO, CISO, and CTO. The CFO is a key partner.

The need we meet: to protect the company today, and to be ready for operations run by people and AI before they arrive. The reaction we want is: “This helps me now, and it prepares me for what is coming.”

Positioning

In one sentence: 7lens is the context layer that lets people and AI understand, govern, and operate the enterprise.

Category: context layer for technology decisions by people and by AI.

One enterprise. One ontology. Seven lenses. Same data. Different questions. Better decisions.

What makes 7lens different

• Built for AI as well as people. The same Context is read by people and by AI agents, with the same permissions and audit trail.
• Runs inside the customer’s environment. The Context stays there. The management plane receives no customer sensitive data.
• No data lake, and no years of consolidation. It reads what existing tools already know and connects it.
• Source systems stay authoritative for the facts they produce. 7lens writes the connected picture. It does not overwrite the source.
• The customer owns its semantics. OSM is the open catalog used to start the Technology model. After that, the customer owns the filled-in model. Swapping a tool changes a mapping.
• AI proposes. Trusted data, fixed rules, and an explicit check decide what is true.

Plain-language glossary

Use these when explaining 7lens to someone who has not met it. The technical terms stay in the product and the documentation.

Technical term	Plain language
Ontology	The model of the company: what kinds of things exist and how they can connect.
Context	The company, mapped: the real organizations, applications, assets, and links, with the history of where each fact came from.
Lens	One role’s reading of that same map, for a person or an AI agent.
Collector	The front door where existing tools send what they know.
Semantic Engine	The part that cleans, matches, and connects that information into one picture.
MCP	A standard way for an AI assistant to ask questions of the Context, under the same permissions as a person.
In-tenant / zero egress	It runs in the customer’s own environment, and the customer’s data stays there.
OSM	The Open Service Catalog Model: an open catalog of technology capabilities that anyone can adopt, used to start a 7lens Technology model.
Owner	The person accountable for a Configuration record. The stored field is accountable_person. The screen label is Owner.
Belonging	Which Application, Domain, or Platform an Asset is for. Belonging is never a person, and it is never labelled Owner.
Stack	An operational competency domain that groups Services, such as Compute or Storage.
Service	A technology capability that more than one product could supply.
Offering	One product or variant that supplies a Service.
Asset Type	The kind of real instance a Service produces. The recognition key for Assets of that Service.
Asset	One real instance in Inventory, recognized by its Asset Type and one Offering.
Platform	Something the enterprise operates that supplies a Service and that business users work in. The business uses on it are Applications.
ICT Provider	The supplier a Service or Offering relies on.
Inventory	The asset record: one version-2 document in the customer’s environment.
Contract	A commercial agreement with a provider. The word is reserved for that meaning.

What 7lens is

7lens gives an enterprise one connected picture of its enterprise landscape.

Cloud, security, finance, inventory, and operations tools already hold the facts. Each one tells a different story. 7lens does not replace those tools. It reads what they know, connects it, and lets each leader ask a different question of the same picture. The value is seeing how those facts relate across technology, applications, organization, cost, security, and operations, without making another copy of the data.

That picture is built inside the customer’s own environment. Customer data stays there.

The path is simple:

1. Collector receives information from the systems the customer already uses.
2. The Ontology is the model: what kinds of things exist, and how they are allowed to connect.
3. The Semantic Engine turns source information into one connected picture, the Context.
4. People and AI agents read that picture through seven lenses. Software and AI assistants read the same picture through an API and through MCP.

A picture of one fact

Retail Banking in Spain runs payments on a platform the enterprise operates. A platform team runs that platform for many business uses. One of the real machines in it is a Kubernetes cluster.

In 7lens that is one connected Context:

• Retail Banking is a Business Domain. The Domain belongs to a Legal Entity in Spain. That Legal Entity is how the Domain, and the Applications in it, sit in the Organization.
• The thing the enterprise operates, and that business users work in, is a Platform. It supplies one or more Technology Services. It has an Owner. The cloud or software supplier behind it is an ICT Provider.
• Payments is an Application in the Retail Banking Domain. It consumes the Services it relies on. It stores no link to the Platform. Payments does not carry its own Legal Entity. An Owner on Payments, when one is named, is the person accountable for the Application.
• The Kubernetes cluster is an Asset in Inventory. It is recognized only by its Asset Type (asset_type_id) and one Offering of that same Service (offering_id). The Service and the Stack are derived from the Asset Type. The Provider is derived from the Offering. The cluster belongs to the Platform. A person is not stored on the Asset. Which Applications the shared cluster affects is derived from Assets.

The finance lens and the security lens then ask different questions of those same facts.

Ontology and Context

These two words stay distinct.

• The ontology is the model 7lens ships: the kinds of things that exist, and the rules for connecting them.
• The Context is that model filled in for one customer: the actual organization, applications, assets, links, and the history of where each fact came from.

Technology is organized as Stack → Service → Offering. A Stack groups Services into an operational competency domain. A Service is a capability several products could supply. An Offering is one product or variant that supplies that Service. Beside its Offerings, a Service defines the Asset Types that say what a real instance of the capability is.

OSM, the Open Service Catalog Model, is the open catalog a customer uses to start that Technology model. Anyone can adopt OSM without 7lens. It suits onboarding, a small team trying the model, and a team building its own platform catalog. After onboarding, the 7lens Technology axis is the authority for that customer’s Stacks, Services, and Offerings. The customer may improve them and add their own. There is no per-entry link back to OSM. OSM and 7lens evolve in parallel. Improvements that would help the next customer start are proposed back to OSM. Platforms, Groups, Asset Types, adoption, and the declaration language belong to 7lens.

External frameworks and tools are mapped onto the customer’s own concepts through the Groups-axis Frameworks and Integrations containers. That mapping sits outside the Technology catalog and outside OSM. Swapping a tool changes the mapping. The enterprise definition stays.

7lens owns the default model. The customer owns the data, the mappings from their source systems, and any extensions they add. The filled-in model stays in the customer environment.

Shared representation — time, people, provenance, quantities, money, and the declaration of each attribute — is a closed core, versioned with the 7lens schema. A customer extends it by narrowing a declaration. A preference, such as time zone or display currency, changes presentation only. It does not rewrite a stored fact.

Canonical means the single 7lens version of a fact after sources have been compared and disagreements resolved. It does not mean 7lens invented the fact.

The system that produced a fact remains the authority for that fact. A cloud platform remains the authority for the virtual machine it reports. 7lens is the authority for how that machine is typed, connected, mapped, traced, and reconciled inside the Context. When 7lens writes, it writes that connected version. It does not overwrite the source system.

The core model: the Ontology

The core 7lens data model is the Ontology: four axes — Organization, Groups, Technology, and Business.

Tell things apart in this order, and stop at the first match:

1. ICT Provider — the supplier.
2. Service — a capability several products could supply.
3. Offering — one product or variant that supplies a Service.
4. Platform — something the enterprise operates that supplies a Service and that business users work in.
5. Asset — one real instance, of an Asset Type under its Service, naming one Offering of that Service.
6. Application — what business users use to run a business process.

Organization

Organization is who the enterprise is and where it operates.

There is one global Organization. Its Structure is Region, optional Sub-region, Country, and Legal Entity. A Country belongs to one Sub-region or, when Sub-regions are not used, to one Region. Regions and Sub-regions follow UN M49. Countries use ISO 3166-1 alpha-2 codes. Commercial groupings such as EMEA are overlays, and they are not these geographic levels.

Every Organization, Region, Sub-region, Country, and Legal Entity has an Owner: the person accountable for that record. In Configuration the label is Owner. The stored field is accountable_person (name, surname, email, and an optional role).

Who and where is the enterprise?

Groups

The Groups axis has three Configuration containers: Groups, Frameworks, and Integrations.

Groups are customer-defined classification dimensions. They classify entities across Organization, Technology, and Business, and they set strategic ownership and access boundaries through the Owner of each value. Groups are an axis of their own. They are not the organizational hierarchy, and they are not Business Domains.

A value is an assignable option. A subgroup is a container that holds values. A Group may have direct values, subgroups, or both. There is one subgroup level. The classification pick is stored on the entity it classifies. A value inherited from a parent does not satisfy a required pick.

Groups apply to Organization, Region, Sub-region, Country, Legal Entity, Stack, Service, Offering, Platform, Domain, and Application. They do not apply to ICT Providers. Classification Groups must not stand in for the Technology hierarchy, and must not encode Data Sensitivity, Environment, or Lifecycle.

Frameworks and Integrations are catalogue enablement on the same axis: Frameworks for standards and compliance regimes, Integrations for tool / platform taxonomies. They are not the same as classification Group values. OSM seeds the Technology catalog and is not a Framework selection.

How does the enterprise want to classify things — and which external frameworks and integrations apply?

Technology

Technology is the catalog of capabilities the enterprise provides, and the Asset Types that recognize real instances of those capabilities.

Stack → Service → Offering, with Asset Types as the sibling of Offerings under each Service.

• A Stack groups Services. Stacks nest. A Stack is an operational competency domain, such as Compute or Storage.
• A Service is provider-neutral. Many Offerings may supply it. Many Asset Types may describe the instances it produces. Each Asset Type belongs to exactly one Service.
• An Offering is one product or variant. Price and commercial terms stay off the Offering. They belong to the Contracts extension.
• A Platform is something the enterprise operates that supplies a Service and that business users work in. ERP, CRM, HR, ITSM, and similar products, when the enterprise operates them, are Platforms. So is an internal platform a platform team runs for others to work in. The business uses built on a Platform are Applications. A Platform has an Owner, a sourcing model, and a delivery model. The supplier remains an ICT Provider.
• An ICT Provider is the supplier a Service or Offering relies on: cloud, software, hardware, SaaS, a managed service, or an open-source community. A Provider has no Owner.
• An Asset Type is the recognition key for Assets of one Service. Assets themselves live in Inventory. They are not rows in the Technology tree.

Infrastructure that applications consume is a Platform only when a platform team runs it as one. Otherwise it is an Asset of the Service it instantiates.

Characteristics of a Service or Offering, and the attributes of an Asset Type, are described in one declaration language in the 7lens schema. A declaration describes the value. The value sits on the Service, the Offering, or the Asset.

What technology capabilities exist?

Business

Business is the landscape of business areas and the applications that support them.

Domain → Application

• A Domain groups Applications. Domains nest. Every Domain belongs to exactly one Legal Entity. A child Domain shares its parent’s Legal Entity.
• An Application is one enduring business system in exactly one Domain. It provides functionality to business users, customers, or other consumers. It consumes Technology Services. It stores no link to a Platform; Assets show that relation when a Platform produced them.

An Application does not carry its own Legal Entity. Organization ownership resolves through the Domain. An Owner on a Domain or an Application is optional. That Owner is the person accountable for the record. Accountability and the Legal Entity are different facts.

How finely the uses of one Platform are split into Applications — by business process, by module, or by Domain — is not fixed in this definition. The order of the identity test is fixed.

A Deployment is a defined way of making an Application or a Platform available in one context. It is part of that definition. It is not a live runtime. Entry points sit on Deployments. A Deployment belongs to one Application or one Platform, never both.

What does the business do, and which applications support it?

Data Model Extensions

These Data Model Extensions extend the Ontology. They are not axes of it.

Inventory

Inventory is the enterprise’s record of real instances, kept in the customer’s environment, in the company dataset, and in backup.

It is one document, at schema version 2 (inventory_schema_version: 2). Field names are snake_case. There is no earlier inventory shape beside it.

An Asset is one real instance of an Asset Type. 7lens is the authority for its meaning: its type, its belonging, the Platforms and Applications it is tied to, and its declared attributes. When a source system exists, that system stays the authority for the raw observed facts, and 7lens records the source of each fact.

Recognition uses two fields only:

• asset_type_id — the Asset Type, which belongs to one Service.
• offering_id — one Offering of that same Service.

The Stack and the Service are derived from the Asset Type. The ICT Provider is derived from the Offering. The Asset id is opaque. It encodes no type, Offering, or Stack. Source-system keys are stored separately.

Belonging says who the Asset is for: an Application, a Domain, or a Platform. It is never a person, and the product never calls it Owner. A shared Asset belongs to the Platform. An Asset made for one Application belongs to that Application, whether a Platform produced it or not. Which Applications a shared Asset affects is derived from Assets. The person accountable for the Asset is the Owner of the Application it belongs to, otherwise the Owner of the Domain, or the Owner of the Platform when belonging is the Platform.

An Asset may point at the Deployments it belongs to, as what a Deployment runs on, or as the code a Deployment is built from. Deployments do not list Assets.

Attributes on an Asset use one envelope: the value, where it came from, when it was last confirmed, and whether it was observed, assessed, or derived. Posture — the observed, assessed, or derived state of one Asset — lives only on the Asset. What a Service or Offering promises (support, recovery targets, approved data classes) is a catalog fact, and it is not posture. Findings and other events are evidence, kept as fact records. Counts and roll-ups are views. They are not stored on the Asset.

An assessed value is a person’s judgment, named with the Owner shape. While it stands, a later observation does not replace it. How long it stays in force is not set. An operator can clear it.

An Asset can be brought to the terminal states retired or deleted. The id is not reused. The transitions among earlier states are not part of this definition.

Contracts — future

The Contracts extension will normalize commercial agreements — the agreements with vendors and providers the enterprise pays for software, hardware, and services — against the configuration the enterprise owns. Tying each agreement to what it covers is how spend becomes visible. The Contract model itself is not defined here. Price and commercial terms stay off the Offering until that extension exists.

Processes — future

The Processes extension will turn the deterministic process out of operators’ heads into a machine-readable process the enterprise can automate and monitor, improving efficiency, time to market, and mean time to recover.

How information gets in

Collector is the front door. It is not a discovery tool, and it is not the engine that decides the canonical picture.

It can receive from the customer’s existing sources: a CMDB, cloud platforms, security tools, monitoring tools, finance systems, application catalogs, and custom tools.

Collector records who sent the data, checks that the payload is usable, accepts a full load or a change, passes it to the Semantic Engine, and keeps a status for that delivery.

Discovery systems discover. Collector brings their information into the Context.

Finding the data stays with the customer and their integration partners. 7lens provides the place to send it.

How a source fact becomes part of the picture

The Semantic Engine does not treat incoming data as already true in 7lens. It produces the Context:

• Normalize — different names and formats become the 7lens model.
• Reconcile — several sources that describe the same real thing become one canonical record.
• Validate — rules mark anything that does not fit the model.
• Map — each fact is attached to the right organization, technology, application, or asset, using the identity test above.
• Keep the trail — where it came from, when it was seen, and how confident the match is. An observed fact names its source. An assessed fact names the person. A derived fact names the rule.
• Resolve disagreements — if two sources conflict, a defined rule picks the outcome. Nothing is chosen quietly. For an Asset attribute, human assessment outranks an observation from the designated source, which outranks any other observation. A lower-precedence observation still updates when the Asset was last seen.

How people and software use it

They use the Context, the customer’s picture. The ontology is the model behind that picture.

An API lets other software ask what exists, how it is connected, and update the connected version: links, mappings, classifications, the source trail, and conflict outcomes.

MCP lets an AI assistant ask the same questions, with sign-in, permissions, and an audit trail.

AI may suggest a mapping, a classification, a link, an interpretation, or a recommendation.

AI proposes. Trusted data, fixed rules, and an explicit check decide what is true.

The seven lenses

A lens is a stakeholder’s reading of the same Context: a way of interpreting that shared picture to answer one class of questions. The stakeholder can be a person or a machine. A lens is not a dashboard and not a separate product module.

The seven named lenses are reference use cases. They are starting points that turn 7lens into enterprise value. Customers configure the ontology, attributes, relationships, mappings, and context each one needs, and they can combine or extend them. They are one Context read seven ways.

All seven are reference use cases. The lead use case is Security: you cannot protect what you do not know you have.

The “Written for” column is the reference audience for that question. It is not a permission model.

#	Lens	Written for	The question it answers
01	Security Lens	CISO and security teams	What do we actually have, what is exposed, and what sits behind each entry point?
02	CTO Governance Lens	CTO and engineering leaders	Is the technology estate production-ready and under control?
03	CFO Capital Lens	CFO and finance partners	Where does technology spend leak, and what does it do to the business?
04	CIO Strategy Lens	CIO	How do delivery and spend connect to the organization’s plans?
05	Lock-In Free Lens	CIO, CTO, and enterprise architecture	How do we own our enterprise semantics and integrate any tool without redefining the enterprise inside each one?
06	Automation & AIOps ROI Lens	CTO and operations leaders	What is automation and AI actually delivering across the operation, and where is the ROI?
07	AI Lens	AI agents, and the people who govern them	Help AI understand the company before it acts — what can agents reach and change?

Reference use cases

• Security Lens (01) — Cybersecurity intelligence through a complete, contextual inventory. The lens reads Applications, the Services they consume, the Platforms they run on, and the Assets that evidence them: compute, clusters, containers, repositories, data stores, machine identities, automations, and AI agents. Each Asset is recognized by its Asset Type and one Offering, and organized by the ontology. Entry points sit on Deployments. The exposure reading gathers an Application, its Platforms, their Deployments and entry points, and the Assets those Deployments run on, with each Asset’s posture. The value is speed, completeness, and context: take in what the enterprise already knows, normalize it, and organize it to the semantics security needs, without building that picture by hand first.
• CTO Governance Lens (02) — shows whether the technology estate is production-ready and under control: lifecycle and adoption on the catalog, operational state on the Assets, and the Applications and business areas they support.
• CFO Capital Lens (03) — relates technology spend to the business it supports, exposing where cost leaks and what each spend delivers. Commercial agreements are the Contracts extension, which is future work. Until then the lens still asks the question of the Context that exists.
• CIO Strategy Lens (04) — connects delivery and technology spend to the organization’s plans, so investment and execution can be read against intent.
• Lock-In Free Lens (05) — The customer owns its enterprise semantics and integrates any tool without redefining the enterprise inside that tool. The customer defines canonical concepts once and maps external frameworks and tools (ServiceNow, TBM, FOCUS, DORA, NIS2, Apptio, and others) onto them. The mapping sits outside the Technology catalog and outside OSM. Swap a CMDB or a FinOps platform and the mapping changes. The enterprise definition stays.
• Automation & AIOps ROI Lens (06) — Measure the operation. An automation is an Asset, recognized by its Asset Type and one Offering of that Service. Demands, executions, and delivery requests are facts kept beside the Assets. An execution records what it touched and the effect. Mean time to recover, time to market, and execution counts are views over those facts. They are not stored as counters. A saved-cost figure that needs a unit price waits on the Contracts extension. The lens is how the enterprise sees where work is still manual, where an automation or an agent already acts, and what to automate, redesign, or leave with a person. Per-Stack figures walk from the Asset Type to its Service to its Stack. That split is calculated, and it is not stored.
• AI Lens (07) — gives agents a governed reading of the Context: organization, business structure, applications, technology, relationships, classifications, and permissions, through the API and MCP, under the same permissions and audit trail as a person. What an agent can reach is computed from the tools it uses, what those tools can do, and the access granted to its machine identity. Give agents an understanding of the enterprise before giving them control of it.

On the payments example: the Security Lens asks what is exposed behind that Application and how each entry point is protected. The CFO Capital Lens asks how spend on the shared Platform sits against the Retail Banking Domain. An agent reading the AI Lens can ask the same Context before it acts.

Same enterprise. What matters to this person — or this agent — for this decision?

Where it runs

7lens runs in the customer’s own environment. The data, the filled-in model, the processing, and the Context stay there.

That includes sign-in with the company’s identity system, permissions by role, separate permissions for people, AI assistants, and automations, a full audit trail, and data kept in the required region.

Customer data means the Context and everything used to build it: what sources sent, how it was mapped, the reconciled records, and how the lenses are configured.

7lens also runs a management plane as a service. It handles only the part of the core semantic concepts that 7lens needs to operate correctly, driven by human configuration — and nothing else. No customer sensitive data reaches that service. The control plane and the data plane run entirely on customer premises, and most operational semantics run there without the management plane. If the management plane is unavailable, the running system keeps operating. Only human configuration of the service-managed semantic concepts pauses.

How the customer prefers to see time, currency, and language is a setting for the whole Configuration. It changes presentation. It does not change stored values.

What 7lens is not

7lens is the connected picture: a model filled in per customer, a front door for existing data, one reconciled Context, seven lenses, and an open onboarding catalog for technology through OSM.

7lens is not a scanner that finds assets, a service desk, a cloud console, a security monitor, a cost-management product, or a data lake. The systems that produce the original facts stay in place.

Where a CMDB or another source already holds the raw facts, that source stays the authority for those facts, and 7lens does not overwrite it. 7lens is the authority for the connected meaning: the Asset’s type, its belonging, its links, and how disagreements were resolved. A customer can also keep that inventory in 7lens. In both cases the meaning lives here.

Promise

7lens creates one trusted Context from the Ontology — Organization, Groups, Technology, and Business — and the Inventory extension on top of it. Contracts and Processes are future extensions.

Collector brings information in. The Semantic Engine connects it. People, software, and AI assistants read that Context. Seven lenses turn it into different decisions.

The aim is a context layer for technology decisions by people and by AI, so that leaders can govern the company they have today and be ready for the one that is coming, in which people and AI operate it together. A dashboard is only one way to look at it.