What an intent contract actually contains

Ask a code generation model to "build a wholesale sales tool with tier discounts," and it will generate 20 files of React components, an ORM schema, and a mock array. It will compile, render buttons, and feel alive for thirty seconds.

Then you ask the operational questions: Can a sales representative quote 40% off without a manager? What happens when a contractor’s credit limit is exceeded? If an invoice is disputed, can line items be altered after payment? The generated code has no answers, because a natural language prompt is not a specification.

"A prompt tells a model what to imagine. An intent contract tells a compiler what must never be violated. In business software, the value is not in rendering the screen — it is in enforcing the boundary."

Why Prompts Are Not Specifications

Natural language is optimized for human nuance, metaphor, and shorthand. Compilers require precision, boundary conditions, and negative constraints. When you prompt an LLM, you are communicating across three severe failure modes:

• Omission of Negative Space: Prompts describe what should happen on the happy path. They rarely specify what must never happen under adversarial pressure.
• Context Window Drift: As an application grows past thousands of lines, subsequent prompts lose track of previously stated rules, introducing subtle regressions.
• Probabilistic Emission: A model predicting the next token has no internal mathematical solver. It guesses plausible-looking code rather than computing structural invariants.

The Five Primitives of ISL

Intent Specification Language (ISL) is a domain-specific language developed at ISL Studio. It bridges human business requirements and deterministic systems engineering by formalizing software into five immutable primitives:

domain CommercialDistribution {
  // 1. ENTITIES: Typed relational records
  entity Contractor {
    id: UUID
    tier: Enum[Silver, Gold, Platinum]
    credit_limit: Decimal
  }

  entity Quote {
    id: UUID
    contractor_id: UUID -> Contractor
    discount: Decimal
    status: Enum[Draft, PendingReview, Approved, Ordered]
  }

  // 2. TRANSITIONS: Explicit state machine verbs
  transition ApproveQuote(q: Quote, approver: Actor) {
    from: Draft | PendingReview
    to: Approved
    requires: approver.hasRole(Role.SalesManager) || (q.discount <= 0.10)
  }

  // 3. INVARIANTS: Mathematical rules that must hold across all states
  policy TradeIntegrity {
    invariant MarginFloor:
      forall q in Quote:
        (q.discount > 0.25) implies (q.status != Ordered)
  }
}

1. Entities & Relations

Entities represent durable business state. Unlike ORM models, an ISL entity defines ownership scopes, cryptographic audit requirements, and foreign key boundaries before a database engine is chosen.

2. State Transitions & Verbs

Entities do not update via free-form mutations. Every modification is an explicit business transition (ApproveQuote, DispatchCrew, IssueRefund). Transitions declare required actor roles, input contracts, and atomic side-effects.

3. Temporal Policies & Invariants

Policies define the invariant core of the business. An invariant is an assertion that must evaluate to true across all database states at the end of every transaction. If a write would violate an invariant, the transaction is aborted by the storage engine.

4. Security & Tenant Boundaries

Row-level tenant isolation is declared directly within the contract. The compiler lowers these rules into native PostgreSQL Row-Level Security (RLS) policies, guaranteeing that data boundaries are enforced regardless of which application layer executes the query.

5. Failure Oracles & Non-Vacuity Rules

An intent contract carries its own verification oracles. For every invariant, the contract specifies an adversarial test beat that intentionally attempts to violate the rule. If the write succeeds during verification, the build is flagged as NO_SHIP.

Deterministic Lowering

Once an ISL contract is validated by @isl-lang/parser and the typechecker, no probabilistic models are involved. The WholeStack compiler engine performs pure, deterministic lowering:

When you change your business logic months later, you don't rewrite code. You edit the clause in your intent contract, compute a semantic diff, and recompile deterministically through the spine. The application is the byproduct; the contract plus the attestation is the product.