Define the outcome.
Canonical intent captures the operation and its constraints independently of a vendor. The tools available today must not silently redefine what the request means.
Skip to the concept
Horistum
One intent.
01 / MEANING
02 / BINDING
03 / EVIDENCE
Clear boundaries.
Different operations.
01 / DELIVERY
02 / DATA
03 / LIFECYCLE
04 / OPERATIONS
05 / PLATFORM TEAMS
06 / AI-ASSISTED DESIGN
A name.
What it is.
A shared horizon for automation
One intent.
Many worlds.
Define what your automation should achieve. Horistum turns human and AI-written intent into a validated, portable model before target-specific artifacts are generated.
Project in active development. A standardization and planning layer, not a runtime executor.
01 / Human and AI-written requests
02 / Explicit meaning and validation
03 / Evidence-backed target output
01 / The concept
Your intent should outlive your pipeline.
A deployment goal is not a Jenkinsfile. A safety requirement is not a line of YAML. Horistum is designed to preserve what an operation means, even when the platform underneath it changes.
The problem is bigger than syntax.
Automation knowledge gets scattered across scripts, platform-specific configuration and team conventions. The goal, its constraints and the assumptions behind it can become hard to distinguish from implementation details.
Translating one configuration format into another does not settle the important questions: what must happen, what must never happen, which approvals are required, and what evidence makes the selected implementation acceptable?
A common model before a specific tool.
Horistum is an AI-first standardization layer for IT and DevOps automation intent. It separates the requested outcome from the implementation chosen to realize it.
Human or AI-written requests become structured intent. Explicit bindings, validation and target compatibility checks then determine what can be projected. Your existing delivery platforms remain responsible for execution.
Choose explicitly.
Select a declared capability implementation and a compatible system. A binding connects meaning to implementation; a binding failure must not rewrite the original goal.
Validate before output.
Check completeness, safety requirements and target evidence before generating runnable artifacts. Missing or unsupported behavior cannot simply disappear in translation.
An illustrative request, not executable syntax
“Deploy billing-api to production. Require approval, preserve the previous release and verify application health.”
What is the intent?
The service, environment, desired operation and constraints belong in a reviewable model, not only in generated platform syntax.
What needs clarification?
The approval requirement needs a concrete mechanism. Release preservation and health verification need explicit meaning and implementation evidence.
What may be generated?
Only output justified by the validated plan and selected target. Unresolved requirements must remain visible rather than becoming implied permission.
This example explains the concept. It is not a live demo, an API contract or a claim that every target supports this scenario.
AI proposes. Standards validate. AI can help express and normalize an automation request. It does not become the authority that decides whether generated automation is acceptable. A fluent proposal is not implementation evidence.
02 / Inside the architecture
Clear boundaries.
Inspectable decisions.
Horistum follows a validation and compilation path, not a black box that takes a prompt and starts changing infrastructure. Each layer has a different responsibility.
-
Human or AI request
Start with an automation goal, entities and constraints. Natural language is a proposal input, not an execution permission.
-
Canonical intent
Establish platform-independent meaning before selecting implementations. Preserve the requested operation and its requirements.
-
Explicit implementation binding
Connect declared capabilities to selected implementations and compatible systems without redefining the intent.
-
Safety and completeness validation
Surface missing information, invalid declarations and unresolved requirements. A requirement and proof of its implementation are different things.
-
Flow AST and Execution Plan
Represent and validate the automation structure. Preserve dependencies, controls and relevant data, workspace and state relationships in a reviewable plan.
-
Target compatibility and readiness
Check the selected target against the plan and its evidence requirements. Unknown or unsupported behavior must remain explicit.
-
Manifest and authorized projection
Produce a target manifest and, where authorized, target-specific artifacts. Renderers consume validated plans; they do not invent new semantics.
Outside Horistum Core
Execution stays with your existing platform. Scheduling work, running tasks and enforcing runtime controls are responsibilities of the selected execution environment.
03 / Intended application areas
Different operations.
The same need for clarity.
The common starting point is not a particular tool. It is an operation whose meaning and safety requirements need to remain understandable across teams and platforms.
Application delivery
Describe the release outcome before choosing pipeline syntax.
Make explicitThe application, environment, approval expectations and health-verification requirements.
Why the boundary mattersChanging a delivery platform should not silently weaken the requirements that made the deployment acceptable.
Database changes
Structure a migration request around more than a command to run.
Make explicitScope, backup expectations and a rollback or recovery strategy.
Why the boundary mattersMissing recovery information should prompt a clear diagnostic, not an invented assumption.
Certificates and secrets
Describe a renewal or rotation with a clear identity and boundary.
Make explicitThe resource, scope and required safety conditions, without exposing secret values in a request.
Why the boundary mattersKnowing which operation is intended is distinct from authorizing a concrete implementation.
Kubernetes maintenance
Make an operational request reviewable before it reaches cluster tooling.
Make explicitThe affected resources, maintenance window, dry-run expectations and operational constraints.
Why the boundary mattersThe plan describes the work. Existing tools and their runtime controls still perform it.
Automation standardization
Develop a shared way to describe intent without forcing a single executor.
Make explicitCommon meaning, dependencies, review criteria and the target differences that matter.
Why the boundary mattersConsistency should come from a shared model, not from hiding differences between implementations.
From proposal to plan
Use AI to help articulate a request, without trusting generated code by default.
Make explicitThe normalized intent, unresolved questions and evidence needed for progression.
Why the boundary mattersThe proposal frontend can evolve while the validation and authorization boundaries stay deliberate.
These are intended application areas, not turnkey service promises. Whether a specific scenario can produce executable output depends on the selected implementation and target evidence.
04 / The idea behind the identity
A name.
A shared horizon.
Different worlds do not need to become the same world to share a reference point.
The horizon and orbital imagery express the idea behind this visual identity: connected systems, distinct responsibilities and a common understanding of intent. The universe is a design metaphor, not a promise to make every platform identical.
Meaning before implementation.
Horistum's mission is to make automation intent understandable, portable and reviewable without surrendering control to vendor-specific syntax or an unchecked AI proposal.
One product, a deliberate history.
Horistum was previously presented as Flow AI. The product name has changed; established technical names such as Flow and Flow AST remain intentional parts of the same project.
The project is in active development. This website introduces the concept and its architectural boundaries, not a production-service availability guarantee.
05 / Questions, without the hype
What it is.
What it is not.
A useful standard needs clear limits as much as an ambitious vision.
Does Horistum execute workflows?
No. Horistum is a standardization, validation and planning layer. Execution remains outside its Core, in the selected platform. It is not another runtime scheduler or workflow engine.
Does it replace Jenkins, Kubernetes or our CI/CD platform?
No. The purpose is to separate automation intent from a particular execution environment. Your existing platforms retain their execution responsibilities. Horistum is not a target-specific public DSL, an SDK-first framework or a general-purpose programming language.
Does one intent work on every target?
Portability is the design goal, not a promise that platforms have identical capabilities. Actual projection depends on scenario-specific compatibility and evidence. Unsupported or unknown behavior must be surfaced rather than silently replaced with a weaker interpretation.
Where does AI fit into the model?
AI can help produce and normalize an intent proposal. Deterministic validation, explicit implementation choices and target evidence govern progression. AI-generated text does not authorize itself and is not trusted as proof of safe automation.
Why not simply generate platform-specific YAML?
Generated syntax describes one implementation. A common model also needs to preserve the goal, constraints and decision boundaries that should survive a change in platform. Horistum places that meaning and its validation ahead of vendor-specific output.
Is this a production service I can subscribe to?
This website describes a project in active development. It does not announce a hosted service, paid plan, service-level agreement or blanket production-readiness claim. Any future availability and supported scope should be stated explicitly.
06 / Start with a real problem
What must remain true when your tools change?
A useful automation model starts with the operation you need to standardize, the platforms involved and the safety requirements that cannot be lost in translation.
Describe the outcome, not just the current script. Identify the approvals, dependencies and recovery expectations that matter. That is the starting point for a shared understanding of intent.