Choosing a recipe

Start from the outcome you need, not from the technology. Almost every application maps onto a stock model; writing code should be the last resort, not the first move.

Start from the outcome

I want to…	Start with	Coding required?
See three members finalize the same events	Your first app ledger	No
Keep an append-only log of opaque application records	`audit-log` recipe (`ordered-log`)	No
Maintain a provable, owner-controlled registry	`owned-registry` recipe (`kv-registry`)	No
Maintain several proof-oriented collections, optionally with value validation	`authenticated-map` recipe (guide)	Configuration; a plugin only for custom rules
Collect member approvals and optionally trigger an action	`approval-workflow` recipe (`approvals`)	Configuration plus typed commands
Track balances with a non-negative account ledger	`balances`	Configuration plus typed commands
Maintain a document-hash trail per product or case	`document-trail` recipe (`doc-trail`)	Configuration plus typed commands
Approve payload hashes using application-defined roles	`role-approval` recipe (`role-approvals`)	Configuration plus actor integration
Require manufacturers, auditors, and regulators to sign by role	Domain-role approvals	No, for the stock scenario
Publish immutable evidence to object storage or IPFS and notify Kafka	`evidence-ledger` recipe (Evidence)	No for the demo; connector plugins in deployments
Call an ERP or API after a finalized decision	Webhook effects	Configuration; emission is stock or plugin logic
Query and prove historical Cardano parameters, stake, and governance	Cardano History	Plugin configuration and CLI
Run a UTxO-style ledger	eUTxO ledger	Experimental; Cardano builder integration
Connect existing machines: when one changes, check, then update another in the same atomic step	`declarative-composite` recipe (declarative bindings)	No: YAML compiled to committed IR
Implement business rules Yano does not ship	The plugin framework	A small Java plugin

If you are unsure, run tutorials 1, 2, 4, and 5 in that order. They show the progression from a replicated log to proofs, external actions, and business-role authorization. Or answer a few questions:

Which recipe should I start from?Decision aid

What you're seeing: answer for your outcome. Each result is a recipe in this release’s catalog; ./yano.sh appchain recipes lists the same set.

What should the ledger do?

Keep an append-only log of opaque records
Replicated audit log
One opaque record is threshold-finalized in the shared application order.
Recipe
audit-log
Availability
BUNDLED · stable
Capabilities
state:ordered-log, sequencer:fixed
Your first app ledger → Recipe catalog →
Keep keyed records, documents or collections with proofs
What shape are the records?
- One value per key, owned by its first writer
  Owned registry
  The first writer owns a named value that is readable with a committed state proof.
  Recipe
  owned-registry
  Availability
  BUNDLED · stable
  Capabilities
  state:kv-registry, sequencer:fixed
  kv-registry → Recipe catalog →
- A trail of document hashes per product, case or shipment
  Document trail
  A document hash advances an entity trail; its count and head have a committed state proof.
  Recipe
  document-trail
  Availability
  BUNDLED · preview
  Capabilities
  state:doc-trail, sequencer:fixed
  doc-trail → Recipe catalog →
- Several collections, with optional schema validation and policies
  Authenticated map
  A value accepted under a genesis-declared collection schema is committed and available with a state proof.
  Recipe
  authenticated-map
  Availability
  BUNDLED · preview
  Capabilities
  state:authenticated-map, sequencer:fixed
  authenticated-map → Recipe catalog →
Approve things before they take effect
Who approves?
- The member nodes themselves
  Threshold approval workflow
  Distinct validator-member decisions produce a provable terminal approval or rejection.
  Recipe
  approval-workflow
  Availability
  BUNDLED · stable
  Capabilities
  state:approval-workflow, sequencer:fixed
  approvals → Recipe catalog →
- People or organizations, by business role
  Governed role approvals
  A governed role policy accepts valid actor decisions and rejects an ineligible actor decision.
  Recipe
  role-approval
  Availability
  BUNDLED · preview
  Capabilities
  state:role-approvals, sequencer:fixed
  Domain-role approvals → Recipe catalog →
