How the demo uses poly

How the demo uses poly An architecture diagram generated by Archify. Refund demo · room, stand-in, replay · Architecture component Refund demo room, stand-in, replay Admission · certificate issuer · Architecture component Admission certificate issuer Certified build · .poly/build and certificate · Architecture component Certified build .poly/build and certificate poly-runtime · load and dispatch · Architecture component poly-runtime load and dispatch read artefacts, write certificate read certified artefacts · file admit the demo copy load and run the build Legend Backend Database

The short answer

  • • It admits a demo copy of the concierge through the ordinary admission, loads it on the ordinary runtime, and only supplies the room, the stand-in and the providers around it

Not shown here

  • • The checker, which has already decided before the demo starts
  • • Connected but out of scope: Workflow server, poly CLI, Check pipeline, Certificate format, Signed records, Feedback commands

What it guarantees

  • • An irreversible effect that may be attempted twice is not admitted unless it names how its target is kept from running it twice: poly-ref reports PL4003 with a witness (a delivery in which the target may execute twice) unless the effect is keyed (an idempotency header and a window that holds the retry horizon) or idempotent by nature in the pinned standard library. The runtime sets the key on every write in a capability the handler cannot bypass. What poly does not verify are the assumptions K17 (the target honours the key) and K18 (an effect declared idempotent by nature is), which a certificate names when an effect declares them