[Name] is the platform for building and running network services. Describe a service of your domain in plain English: its parameters, the steps of each operation, what must be true afterwards. The platform takes the specification in, builds the service from it, proves it in the lab, and publishes it to the catalog with your name on it.
Capabilities
Everything between a specification and a running service, so you can concentrate on the network.
A service is a domain specification in plain English: parameters and where each comes from, the steps of create, modify and delete, scenarios, examples. Bound to a template or an existing executor, it generates the product folder. No new language to learn.
Order form, inventory mapping, NSO package and test suite are generated from the specification. Change the specification, and everything follows.
Scenarios run in the lab. Predicted network state is verified. Conflicts with existing products are detected. Each domain controller's scenarios are written from outside the controller, so every solution runs the same ones. Approvers see evidence, not descriptions.
Every product carries its owner, on-call, version and risk class. Every instance shows its status, its history and its drift. Ownership lives next to the product, in the repository.
A change is a pull request with its checks attached. Review, approve, merge — the audit trail is complete without anyone writing it.
Services are applied by executors — NSO, the Check Point management API and other managers. Only executors touch devices. Post-change verification confirms the network is in the predicted state.
How it works
From a specification to a service in the catalog.
Describe the service at the front door: answer questions or submit the file. The gate says its level and what binds it; a merge request goes to your domain.
The platform generates the form, inventory mapping, NSO package and tests.
Scenarios run in the lab, predicted state is verified, conflicts are checked. Results are attached to the change.
Reviewers see the evidence and the risk class, and approve in the pull request.
The product is orderable. You see every instance, every change, every drift — and you are the one on the product page.
Ordering a service
Instances go the same way: fill in the generated form (or write the record directly), checks run, approval, applied. Same evidence, same trail.
Changing a product
Edit the specification, open a pull request. The platform rebuilds and re-proves everything; existing instances are re-verified against the new version.
Existing services
Config already in the network is imported into products through an adoption step you confirm. The platform reports what it finds; it never changes it unasked.
Click demos
Click through how people use the platform, one activity at a time. Each demo shows the stories and features it covers, and whether it is imagined, specified or proven.
A1 · Contribute a product
features F017 F016 F015 F032
Walk through it →
A1 · Contribute a product
features F015 F016 F026 F027 F032
Walk through it →
A1 · Contribute a product
features F026 F015 F027 F012 F032 F072
Walk through it →
A4 · Order a service
features F014 F101 F110 F111 F040 F042 F031 F024
Walk through it →
A4 · Order a service
features F111 F025 F041 F030 F104 F033 F062 F031
Walk through it →
A4 · Order a service
features F012 F111 F052 F031 F026 F072 F063
Walk through it →
A7 · Operate a service
features F083 F081 F082 F040 F072 F101 F111
Walk through it →
A10 · Run the platform
features F082 F016
Walk through it →
A10 · Run the platform
features F027 F014 F032
Walk through it →
The catalog
Every service the network offers, with its owner, version and status. Order from here; contribute from here.
| Product | Owner | Version | Risk class | Instances | Status |
|---|---|---|---|---|---|
| l2vpn-cloud-attachment | M. Weber | 1.0 | B | 38 | Published |
| l3vpn-site | A. Novak | 2.3 | B | 412 | Published |
| internet-access-business | A. Novak | 1.4 | A | 690 | Published |
| dc-tenant-fabric | S. Ito | 1.1 | C | 27 | Published |
| acl-edge-policy | M. Weber | 0.9 | A | 13 | In review |
| sdwan-branch-overlay | L. Braun | 0.3 | B | — | In sandbox |
Sample entries. Live data on the catalog page.
The sandbox
Try a template against virtual devices, run your scenarios, see the rendered config — before anything becomes a product.
For platform engineers
The platform is built to be extended.
Turn a bound domain specification into the product folder, schema, form, NSO package and tests. Add a generator, and every product gains the capability.
Policies, conflict rules, verification queries. Written once, applied to every change, in CI and at admission.
A domain offers its resource types through a native controller or an adapter in front of the API it already has. What each operation does in the domain's system is specified once, for every solution; how it runs is the solution's. Domain controllers
Encode how products are built here so the assistant drafts them the way your team would. Versioned with the platform.
Models
The platform and its agents use language models only through model endpoints registered in the platform. The default endpoint runs locally. A model the customer already uses can be added where their data protection covers it.
Click demo: configure models →feature F082
Architecture, API reference and contribution guide: [docs URL]
Getting started
Most people finish the first two in an afternoon.
Sign in with your network account. Pick a template you already have, or start from a catalog product as an example.
[sandbox URL] →Add two or three worked examples and the scenarios you care about. Let the assistant draft the schema, then correct it.
[guide: your first product] →Submit the domain specification; checks run; a reviewer of your domain approves. Your product is in the catalog with your name on it.
[platform team channel] →FAQ
No. Templates, scenarios and worked examples are the contribution. If you enjoy scripting, scripts are welcome as product components and run through the same checks.
The executors you already run — NSO, the Check Point management API and other managers. The platform renders products into executor calls; only executors talk to devices.
Two things. Agents that draft — schemas from templates, scenarios from examples, explanations of failed checks — for a person to put into a pull request; the checks and the reviewers decide. The platform assistant, a side panel on every page, answers questions from what the person may read and names its sources, and proposes steps in the designer and the interview for the person to confirm. It never orders, changes, approves, merges or opens a pull request (F083). Neither applies anything. Demo: ask the platform
Not by default: the default model endpoint is local. An external model is used only if the platform team registers an endpoint for it, through a merge request, naming the data-processing agreement that covers it. Each request names its purpose and data classes and goes only to an endpoint allowed for both; otherwise it is refused. Every call is recorded in the trace and audit. Models
A label on each product that sets how much proof is needed before it ships: Class A ships on green checks; Class B adds a second reviewer and a lab run against the current network; Class C adds staged rollout and a change window.
The change stops and the report names the scenario or verification that failed and what it observed. Fix the specification, push, and the checks run again.
Every domain follows the same rules (F027.R16–R24). A refusal fails the resource with the system's message; it is applied again only when the request changes or a person retries it. An outage is retried. Only fields declared to change in place change; any other change is refused, and the resource is deleted and created again. A controller changes only objects it created. A difference made in the domain's system is reported as Drifted and not corrected; a person applies the resource again or changes it. A resource others depend on is removed last. A removal that fails shows Deleting; an operator retries it or releases the resource. F027.R16–R24 · Domain controllers
Yes. The adoption step imports existing config into product instances and shows you the diff. Zero diff means adopted; you confirm before the platform manages it.
The platform team at [platform team channel]. Each product page also lists its owner and on-call.
Try a template against virtual devices, run your scenarios, submit the specification. The same checks run as for every product.