Four-stage validation: catching Swift mistakes before you open Xcode

Compilation without validation is just code generation. Axint validates before emitting Swift. Four stages, each progressively more specific, with early exit so you get fast feedback.

Stage 1: Schema

Does your defineIntent() call have the right shape? Required fields present? Types make sense?

typescript

defineIntent({
  name: "SearchNotes",
  params: ["query"],  // ← array, not object
});

error AX001: params must be an object, not an array.

Schema validation is cheap. If it fails, we bail immediately — no point running type checks on a malformed definition.

Stage 2: Types

Are your parameter types valid Swift types? Do custom type references resolve?

typescript

defineIntent({
  name: "ProcessOrder",
  params: {
    orderId: "string",
    user: "UserModel",        // ← not defined
    metadata: { id: "string" }, // ← nested objects not supported
  },
});

error AX005: parameter 'user' references undefined type UserModel.
hint: App Intents support scalar types and enums. Define UserModel as an entity
      or use scalar fields instead.

The hint matters. We don't just say what's wrong — we suggest what to do about it.

Stage 3: Intent semantics

Does the intent conform to App Intent conventions? Are parameters titled? Is the return type valid?

error AX003: parameter 'query' has no title.

  intent.ts:12:5
  12 |    query: "string",
     |    ^^^^^

  Use param.string("Search term") to provide a title.

Each error has a code (AX-prefix), a source location, and a fix suggestion. The MCP server surfaces these as inline diagnostics in your editor.

Stage 4: Swift-specific rules

The generated Swift needs to actually compile. Stage 4 checks Apple-specific requirements:

warning AX112: Intent 'SendMessage' uses a parameter name that shadows a Swift
keyword ('return'). The generated code will use backtick-escaping (`return`),
but consider renaming for clarity.

Stage 4 errors link to Apple's documentation. We don't just report problems; we point you at the relevant WWDC session or API reference.

Early exit

The four stages run in order. If stage 1 fails, stages 2-4 don't run. This means you see one category of error at a time — shape issues first, then type issues, then semantic issues. Faster feedback loop, less noise.

You can run validation standalone:

bash

axint validate intent.ts --json

Returns structured JSON with error codes, locations, and suggestions. The IR post covers how validation operates on the IR rather than the source AST, which is what makes cross-language error reporting possible.