- name
- modelling
- description
- Maps the operational account to a Petrinaut SDCPN, and revises, checks and delivers it. Use before any net mutation, net revision, construction-led analysis, experiment proposal or net delivery.
# Modelling the operation
Consume the attributed operational account without manufacturing source facts. Construction and elicitation recur together: build from available meaning, expose representation choices, and revise as the account changes.
## Construct
Read `references/mapping.md` and `references/checks.md` before first construction. Make every net change through the mounted Petrinaut tools, as the `petrinaut` skill describes. If those tools are absent, limit the result to the recoverable account and construction reflections. Say construction changed only after successful tool evidence.
Start when an activity and what it changes are available, normally in the first exchanges. Sketch the breadth already described rather than only the current detailed thread. Missing facts use visible stand-ins; they do not postpone construction. Conflicting accounts remain represented as unresolved rather than silently selected. An explicit request for sensible defaults authorizes purpose-bounded agent choices, still labelled as such.
After meaning-bearing input, extend or reshape the net to carry it, or make no mutation when it already does. Treat the net as a draft: revise types and elements and remove superseded structure when new meaning no longer fits. Preserve unrelated structure at the level actually inspected.
Every accepted step of net changes gets a reflection in the exchange's commit, made after its net steps, anchored to the net elements the step created or changed and to the claims and entities they carry: what those elements represent, and any stand-in, inference, default, approximation, revision or target loss, with what it affects. Where a result will rest on one of these, the same commit records an obligation naming the run that would test it; a reflection that cites a run's observed result discharges the obligations that run met. Reflections are the Ledger's only link to the net; they are neither operational facts nor a mandatory queue of questions.
## Check correspondence
Apply `references/checks.md` to every changed fragment and before delivery. Compare the inspected net with the account: supported meaning is present, stand-ins are visible, contextual quantities remain contextual, consumed/reserved/read distinctions and resource release survive, and changed rules reshaped incompatible structure.
Keep evidence levels separate:
1. tool-schema acceptance of exact calls and inspected structure;
2. agent-reviewed structural correspondence with the account; and
3. observed behaviour from a named simulation or stronger analysis with its scenario and scope.
A lower level never implies a higher one. A compilation diagnostic does not prove scenario or metric code, reachability, conservation, semantic fidelity or behaviour.
## Prepare experiments
When the USER states a decision the model should answer, asks to run an experiment, or changes its measure, direction, tunable quantity/range or regime, read `references/experiment-configuration.md`. Early purpose, levers and protected conditions are operational meaning; they are not experiment readiness.
Readiness requires both the stated decision configuration and current executable counterparts described in that reference. Construct missing net prerequisites; ask only for missing source facts. Parameters and metrics alone never trigger a proposal. Hard restrictions remain distinct from soft objectives, and unsupported enforcement is disclosed rather than encoded as a penalty.
Draft at most once per meaningful configuration through the mounted draft tool, following the `petrinaut` skill's experiment reference. A draft is for review: it is not saved with the document, run, approved, completed or applied. The USER controls Run and any later use of results.
## Deliver or continue
Use the current Ledger and inspect the current net before delivery. State the intended purpose; whether the account is sufficient or partial; whether construction was absent, blocked, partial or tool-schema accepted; whether structural review occurred; whether behaviour is untested or observed under a named analysis; agent-authored assumptions and simplifications; unresolved conflicts and gaps; target/tooling losses; and the smallest evidence that would change the result.
Once the USER has agreed the structure, you may offer one or two domain-specific place visualisations, such as a queue as a stacked bar or machines as a row of state-coloured rectangles.
An explicit stop opens no new topic. Deliver useful partial work and any already-checked fragment. In an unbound conversation, explain the construction that the account supports and the missing capability or fact, without claiming a mutation, check or draft occurred.
## Resources
Read resources directly from this skill's advertised packaged-resource paths. Relative names here are labels, not includes. Do not follow Markdown references recursively.
Auf GitHub ansehen