Ceez FlowCEEZ FLOW
Log inSign up

Governed network change

Network change, without the risk.

Connect the network you run, draw or describe a change, and see exactly what it will do on the real devices. A person approves it, it is applied as one transaction, and it is proven, or undone.

Sign up Log inSee how you use it
  • NETCONF
  • OpenConfig YANG
  • Confirmed commit
  • Automatic undo
  • Audit trail
Review changes · checked against the real devices
Add 1Take over 1Change 1Remove 1In place 4
  • Take overlink spine1 Ethernet2 ↔ branch-leaf Ethernet49

    The service already runs it: no device changes

  • Changelink branch2-leaf Ethernet50 ↔ spine1 Ethernet3

    branch2-leaf: +1 · spine1: +1 (MTU 9000)

  • Addlink branch-leaf Ethernet3 ↔ branch2-leaf Ethernet4

    branch-leaf: +4 · branch2-leaf: +4 (10.51.0.2/31 from pool)

  • Removetest-link (removed from the network)

    branch-leaf: −2 · hq-leaf: −2

Every change is a dry run on the live devices first. Nothing is written until it is approved.

Illustrative screen

The platform

One path for every change, from intent to proof.

Network teams stitch together spreadsheets, scripts, tickets and screenshots. CEEZ FLOW puts the whole change on one governed path.

01

Connect

Bring in the network you already run

Discover devices, pin each SSH host key, prove read and write access, and store a baseline. Logins are saved once, encrypted.

Replaces: a spreadsheet of devices and shared passwords

02

Design

Draw the change, or describe it

A drag-and-drop canvas, service models from YANG, and AI that fills in the details from a sentence. The change is worked out for you, device by device.

Replaces: hand-built configs and copy-paste

03

Govern

Approval on the exact plan

A person sees what will be added, changed and removed. Approvals are bound to the plan, with policies for who and how many.

Replaces: a ticket and a hope

04

Execute

One transaction across every device

Confirmed commit, read-back, and automatic undo if anything fails. Only the difference is applied.

Replaces: commands typed on each box

05

Prove

Evidence, drift and compliance

Every step is recorded. Services are checked against the devices, and devices against standards such as NIST, CIS and PCI.

Replaces: “did it work?” and screenshots

How you use it

Five steps. The same for every change.

