01 · Governance
One layer decides
Business logic lives only in the decision layer: INAF defines what runs, when and with whose permission. The execution tools are interchangeable.
Design principles
The tools execute. INAF decides.
02 · Evidence
Three outcomes, all audited
Every decision ends in an automatic action, an action under approval or a recommendation only, and all of them are recorded, even the one nobody ran.
03 · AI with limits
AI complements the rules
It covers queries that cross sources, alarm correlation and conversation with the operator. Every action it requests goes through the decision engine, and raw data never leaves the client's network.
What it is
First normalize, then govern, and only then automate.
INAF is CTH's reference architecture to automate network operations without losing control. Today it exists as a design and a build plan —not as an installed product— and it is built and adapted together with your team.
Connects to what you already have
It receives whatever starts a task: monitoring events, tickets, self-service, APIs, schedules and ChatOps.
Control and compliance
Access tied to the client's directory, approvals based on criticality, immutable auditing and versioned policies with review.
Reversible execution
Every change runs with verification and the ability to roll back on failure.
Architecture
Five layers, each with a single responsibility.
Components talk through an event bus, and the source of truth, the orchestrator and the monitoring can be swapped without touching the other layers.
-
1 · Triggers
They receive whatever starts a task: monitoring events, ITSM tickets, self-service, APIs, schedules and ChatOps.
-
2 · Control and decision
The core of INAF. It normalizes and enriches each request with the source of truth, evaluates policies and rules, compares actual against desired state and decides.
-
3 · Execution
It runs idempotently and with rollback, with no business logic: it knows what to run, on which device and how to revert, not why.
-
4 · Governance
Access control tied to the client's directory, approvals by criticality with a time limit, immutable auditing and versioned policies.
-
5 · Infrastructure
The client's network devices and clouds. They only run what INAF governs; they never decide.
Plus two lateral components: observability, whose telemetry feeds new triggers and decisions, and integrations with tickets, chat, email and CMDB in both directions.
Build
Built in phases, inside your operation.
INAF is not an installed product: it is an architecture that we build and adapt with your team, starting with the first use cases. CTH engineers work with your team at every step.
01
Assessment and modeling
We align priorities (operations, risk and compliance) and define the first use cases with measurable impact.
02
Build and integration
We build the components that are needed and integrate them with the client's channels and tools: tickets, monitoring, self-service or ChatOps.
03
Sustainable scaling
We scale use cases with consistency, governance and traceability, keeping an operating standard for the team.
Contact
Talk about INAF
Tell us about your network operation and we will assess together whether INAF, or part of its architecture, is the way to go.
INAF is a framework from CTH Soluciones Tecnológicas SAS · Tax ID (NIT) 901.566.331 · Bogotá, Colombia