fsl-business

FSL Business Layer

Use this skill to turn business process material into a business Name { ... } FSL file. Keep the output at the business/consulting level: process stages, business transitions, policies, KPIs, goals, and control preservation evidence.

Before writing syntax, read ../fsl/SKILL.md, then use its reference index to load only the needed language and verifier detail. When working inside this repository, read examples/consulting/ for As-Is/To-Be work, examples/pm/cancel_flow.fsl for a PM-friendly business flow, and examples/e2e/1_business.fsl when this business layer will be chained downstream.

Boundary

Produce business-layer artifacts only:

• A business spec with actor, entity, process, transition, optional control, policy, kpi, and goal, plus a top-level verify { instances Entity = N } bound
• Optional standalone governance catalog when the same controls must be traced across multiple business specs
• Verification commands/results, usually fslc verify ... --engine induction
• Optional As-Is/To-Be control preservation using fslc refine and a mapping file

Do not write system requirements, acceptance criteria, UI states, service/API shape, data models, queues, outboxes, retry algorithms, implementation adapters, or design refinement maps from business material. If the source asks for those, route the work to fsl-requirements or fsl-design after the business layer is agreed.

Workflow

1. Extract a business formalization memo in chat:
   • actors and external roles
   • business entity names and finite verify { instances ... } modeling sizes
   • process stages and allowed business transitions
   • policies/controls with IDs and verbatim source text
   • KPIs/goals and what counts as completion (kpi name = count Entity in Stage)
   • open questions about rule priority, exceptions, ownership, or timing
2. Ask for confirmation before encoding any interpretation that changes behavior. Representation-only modeling choices may be labeled and carried as comments.
3. Write the business spec. Prefer readable stage syntax:
   • entity Claim with verify { instances Claim = 3 }
   • kpi paid_claims = count Claim in Paid
   • control CTRL-1 "..." owner Finance severity high applies_to Claim
   • policy POL-1 "..." satisfies CTRL-1 every Case in Source must eventually be Target
   • policy POL-2 "..." satisfies CTRL-1 every Case reaching Completed must have passed through AwaitingApproval — the no-bypass form; desugars to an invisible history flag plus a kernel invariant, without descending to requirements
   • goal G "..." some Case can reach Target
   • goal G "..." all Case can be Target or OtherTarget
4. Run fslc check, then fslc verify --engine induction. A pure stage-graph business spec needs no flag for intentional stops: terminal { } is derived automatically from each process's sink stages (stages with no outgoing transition), so a spec that ends cleanly at those stages verifies with no flag. --deadlock ignore is not the tool for intended stops — it silences all deadlock detection, including unintended ones.
5. If comparing As-Is and To-Be, keep them in separate files. Write an explicit mapping that states the business interpretation, then run fslc refine tobe.fsl asis.fsl mapping.fsl.
6. Report results in business language: which policy/control/KPI broke, the shortest reproduction trace, and which interpretation remains a human judgment.