This is what a user actually does, and what the platform does for them at each step.

  1. STEP 01

    Connect your network.

    Point CEEZ FLOW at an address range and a saved login. It finds what answers, shows each device’s SSH key to trust, and proves it can actually change the device before anything depends on it.

    You

    • Give an address range or a list
    • Choose a saved credential
    • Trust each device’s key

    CEEZ FLOW

    • Pins the SSH host key
    • Proves a real write (lock taken and released)
    • Stores a baseline revision and reads the topology
    Onboarding · discovery and readiness
    10.20.0.0/24found 4 devicesCredential: lab-netconf
    • hq-leaf10.20.0.11ReadyRead and write proven (lock taken and released)
    • branch-leaf10.20.0.12ReadyRead and write proven (lock taken and released)
    • dc-leaf10.20.0.13Read onlyCan be read; a write was refused
    • edge-710.20.0.27BlockedLogin refused: check the credential

    A device is trusted only after its SSH key is pinned and a real write has been proven. A baseline of its configuration is stored before anything runs.

  2. STEP 02

    Draw or describe the change.

    Draw devices, links and customer networks on a canvas, or say what you want in a sentence. Ports, link addresses and next hops are filled in from your inventory and address pool, and every value says why.

    You

    • Drag devices and links, or type a request
    • Take over services that already run
    • Remove what should come off the network

    CEEZ FLOW

    • Chooses free ports and the next free subnet
    • Spots conflicts and offers a fix
    • Keeps the canvas matching what the devices show
    Designer · Frankfurt Fabric
    spine1spine2hq-leafbranch-leafdc-leaf

    Fill it in for me

    A VPN for Globex between hq-leaf (10.1.0.0/16) and branch-leaf (10.2.0.0/16)

    Ports, link addresses and next hops filled in from your inventory and address pool, each with its reason.

    Link spine2 Ethernet3 ↔ branch-leaf Ethernet4 clashes with a deployed link service.

    Take over serviceUse free portsRemove
  3. STEP 03

    Review exactly what will happen.

    Before anyone approves, every change is dry-run against the live devices. You see each element as add, take over, change or remove, and what it does on each device.

    You

    • Open Review changes
    • Read the plan, device by device
    • Fix problems with one click, or with AI

    CEEZ FLOW

    • Dry-runs every element on the real devices
    • Shows problems in plain words, not config paths
    • Refuses what would conflict with another service
    Review changes · checked against the real devices
    Add 1Take over 1Change 1Remove 1In place 4
    • Take overlink spine1 Ethernet2 ↔ branch-leaf Ethernet49

      The service already runs it: no device changes

    • Changelink branch2-leaf Ethernet50 ↔ spine1 Ethernet3

      branch2-leaf: +1 · spine1: +1 (MTU 9000)

    • Addlink branch-leaf Ethernet3 ↔ branch2-leaf Ethernet4

      branch-leaf: +4 · branch2-leaf: +4 (10.51.0.2/31 from pool)

    • Removetest-link (removed from the network)

      branch-leaf: −2 · hq-leaf: −2

    Every change is a dry run on the live devices first. Nothing is written until it is approved.

  4. STEP 04

    Approve the exact plan.

    The approver sees the same plan, the devices it touches and what it removes. The approval belongs to that plan only: if the network moves, it stops and asks again.

    You

    • Open Approvals
    • Check the plan and the devices touched
    • Approve or reject

    CEEZ FLOW

    • Binds the approval to the plan’s fingerprint
    • Applies policy: tiers, four-eyes, readiness
    • Records who decided and when
    Approvals · waiting for a person
    Design Frankfurt Fabric r3PendingTier 2

    Touches branch-leaf, branch2-leaf, spine1, spine2

    Roll out revision 3: 0 to add, 4 to take over (no device change), 1 to change, 0 to remove.

    plan 766e4c893d5c295a…

    ApproveReject

    An approval is tied to this exact plan. If the devices change before it is applied, the run stops and asks again.

  5. STEP 05

    Apply, verify and prove it.

    The change is applied as one all-or-nothing transaction, read back from the devices, and checked against the network. If a step fails, everything the run changed is undone.

    You

    • Watch the run, or walk away
    • Open the evidence if you need it
    • Roll back to an earlier state when required

    CEEZ FLOW

    • Confirmed commit with read-back
    • Undoes newest first on failure
    • Verifies services and links, records the result
    Execution · every step recorded
    1. ✓Check the devices are readyRead and write proven on 4 devices
    2. ✓Roll out Frankfurt FabricApproved by an administrator
    3. ✓Apply the designConfirmed commit on 4 devices, read back
    4. ✓Verify the network matchesEvery service in sync; links seen on both ends
    5. ✓Record it as the networkTopology updated
    If a step fails: everything this run changed is undone, newest first, and the evidence of what happened stays with the run.

Illustrative screens, drawn from the product

Use cases

What teams run on it, day to day.

The first five are ready-made workflows you add with a click. The rest use the same services, approvals and undo.

Provision a customer VPN

A new customer signs up across two offices.

  1. Dry run→
  2. Approval→
  3. Deploy→
  4. Prove

Both sites configured together, checked against the devices, with the VPN proven before you tell the customer.

Add a site to a live VPN

A customer opens another office.

  1. Dry run→
  2. Approve→
  3. Apply→
  4. Prove

Only the new site’s device is touched. Every other site is left exactly as it is.

Port maintenance window

Carrier circuit work or an optics swap.

  1. Port down→
  2. Do the work→
  3. Second approval→
  4. Restore

The port comes back exactly as it was, with two approvals on record: start and finish.

Drift audit and repair

Someone changed a device by hand.

  1. Audit all services→
  2. Approve→
  3. Repair→
  4. Audit again

Every drifted service found, repaired under approval, and proven clean.

Decommission a service

A customer leaves, or a service retires.

  1. Approve→
  2. Remove→
  3. Restore

The service is removed and each device gets back exactly what it had before.

Fleet-wide change

Raise the MTU on every uplink.

  1. One request→
  2. Reviewed plan→
  3. Apply once

One reviewed change across many ports and devices, and a single removal restores every old value.

Take over an existing network

You already run a network and want to manage it from one place.

  1. Onboard→
  2. Take over services→
  3. Edit on the canvas

Existing services become managed without touching a device. From then on a canvas edit is a real, reviewed change.

Compliance and audit evidence

An auditor asks what changed and whether you comply.

  1. Scan→
  2. Findings→
  3. Accept exceptions→
  4. Schedule

27 ready-made policies across NIST, CIS and PCI-style standards, or your own rules, with scores and accepted exceptions.

AI-assisted change

