Intentionality Is Not a Step. It Is a Gate.

The first principle of the manifesto reads as a virtue: every generation begins from declared human intent. Stated that way, it sounds like advice. Advice is what teams ignore on a Friday afternoon when the demo is Monday.

Intentionality only becomes load-bearing when it stops being advice and becomes a gate. Not "we should declare intent before generating" — the generation does not run until intent is declared, in a form the system can verify, signed by a human who can be named. That is the difference between a principle on a slide and a principle in the pipeline.

Software is still the expression of human intent. The speed of generation has changed. The need for intent has not.

The diagnosis: intentionality as decoration

Walk through how most teams actually adopt the principle. There is a doc. The doc says: "Before invoking a coding agent, write a brief description of what you want to build and why." The doc lives in the wiki. New engineers read it on day one and forget it on day three. Senior engineers nod at it and skip it because they "know what they want." Nobody enforces it because nothing in the system can enforce it.

Six months later, the audit asks: how do you know the agent built what you intended? The team produces the doc. The auditor asks for the evidence — for one given commit, what was the declared intent, who declared it, when. The room goes quiet. The doc was never connected to the artifact. The principle was decorative.

This is not a moral failure. It is a design failure. Asking humans to be disciplined where the system is permissive produces, reliably, undisciplined humans. The fix is not better posters. The fix is moving intentionality from the prose layer to the control layer.

What a gate actually means

A gate has three properties that a checklist does not.

It is synchronous. The generation cannot proceed until the gate passes. Not "should not." Cannot. The agent invocation receives a missing-intent error and refuses to run. This is the same shape as a CI check that blocks merge — and for the same reason: optional controls are controls only for the people who do not need them.

It is verifiable. The intent is captured in a structured form the system can read: a declaration with named fields (what is being built, what guarantees it must hold, what rules it must respect, who owns those rules). Free-text "describe what you want" is not enough — it cannot be queried, audited, or compared against what was produced. Structured intent can.

It is signed. A named human is attached to the intent at the moment of declaration. Not "the team approved it" — Maria approved this, on this date, with this version of the spec. The signature is what makes accountability possible. It is also what makes the audit short instead of forensic.

These three properties are what GAISD.2.1 ("declaração de intenção como gate") and GAISD.2.3 ("spec funcional governada") describe. The agent runtime that refuses to proceed without a valid intent file is GAISD.4.1 ("geração governada") in operational form. They are not new in concept. Engineers have built CI gates, signed commits, and structured artifacts for decades. The novelty is recognizing that AI-assisted generation needs the same treatment — and probably more, because the cost of an unintended output just dropped to zero.

The objection: this will slow us down

The reflex from teams used to fast loops is predictable: a gate adds friction; we adopted AI to remove friction; therefore the gate defeats the point. This objection is structurally wrong, but it deserves a careful answer because it sounds reasonable.

Two things to notice.

First, the friction the gate adds is a one-time cost per intent, not per generation. Once the intent is declared and signed, the agent can iterate inside that intent freely — five generations, ten, fifty. The gate gates the direction, not the throughput. Teams that conflate the two have not actually used a gated workflow.

Second, the friction the gate adds is the friction the team is already paying, just paying it at the wrong end. The teams that skip declared intent are the same teams writing rollback PRs three weeks later because what shipped did not match what was wanted. The intent conversation happens either way. The choice is whether it happens before code exists, when it costs minutes — or after, when it costs a sprint.

The teams that actually run gated workflows report the inverse of the predicted slowdown. The gate compresses the loop. Engineers stop generating speculatively. Reviews get sharper because the reviewer has the declared intent to compare against. The agent gets better context because the structured intent is the best context it ever gets.

What this looks like in code

A gated intent is not a heavy artifact. It is a small, structured file co-located with the change:

intent:
  id: intent-2026-04-28-billing-proration
  author: mary.jane@company.com
  declared_at: 2026-04-28T14:22:00Z
  what: "Add proration to mid-cycle plan upgrades for the Pro tier."
  must_guarantee:
    - "Customers are charged only for unused time on the new plan."
    - "Existing invoices are immutable; proration creates a new line item."
  must_not:
    - "No retroactive refunds for downgrades — that is a separate flow."
  business_rules:
    - rule_id: BR-117
      owner: finance.ops@company.com
      summary: "Proration uses calendar days, not billing days."
  context_required:
    - billing/subscriptions/lifecycle.py
    - billing/invoices/immutability_contract.md
  reviewers: [tech.lead@company.com, finance.ops@company.com]

The agent invocation reads this file. If the file is missing, malformed, or unsigned, the invocation fails. If the file is present, the agent runs with the declared intent as the top of its context, the cited files as the working set, and the named reviewers as the required approvers on the resulting diff.

Notice what just happened. Intentionality (principle 1), business rule sovereignty (principle 3 — BR-117 is owned by a named human, not inferred by the model), and traceability (principle 4 — every commit can be traced back to intent-2026-04-28-billing-proration and the human who signed it) are now structurally enforced by the same artifact. One gate, three principles operationalized.

What this means for the Tech Lead

Three concrete moves.

Stop treating the intent doc as documentation. Move it from the wiki to the repository, give it a schema, give it a CI check, fail the agent invocation when it is missing. The principle becomes real the moment "I forgot the intent doc" produces a build error instead of a Slack reminder.

Define the minimum viable intent for your domain. A billing change needs different fields than a UI tweak. The schema should capture what is non-negotiable for your system: which business rules must be cited, which architectural boundaries must be acknowledged, which reviewers are required for which kind of change. Generic schemas produce generic compliance.

Make the intent the agent's first context, not its afterthought. If the agent reads the intent file as the top of its prompt, the quality of every subsequent generation rises. If the intent lives in a wiki the agent never sees, you have a control for auditors and nothing for engineers. The artifact has to do both jobs.

The invitation

A principle that the system does not enforce is a principle the team will eventually skip. Intentionality, treated as advice, becomes the first casualty of any deadline. Treated as a gate, it becomes the thing that lets the team move faster — because every generation starts from a declaration that the team has already aligned on.

The five principles of the manifesto are not five aspirations. They are five controls that compound. Intentionality is the first because nothing else works without it. If your team has the principle on a slide but not in the pipeline, that is the next thing to fix.

Sign the manifesto at gaisd.dev/sign, and adopt principle one — human intentionality — not as a recommendation, but as a gate the system enforces.