Ontology and Apps
The model arrives built.
Most models of a digital estate are assembled from assertions. Klarvant Namespace Command builds one from observation, and shows you which is which.
Act one
A model is only worth what its provenance is worth.
Most inventories are built from what someone believed was true at the time. A spreadsheet exported and never revisited. A tool pointed at the things it was told to look at. A list maintained by a person who has since changed roles.
The result is a model nobody quite trusts. When a question arrives that actually matters, most teams check the answer before they act on it. That checking is the real cost, and it is why so much good discovery work never turns into a decision.
Namespace Command builds the model differently. Every object in it is classed by how it came to be known:
- Observed. Seen directly by the platform. Your domains, subdomains, DNS records, certificates, TLS endpoints, IP addresses, email services, web pages and technologies. Fourteen types.
- Enriched. Attributed from what was observed. Suppliers, services, network operators, certificate authorities, registrars and jurisdictions. Six types.
- Derived. Computed by the platform. Findings, assessments and posture ratings. Three types.
- Asserted. Stated by you. Organisational units, contacts and owners, claimed domains. Three types.
Twenty-six object types, twenty relationship types, each relationship carrying the evidence it rests on. Where an exact figure is not available, the model shows nothing rather than an invented number.
So you always know why the model believes what it believes. That is the difference between an inventory you consult and a model you can act on.
Generic ontology platforms arrive empty and wait to be told. This one arrives populated, and keeps building itself with every assessment.
There is no modelling project and no services engagement. The model is there on day 1, built from the outside in.
Act two
Then the loop closes.
Every team has a list of things someone is supposed to be watching. A certificate that expires in November. A domain that renews in March. Whether anything new has appeared in the supply chain this week. It lives in a calendar reminder, a recurring ticket, or somebody's memory, and it holds until the week that person is busy.
Every "someone should be watching this" becomes an App.
Apps are workflows you assemble yourself in a drag-and-drop composer. No code. They watch the model, analyse what changes, and carry out the instructions you gave them: raise it in the platform, email the accountable owner, post to Slack, open a Jira ticket.
Drag-and-drop Apps: your triggers, your rules, your systems.
Eight building blocks. Trigger sets what to watch. Matcher narrows it to what matters. Enrich attaches context, such as who owns the asset. Analyse with AI reads each event and explains it in plain language, at a depth you choose. Gate stops the same finding alerting every day. Notify decides who hears about it and where. Act decides what the platform does. Branch splits the path up to four ways, always with an explicit "otherwise", so nothing falls through in silence.
Six triggers, all change-driven: a new finding is opened; a certificate is approaching expiry at 7, 30 or 90 days; a new certificate is observed; a new supplier is detected; a web page is classified into a category you are watching; a domain registration is approaching expiry. Each run looks at what is new since your last completed assessment, so an App reacts to change rather than restating what you already know.
Describe the App. Review it. Run it. An App can be drafted by AI from a plain-language description. You review every block before saving, and nothing runs until you enable it.
Governance is built into the automation, not bolted onto it. Recipients are chosen from your organisation's members and its verified accountable owners. Free-typed addresses cannot be entered at all, so an App cannot send outside your governed audience. Every action it takes, every notification, every finding raised, every re-check requested, is recorded in the App actions ledger with timestamp, target and outcome, filterable and exportable. Each App keeps a run history showing which path it took and why. A dry run shows exactly what an App would do against today's data without sending anything or changing anything. Sending is bounded by fair-use caps.
Twelve ready-made templates cover the familiar cases, so the first App is running in minutes rather than being designed from a blank canvas.
Act three
A Monday morning.
A vendor publishes a vulnerability. The question that follows is always the same: where are we exposed? It is usually answered by three teams, several spreadsheets and two days.
Because your estate is already modelled, it is one search. Namespace Command tracks newly published CVEs, enriches them with exploitation context, and matches them against the technologies actually detected in your estate. Dependency Signals shows which products, which vendors and which domains are affected, and how far it reaches.
The intent is relevance, not news. Not "a new CVE was published", but here is where it touches you.
And because the model is connected to your Apps, the same event can open the ticket, notify the owner, and request a re-check once the fix lands. No one has to be at their desk for that to begin.
Close
What comes next.
Today the model is built from what Klarvant observes. We are working on letting you layer your own view over it: your organisational structure, your business services, your priorities, grounded in an estate that has already been independently observed. Model meets reality. This is in development, not yet available.
Governance, enacted.