We make business knowledge a first-class engineering artifact.

Business knowledge is trapped in code, heads, and scattered docs. Specy is a structured specification layer that connects product intent to system behavior: traceable, verifiable, and usable by humans and machines.

Run Specy on your codebase

When your system knows more than your team

Every team that builds, rewrites, or evolves software faces the same risk: the knowledge that makes the system work is invisible to the people who need it.

Legacy modernization

Ambiguous specs & rework

Building from scratch

The problem

A 15-year-old Java monolith processes 200K transactions daily. Three people who understood the payment rules have left. You need to rewrite it but nobody can tell you what the system actually does.

With Specy

Specy distills 47 domain concepts, 23 operations, and 12 policies from 400K lines of code. The team reviews the model in hours, not months. Your PO can read it. Your architect can trust it.

"Here's what your system knows and here's what you risk losing by rewriting"

The problem

Your PO writes a story: "As a merchant, I want to cancel a transaction". It sounds clear. Your dev interprets and build code from it. Three sprints later, you discover that cancellation during a payment retry was never specified. Human or AI, the result is the same: ambiguous specs produce ambiguous software.

With Specy

Specy anchors the story against the existing model. It maps 3 impacted concepts, 2 state transitions, and 1 refund policy. It reveals 2 uncovered cases before anyone writes a single line of code. The AI builds from the spec. An independent checker verifies the output against the same model. Human review focuses only on what requires judgment.

"The spec shows what you want, what it impacts, and what you forgot"

The problem

You're starting a new project. Everyone is aligned, for now. But domain rules live in people's heads, specs live in scattered docs, and by sprint 3 the team is already building on assumptions nobody validated.

With Specy

Start by describing your domain in conversation. Specy structures it into a model your whole team can read and challenge, before the first line of code exists. When you start building, the AI generates from the spec, not from guesses.

"Anchor the knowledge early and stay aligned as you build"

How Specy works

Specy works in three steps. Each one feeds the next.

1 Distill

Connect your repo. Get a readable domain model in minutes.

Your code

DISTILL

order.domain.specy

module Order

policy mustBeActive(c: Customer)
  :: "Only active customers" {
  c.status = active
}

entity Order :: "A customer order" {
  identifier id : uuid
  fields {
    status : OrderStatus
    items  : list<OrderItem>
    total  : Money required
  }
  references {
    customer : Customer 1..1
  }

  invariants {
    hasLines :: "At least one item" {
      isNotEmpty(items)
    }
  }

  operations {
    "Place an order" on PlaceOrder {
      resolves Customer from cmd.customerId
      policy mustBeActive(Customer)
      creates Order {
        status = draft
        customer = Customer
        items = cmd.items
      }
      emits OrderPlaced
    }

    "Cancel" on CancelOrder {
      resolves Order from cmd.orderId
      sets Order { status = cancelled }
      emits OrderCancelled
    }
  }

  transitions {
    [*] --> draft on "Place an order"
    draft --> confirmed on "Confirm"
    draft --> cancelled on "Cancel"
    confirmed --> shipped on "Ship"
    shipped --> delivered on "Deliver"
  }
}

enum OrderStatus {
  draft, confirmed, shipped,
  delivered, cancelled
}

value Money {
  fields {
    amount   : decimal min(0)
    currency : string
  }
}

2 Dialogue

Ask any question about your system. Get answers grounded in the model, not in someone's memory.

order.domain.specy

module Order

policy mustBeActive(c: Customer)
  :: "Only active customers" {
  c.status = active
}

entity Order :: "A customer order" {
  identifier id : uuid
  fields {
    status : OrderStatus
    items  : list<OrderItem>
    total  : Money required
  }
  references {
    customer : Customer 1..1
  }

  invariants {
    hasLines :: "At least one item" {
      isNotEmpty(items)
    }
  }

  operations {
    "Place an order" on PlaceOrder {
      resolves Customer from cmd.customerId
      policy mustBeActive(Customer)
      creates Order {
        status = draft
        customer = Customer
        items = cmd.items
      }
      emits OrderPlaced
    }

    "Cancel" on CancelOrder {
      resolves Order from cmd.orderId
      sets Order { status = cancelled }
      emits OrderCancelled
    }
  }

  transitions {
    [*] --> draft on "Place an order"
    draft --> confirmed on "Confirm"
    draft --> cancelled on "Cancel"
    confirmed --> shipped on "Ship"
    shipped --> delivered on "Deliver"
  }
}

enum OrderStatus {
  draft, confirmed, shipped,
  delivered, cancelled
}

value Money {
  fields {
    amount   : decimal min(0)
    currency : string
  }
}

DIALOGUE

Your team talks to the model

Can a customer cancel an order after it has been shipped?

Specy

No. The model only allows cancellation from draft or confirmed. Once an order reaches shipped, the only transition is to delivered.

(Order.transitions, "Cancel" operation)

What if we need to allow it?

Specy

Contradiction: shipped items need a return flow that doesn't exist in the model. Use /spec to formalize this change.

3 Spec

Feed a user story to Specy. It confronts the story against the model, surfaces contradictions and gaps, and produces a formal spec.

User story → confrontation

A customer should be able to cancel an order after it has been shipped.

SHOP-1247

Specy /spec

Decomposition against order.domain.specy:

Order [EXISTING] CancelOrder [EXISTING] OrderCancelled [EXISTING]

Order.transitions { shipped → cancelled } [NEW]

Specy /spec

[CONTRADICTION] Transitions restrict cancellation to draft and confirmed. No path from shipped to cancelled.

[IMPACT] StockService.restock assumes products in warehouse. Shipped items need a return flow.

[GAP] No return process modeled. Refund sequencing with physical return not addressed.

SPEC

cancel-after-shipping.spec

spec "Cancel after shipping"
against module Order version "a1b2c3d"
uses module Order

narrative {
  "As a merchant, I want to cancel
   an order after it shipped."
}

concepts {
  entity Order [existing]
  command CancelOrder [existing]
  event OrderCancelled [existing]
  transition shipped --> cancelled [new]
}

confrontation {
  contradiction "Blocks shipped" {
    "Policy restricts to
     {draft, confirmed}."
  }
  gap "No return process" {
    "Shipped items need return."
  }
}

changes "order.domain.specy" {
  modify Order.transitions {
    add shipped --> cancelled
      on "Cancel an order"
  }
}

impact {
  operation Order."Cancel an order"
    -> affected
  operation Order."Deliver a shipped order"
    -> affected
  policy maxOrderAmount -> none
}

order.domain.specy

See what your system knows.

We'll run Specy on one of your modules.
One hour. No commitment. You keep the model.