# Krafthaus App Contract v1

Status: Accepted
Date: 2026-06-11

## Purpose

Krafthaus is the Forward-deployed product layer for Decide. It turns one consequential customer workflow into an application surface with a clear operating contract:

```text
intake -> rulebook -> record -> handoff
```

A Krafthaus app is not a loose prompt or one-off memo. It is a bounded workflow surface that installs Decide where a verdict, record, or handoff matters.

## Ownership Boundary

Krafthaus owns the application surface: the workflow framing, intake contract, purpose-specific interface, customer-facing artifact, and execution handoff.

Decide owns deterministic evaluation: Rulebook v1 validation, trusted adapter lineage, Decision Record creation, verification, replay, and the lower-level API/runtime contract.

This split is the product architecture:

- Krafthaus makes Decide usable inside a specific customer workflow.
- Decide makes the workflow result deterministic, replayable, and auditable.
- Decision Memos are one application, not the definition of Krafthaus.

## Required Shape

Every Krafthaus app should declare:

1. Workflow purpose and owner.
   The app must name the customer workflow, the accountable operator, and the consequential action or handoff it supports.

2. intake contract.
   The app must define the input fields it needs before the workflow can run. For memo runs this is question, KPI, options, guardrail, and evidence. For execution gates this is proposed action, actor, amount, policy facts, risk, and execution context.

3. rulebook or trusted adapter binding.
   The app must state whether facts are supplied directly, normalized through a trusted adapter, or both in separate stages. Customer-supplied executable code does not run inside Krafthaus. If purpose-specific code is required, it must be registered as a trusted adapter with pinned version, manifest hash, input/output schema, and execution boundary.
   Supported production bindings are `direct_declarative_rulebook` and `trusted_adapter_facts_then_declarative_rulebook`. `customer_executable_rulebook` is unsupported: customer executable code does not run inside Decide or Krafthaus as Rulebook v1.

4. Decision Record.
   The app must preserve the Decide response fields needed for review: verdict, application verdict when present, reason code, matched rule, action, evidence, rulebook lineage, adapter lineage, record hash, receipt hash, verify URL, replay URL, and request identifiers.
   For deterministic Decide-backed claims, the app must satisfy Decide's
   `decide_application_binding_v1` contract before execution handoff by
   capturing at minimum `rulebook_contract`, `runtime_binding`, `verdict`,
   `application_verdict`, `action`, `reason_code`, `matched_rule_id`,
   `rulebook.hash`, `input_hash`, and `rulebook_attestation.bundle_hash`.

5. Workflow interface.
   The app must render the result in the form that the operator can actually use: memo, notary response, packet JSON, review screen, score, dashboard row, or implementation handoff.

6. execution handoff.
   The app must state what happens next: proceed, block, defer, review, ask for missing input, open a ticket, anchor a hash, write back to CRM, or hand the artifact to a human owner.

7. Outcome path.
   When the workflow repeats, the app should define how execution receipts, outcome records, rollback triggers, or later review evidence flow back into the operating loop.

## Application Manifest v1

Application Manifest v1 is the machine-readable form of this contract. It binds
one Krafthaus workflow surface to an exact Decide runtime, intake contract,
rulebook or trusted adapter, Decision Record requirements, action boundary,
handoff, and outcome path.

- Schema: https://www.krafthaus.app/schemas/krafthaus-application-manifest-v1.schema.json
- First reference manifest: https://www.krafthaus.app/manifests/solana-execution-gate-v1.json
- Application registry: https://www.krafthaus.app/manifests/index.json
- Registry schema: https://www.krafthaus.app/schemas/krafthaus-application-registry-v1.schema.json
- Pinned Decide runtime: https://api.decide.fyi/manifests/rulebook-runtime-v1.json
- Decide application binding: `decide_application_binding_v1`, published under
  `application_binding` in the pinned Decide runtime manifest.