Connect existing machines: when X happens, check, then do Y
Declarative event workflow
A source command and its event-derived commands commit atomically with an auditable receipt.
Recipe
declarative-composite
Availability
BUNDLED · preview
Capabilities
state:declarative-composite, sequencer:fixed
Bindings learning path → Recipe catalog →
Publish evidence to storage and notify other systems
Role-aware evidence ledger
A role-authorized evidence record and its release decision are committed and queryable.
Recipe
evidence-ledger
Availability
BUNDLED · preview
Capabilities
state:role-evidence, sequencer:fixed
Evidence → Recipe catalog →
Run a UTxO-style ledger
Which kind of experiment?
These recipes are experimental. Use test networks and no real funds.
- A test ledger funded at genesis
  Scalus-backed EUTxO ledger
  A signed key-controlled or bounded Plutus V3 transaction consumes virtual EUTxOs and creates MPF-proven outputs and receipts.
  Recipe
  eutxo-ledger
  Availability
  FIRST_PARTY_OPTIONAL · experimental
  Capabilities
  profile:eutxo-plutus-v3, funding:eutxo-genesis, sequencer:fixed
  eUTxO ledger → Recipe catalog →
- Deposits from and withdrawals to Cardano
  Federated Cardano EUTxO bridge
  Accepted stable deposits create mirrored EUTxOs; signed L2 spends create irrevocable claims that settle only through the configured signer path or a current accepted MPF root with single-use nullification.
  Recipe
  eutxo-cardano-bridge
  Availability
  EXPERIMENTAL · experimental
  Capabilities
  profile:eutxo-plutus-v3, bridge:cardano-federated, sequencer:fixed
  eUTxO ledger → Recipe catalog →
Something no stock machine models
Custom state-machine project
The operator-defined state-machine contract is loaded from a reviewed pinned plugin bundle.
Recipe
custom-plugin
Availability
REFERENCE · experimental
Capabilities
state:custom-plugin, sequencer:fixed
The extension ladder → Recipe catalog →

Then pick the extension level

Does a stock machine or recipe already model the outcome?
  ├─ yes → configuration only
  └─ no
      Do existing machines have the commands and events you need?
        ├─ yes → declarative bindings, or a small Java composite
        │        when bindings cannot express the coordination
        └─ no  → a custom state-machine plugin

Read the extension ladder before deciding you need Java. Most teams that think they need a custom state machine actually need bindings or a composite, and many that think they need a composite need only configuration.

Questions that change the answer

Who authorizes an action — a node or a person? If the approver is a validator member, approvals is enough. If the approver is a business actor at an organization (an auditor, a regulator, a QA manager) whose key is not a node key, you need role-approvals or the role-evidence profile. Those separate the identity that transports a command from the identity that authorizes its business meaning.

Do you need to prove absence, or only presence? Presence is straightforward. Absence requires dataset completeness — a marker, a paired subject, or an authenticated snapshot descriptor. Design for it up front; see State and proofs.

Does an external system have to act on a decision? Then you need effects, and you must decide the finality gate (app-final vs l1-anchored), the expiry, and who may attest to results.

Do several capabilities need one atomic state root? That is exactly what a composite profile is for, whether declarative bindings or a Java composite build it. If they can live on separate chains, use separate chains — a node can host several.

Is the data volume large and immutable per period? Look at authenticated snapshots rather than growing primary authenticated state indefinitely.

Will the semantics change after launch? Choose governed composite profiles from the start. Retrofitting governance onto a fixed-profile chain means a new chain.

What “no code” honestly means

No-code means the required state machine, composite, connector, and launcher already ship with Yano X. A real application still:

sends typed commands;
owns its UI, identity onboarding, key custody, and business data; and
decides its retention, authorization, and operational policy.

Configuration cannot invent arbitrary consensus transitions. New combinations of existing components use declarative bindings, or a small Java composite plugin when bindings cannot express them; genuinely new domain logic uses a custom state-machine plugin.

Before you commit

./yano.sh appchain recipes                 # what this build offers
./yano.sh appchain capabilities            # support tier, scope, selection
./yano.sh appchain capabilities --format json

The catalog is release-pinned, so the binary you built is the authority for the version you will run. The recipe catalog and capability catalog here are generated from the same files.