You know the outcome but not the config.

  1. Describe it→
  2. AI proposes→
  3. Platform re-checks→
  4. You approve

Agents draft the workflow or fix a conflicting design. The platform verifies every proposal; nothing runs without approval.

Governance

Control is part of the path, not bolted on.

Network changes fail in the middle. CEEZ FLOW assumes that, and is built so a failure leaves the network as it was and leaves a record of why. The same controls apply whether a person or an AI agent started the change.

Approval bound to the plan
A changed network invalidates the approval. A run is never applied on a plan nobody saw.
Policies
Require four eyes, require ready devices, cap blast radius, and require review where you decide.
Readiness gate
Changes only reach devices that have proven they can be read and written.
Undo built in
Every change is a confirmed commit with a read-back, and is undone automatically if a step fails.
Audit trail
Each step, decision and piece of evidence is recorded with who and when.
Secrets
Logins are encrypted at rest, never shown again, and rotated in one place.
Isolation
Each organization’s data is separated at the database, not only in the application.

With AI

AI that proposes. People who decide.

AI removes the typing, not the accountability. Every proposal is checked by the platform and every action still goes through approval.

01

Describe it

Write a request in words. The platform completes it, shows every value it chose and why, and checks it against the service model before it is used.

02

Fix it

When a design conflicts with the network, a reviewer explains why and proposes the smallest fix. The platform re-checks each proposal: what it resolves, what remains, what it would break.

03

Draft it

Agents design a workflow from a stated outcome for you to review, with the same approval and undo as anything else.

  • Agents can read and propose. They cannot approve or apply.
  • What an agent reads from the network is data, never instructions.
  • Bring your own model, or switch agents off by policy.

Under the hood

Built on open standards, so it fits what you have.

To the network

  • NETCONF over SSH
  • OpenConfig and vendor YANG models
  • Confirmed commit where the device supports it
  • A YANG library for your platforms

To your systems

  • REST API for everything the console does
  • Workflows exported as BPMN
  • Web calls and schedules inside workflows
  • Services published from your own models

To your people

  • Guided console for engineers
  • Approvals for the people who decide
  • An audit trail for the people who ask
  • Optional AI, with the model you choose

For your team

Network operations becomes operating capacity.

Network engineers

Draw it, review it, ship it.

Design on a canvas, see the real difference on the live devices, and roll out without typing a command on a box.

NetOps leaders

Fewer incidents. One record.

Replace tickets and tribal knowledge with a path that is the same every time, with every change on record.

Security and risk

Explicit authority. Evidence.

Approvals, limits and compliance checks are part of the path, with an audit trail you can hand over.

Automation teams

One safe path for people and AI.

People and agents use the same governed route: agents propose, people decide, everything is undoable.

Questions

Things people ask first.

Which devices does it work with?

Any device that speaks NETCONF and models its configuration in YANG. CEEZ FLOW maps services onto OpenConfig and is verified end to end on a six-node NETCONF and OpenConfig fabric. Extending it to your vendors is done through the YANG library and a mapping for your platform, and we would do that with you during onboarding.

Does it replace the tools we already use?

It sits above the devices, not instead of your monitoring or source of truth. You keep your tools; CEEZ FLOW is where a network change is designed, approved, applied and proven. Workflows can also call out to other systems over web calls.

What happens if a change fails halfway?

Each change is a confirmed commit with a read-back. If a step fails, the run undoes what it changed, newest first, and keeps the evidence of what happened. You can also choose to keep what worked and carry on.

How are AI agents controlled?

Agents can read the network and propose. They cannot approve or apply, and what they read from the network is treated as data, never as instructions. The platform re-checks every proposal against the live devices, and nothing runs until a person approves it. An organization policy can switch agents off.

Can we bring existing configuration under management?

Yes. Onboard the devices, then take over the services that already run. Nothing on a device changes when you do. After that the canvas manages them: a change is reviewed and approved, and removing something takes it off the network.

Which AI model does it use?

Your choice: any OpenAI-compatible endpoint or Anthropic. It is configured per organization, and the AI features are optional.

Where does it run, and how are logins stored?

As a set of containers you run yourself: an API, a web console, PostgreSQL and Redis. Logins are encrypted at rest with a key you control, and each organization’s data is isolated at the database.

How do we get started?

Log in, onboard a few devices, and take a service through the five steps above. Write to info@ceez.ai and we will walk through it with your network.

Get started

See your network change under control.

Log in, onboard a few devices, and take one change through the five steps.

Sign up Log inWrite to us

Prefer email? info@ceez.ai