The Workshop is where you build one application. It is a single screen with nine lenses over the same live model, and Paroksh docked beside them, bound to the project you are in.
Nothing here is a separate artifact you have to keep in step. Every lens is a different question asked of one model, so a change made in the conversation shows up in all of them at once.
The nine lenses
| Lens | What it answers |
|---|---|
| App | Your app, running against this session's own backend. |
| Domain | The things your app keeps track of, and the rules about them. |
| Application | What it does — commands, queries, use cases, reactions. |
| Systems | The capabilities it is made of, and what they depend on. |
| API | Every endpoint and event it declares. |
| Flows | Business processes and journeys — how someone reaches a goal. |
| Coverage | What the model promises, against what is actually built. |
| Assurance | What your model promises, and how much of it is specified, honest and verified. |
| Source | Your model, the backend it compiles into, and your web app. |
App comes first, deliberately. Eight of these are views of the model; that one is the result. Putting the running application at the front keeps the thing you are actually building in front of you, rather than the description of it.
Reading them in a useful order
The lenses are not a workflow and you can open them in any order, but two paths pay off early:
When something is missing. Flows shows the processes you have described; Coverage shows which of the capabilities those flows require nothing yet provides. That gap is your backlog, and it is derived rather than maintained — it empties as you build, without anybody ticking items off.
When something is claimed. Assurance is the one that argues back. Your model makes falsifiable statements about runtime behaviour — each guard, each constraint, each endpoint contract — and this lens reports how many of them are actually verified, and flags any capability claiming to be readier than its evidence supports. See Capabilities for what makes a maturity claim checkable.
Paroksh in the Workshop
The dock here is bound to this project. Same agent, same identity, same rules as everywhere else in Cisely — the difference is what is in reach: the application's own model, rather than the whole business context.
That binding is the useful part. You can point at what is on screen and ask about it, and the agent already knows which project you mean.
The app is really running
The App lens is not a mockup or a static preview. It is your application, served by a backend generated from the model as it stands, so what you click is what the model actually does.
Which means the fastest way to find out whether a rule says what you meant is usually to go and try it, rather than to read the declaration again.
Next: Introduction to Vishwakarma — the language the model is written in, and the one every lens above is a view of.