by YAMLValidator (LX AI)
Open YAMLValidator, provide the required inputs, run Demo to preview the workflow, then switch off Demo when a live key is configured.
Catch YAML errors before they break your deploy
Decision-support only — confirm before you publish or act.
You need a modern browser that supports JavaScript ES2020. No server installation is required because the tool runs entirely in the client. If you plan to use the live AI explanation you must have a valid API key from the provider; otherwise you can work in Demo mode which uses a built‑in mock model.
Navigate to the product URL. The landing page shows a large text area labelled “YAML source”. Below it you see two toggles: “Demo mode” and “Show line numbers”. Keep Demo mode on for your first experiment; this lets you see the full flow without consuming a key. Click the “Run validation” button to start the process.
When Demo mode is active the tool substitutes the AI explanation step with a deterministic placeholder that repeats the lint message. This lets you verify that the UI, the lint engine and the report generator all work together. Switch Demo mode off only after you have stored your API key in the settings pane; the UI will then call the remote model for each detected issue.
Click the “Upload file” button and select a .yaml or .yml file from your workstation. The validator reads the file as UTF‑8 text, checks for a byte‑order mark and strips it if present. The original file is never modified; a copy is kept in memory for the duration of the session.
Alternatively you can copy the YAML block from your editor and paste it directly into the source area. The tool treats the pasted content exactly as if it were loaded from a file, applying the same line‑ending normalisation (CRLF → LF) before linting.
For automated pipelines you can expose the validator through its public POST endpoint. Send a JSON payload with the field “yaml” containing the raw string and a boolean “demo”. The response includes a JSON lint report and, if demo is false and a key is supplied, an AI‑generated explanation array. The endpoint returns HTTP 200 on success and 400 if the payload is malformed.
The lint engine applies a fixed rule set versioned as yaml-validator@2026-07-19. Rules are grouped into five categories: syntax, structure, references, formatting and safety. Each rule is implemented as a pure function that receives the parsed AST and returns a list of violations with line and column numbers.
When a rule fires the engine records the exact line number (starting at one) and the column offset of the first offending token. The UI highlights the entire line in a light red background and places a tooltip that shows the rule identifier and a short message. Clicking the line number scrolls the source view to that position and expands the explanation panel.
YAML allows anchors (&) and aliases (*) to reuse nodes. The validator builds a symbol table while walking the AST. If an alias refers to a name that was never defined, or if an anchor is defined twice in the same scope, a reference error is emitted. The report includes the anchor/alias text and suggests either removing the duplicate or adding the missing anchor.
After the deterministic lint finishes, each distinct violation is sent to the language model together with a window of five lines before and after the problem. The model is prompted to describe the issue in plain language, to show a corrected snippet that respects the original indentation, and to note any side‑effects the change might have on dependent files. The temperature is set to zero to obtain deterministic outputs.
The returned snippet replaces the offending block with a version that follows the rule’s recommendation. For indentation errors the snippet adds or removes spaces to match the parent level. For duplicate‑key errors the snippet keeps the first occurrence and comments out the later ones with a explanatory note. For quoting issues the snippet adds double quotes around scalars that contain colons or leading zeros.
The AI pass is a decision‑support tool. It never rewrites your file automatically; you must review the suggested snippet and decide whether to apply it. Treat the output as a starting point, especially when the YAML contains custom tags or complex merge keys that the model may not fully understand.
The validator does not promise that every possible YAML mistake will be found. Some logic errors, such as using a wrong environment variable name inside a string, sit outside the scope of syntactic and semantic checks and therefore are not reported.
Even when the tool returns zero warnings you should still read the final YAML before merging to a shared branch. Human judgement is required to assess business logic, naming conventions and compliance with internal standards.
The engine never evaluates the content of your YAML. It does not launch containers, run scripts or call external services. This design choice eliminates the risk of code injection and makes the tool safe to run on untrusted input in a sandboxed browser tab.
After a successful run you can download a JSON report by clicking the “Export” button. The document contains a top‑level “runId” (a UUID v4), a timestamp in ISO‑8601 format, the original YAML SHA‑256 hash, an array of lint objects and, if the AI pass was executed, an array of explanation objects. Each lint object includes ruleId, message, line, column and a severity level (info, warning, error).
The runId lets you correlate the report with logs from your CI system. Store the Id alongside the build number in your artefact repository. When you need to re‑examine a past validation you can request the report again by providing the Id to the internal history endpoint (available only in self‑hosted deployments).
For regulated environments you may archive the raw YAML, the JSON report and the runId together in a write‑once storage bucket. Because the validator never modifies the source file, the archived pair provides a verifiable proof that the configuration passed the defined lint rules at a specific point in time.
I keep a written checklist next to every release that touches this topic. The list is boring on purpose: name the owner, name the evidence artifact, and name the rollback. If a step cannot produce a file, a ticket, or a log line, it is not a step — it is a wish.
| Signal | What to record | Stop-ship? |
|---|---|---|
| Unexpected write or send | Tool name, args, identity | Yes until gated |
| Missing confirmation on destructive action | Call path and bypass | Yes |
| Untrusted text treated as instruction | Source surface and resulting action | Yes for agent reach |
| Scanner clean, judgment open | Deferred items + owner | Only if core path safe |
yamlvalidator helps with the measurable first pass. Architecture choices, legal sign-off, and customer-facing claims still need a human owner. Treat every checklist row as decision support, not a certificate.
When a prospect asks whether the product "covers everything," I answer with the boundary: automated checks catch known patterns; novel chains and policy judgment still need review. That honesty keeps support load down and keeps the blog aligned with what the product actually does.
If you need a second opinion, pair this write-up with the references below and with your own staging reproduction. Do not skip the reproduction step just because a model wrote a confident summary.
Catch YAML errors before they break your deploy
Operators and builders who need a fast first draft or checklist from YAMLValidator.
Yes in explicit Demo mode. Live AI requires a configured key.
No. Outputs are decision-support; you still review before publishing or acting.
Only if those features are implemented in this product build — do not assume them from marketing copy.
Runs may be stored locally under the product's .data/ boundary; treat demos as ephemeral.