- Rulebook runtime decision: https://www.krafthaus.app/docs/DECIDE_RULEBOOK_RUNTIME_DECISION.md

The manifest is closed and fail-closed. It does not allow customer-supplied
executable code, and it must pin the exact Decide runtime contract and canonical
rulebook hash it expects.
Krafthaus CI compares conformant runtime pins and registered candidate rulebook
pins to Decide's authoritative contracts so drift fails before deployment.

The Application Registry distinguishes `conformant` applications with published
Application Manifests from `candidate` applications with known blocking
requirements. Refund Policy Notary is the first conformant direct declarative
rulebook application. Its record-mode runtime preserves the stable policy
intake, evaluates the exact normalized facts through Decide, and returns a
request-linked Decision Record with verification and historical replay.

Decision Memos are registered as a conformant hybrid application, not as a
deterministic recommendation app. Decision Memo Workflow is a conformant hybrid
application. The implemented split is:

- a trusted adapter normalizes packet facts such as question completeness,
  KPI/guardrail readiness, option count, evidence quality, owner, and run window
- a declarative readiness gate decides whether analysis may run, must defer, or
  is blocked
- the readiness gate produces the deterministic Decision Record
- any generated memo recommendation is emitted as a separate advisory artifact,
  not the binding Decide verdict
- degraded runtime paths do not select a winner or advance the packet to
  `decided`
- the named owner keeps final authorization for the written call and execution
  handoff

## Current Application Map

| Krafthaus application | Workflow surface | Decide role | Handoff |
| --- | --- | --- | --- |
| Decision Memos | Product, pricing, growth, or operating call | Conformant hybrid: deterministic readiness gate and record first; advisory memo recommendation remains separate | Written call, guardrails, rollback trigger, next action owned by the decision owner |
| Krafthaus Workflow Readiness | Proposed workflow app before binding | Conformant hybrid: trusted adapter facts feed a declarative Rulebook v1 binding verdict | BIND_READY, ROUTE_REVIEW, or BLOCKED before `bind_workflow_application` |
| Solana execution gate | DAO, agent, or treasury action before signing | Rulebook-backed verdict and packet lineage before value moves | APPROVE, DEFER, or BLOCK plus packet hash and optional Memo anchor |
| Policy MCP notaries | Refund, cancellation, return, or trial policy checks | Stable policy verdict/runtime endpoint | Agent-citable policy response and source path |
| Operator mini-tools | Vendor choice, build-vs-buy, rollout guardrail, or manual-review cost workflow | Decide-backed rule or record layer when the tool needs a verdict | Calculator output, review packet, or follow-up workflow |

Refund, Trial, Cancel, and Return use direct declarative Rulebook v1 evaluation
without trusted adapters. They preserve the stable REST and MCP application
contract while adding signed rulebook results. Refund additionally publishes a
conformant Application Manifest and opt-in Decision Record runtime; the same
generic bridge can graduate other direct-rulebook applications when warranted.

## Non-Goals

- Do not define Krafthaus only as Decision Memos.
- Do not present Krafthaus as the core Decision API.
- Do not claim that every workflow is deterministic merely because a UI exists.
- Do not let an LLM make loosely defined business judgments without a declared rulebook, adapter, evidence boundary, or human handoff.
- Do not persist degraded Decision Memo runs as completed decisions or treat input order as a recommendation.
- Do not run customer-supplied executable logic as a shortcut around the rulebook/adapter contract.
- Do not let `action_executes_before_decision_material_is_captured`; a
  Krafthaus app that cannot capture the Decide application-binding material
  before handoff is exploratory or advisory, not a deterministic production
  Decide-backed application.

## Product Implication

The smallest sellable unit is one consequential workflow. The durable architecture is a family of Krafthaus apps that install Decide into those workflows without forcing the customer to buy generic decision infrastructure first.

This is the delivery layer: Krafthaus finds the workflow surface, packages the interface, binds the rulebook or adapter, stores the Decision Record, and makes the next action usable.