Model portable external occurrence responsibility

[woksin]

Portable problem

A model needs to state that a business occurrence comes from another modeled application/module or external capability without exposing observer, daemon, sequence, subscription-offset, or transport terminology.

Scope

• Named external occurrence/fact source as a portable responsibility boundary.
• Exact source application/module/capability identity when part of the modeled system.
• Translation/capture into local domain facts.
• Causation/correlation and scope propagation.
• Capability admission and deterministic specifications.

Non-goals

• Observer sequence names.
• Subscription offsets/checkpoints.
• Daemon/shard hosting.
• Broker topics or endpoints.
• Runtime topology inferred from source configuration.

Acceptance criteria

• External responsibility is understandable without framework terminology.
• Source occurrence and translated local fact remain distinct.
• Cross-application identity and correlation are typed.
• Translation can be executed and specified portably.
• Realization profiles supply transport/subscription details separately.
• Missing or ambiguous external ownership fails closed.
• Studio diagram and AI semantic snapshot preserve the boundary.

This rewrites the former observer/sequence framing into portable model semantics.

[einari]

Swept as part of a pass over the open set. Still valid at origin/main 7709d43, and the reaction rework (#104) changed one half of it.

State of the two halves:

• sequence on a projection exists and is now documented. ProjectionSyntax.Sequence, parsed at ProjectionParser.cs:82, and the PDL grammar carries it - Documentation/screenplay/projections/grammar.md:38, "sequence", Ident, NL. The "undocumented" part of this issue is stale.
• A reaction still has no equivalent. ReactionTriggerSyntax carries a source, data, produces, invokes, a file and code - nothing about which sequence or which store the events come from. So a cross-service observer still reads as though it observed the local log.

What #104 changed about the question

A reaction no longer assumes its trigger is a domain event at all - when <Name> may name an event, a declared trigger, or a registered one, and the whole point of that design is that "a reaction should not have to know whether what set it off came from the event store, a clock, an integration or a custom runtime provider".

That is worth taking seriously here, because it argues against putting a store on the reaction. Under that model, "events from the Ada application's store" is not a property of the reaction - it is a property of what the trigger is. Which suggests the cleanest answer is not a new clause on a reaction but a trigger that says where its occurrences come from, leaving the reaction unchanged.

Three ways to express it, in the order I would consider them

1. Say it on the trigger, not the reaction. A trigger declaration already says "this name exists, and here is what an occurrence hands you" while deliberately saying nothing about what makes one occur. Extending it with an optional origin - which application's stream, which sequence - states the subscription exactly once, where the name lives, and every reaction naming it inherits it. It also composes with import: import Lobby.Invitations.InvitationToJoinAdaAccepted already says the event type comes from outside, and this would say the stream does.
2. sequence on a reaction trigger, for parity with a projection. Narrower - it answers the outbox/inbox half ([EventSequence] / [EventLog]) without answering the cross-application half. Cheap, obviously consistent, and it is the half that is missing on one construct and present on the other for no stated reason.
3. A first-class notion of another application's store. Biggest, and the one to avoid until something forces it: it makes a document depend on how another application is deployed, which is the sort of thing authentication deliberately keeps out.

I would do 2 for parity and design 1 properly, rather than bolting a store onto a reaction.

The thing to decide either way

Is the sequence name resolved or opaque? The language has precedent both ways: a policy name must resolve, a scoped to scope and a registered trigger name are opaque by design. A sequence is the event log, an outbox or an inbox - a small, known set for Chronicle, but not one the language should hard-code if Stage may serve other runtimes. Opaque with a documented conventional set (log, outbox, inbox) is the answer that ages best, and it is what a projection's sequence does today, so parity comes free.

One note on direction: the issue says the missing thing is "which application's event stream it observes". Worth stating that the inverse - which application's stream we publish to - is the outbox side of the same clause, and both fall out of whichever of the three shapes is chosen.

[cratis-direct]

Thanks for opening this - it has been received and will be looked at.

---

Posted by Stagehand (AI) - an autonomous agent, not a person. Review accordingly.

[woksin]

Work has started locally as part of the coordinated end-to-end Screenplay/Stage/Studio/CLI delivery effort tracked in #174. @woksin is coordinating implementation in dependency order with repository-specific AI corpus instructions and specifications. Existing work/PRs will be reconciled rather than duplicated. This is a kickoff, not a completion claim; focused progress, verification evidence and blockers will follow here.

[woksin]

Open decisions blocking this issue, from a triage against the source after v4.20.0. Each needs a product or architecture choice before implementation; the options and their consequences:

1. Where origin lives — optional origin on trigger (stated once, inherited by every reaction) vs a clause on the reaction trigger (parity with projection sequence, but recouples reactions to transport) vs a first-class "other application's store" (makes a document depend on deployment, contradicts the non-goals). triggers.md:35-45 — a trigger declares name and shape and nothing about what makes it occur — favours the first.
2. Resolved or opaque source name — resolved fails closed per criterion 6 but needs cross-application knowledge the compiler lacks; opaque is cheap and cannot fail closed.
3. Is translation a construct or just a reaction that produces? A distinct construct satisfies criterion 2 explicitly; reuse keeps the language small but leaves source occurrence and local fact indistinguishable in the tree.

[woksin]

Problem (evidence)

The external-occurrence-to-local-fact translation and deterministic specification requested here still lack an executable semantic contract. At v4.24.0, SemanticSliceKind admits only StateChange and StateView (Source/DotNET/Screenplay/Semantics/SemanticModel.cs:9-27); SemanticModelBinder.SliceMembers.cs:25-38 reports reactions and captures as unsupported. At origin/main, the kinds remain unchanged (SemanticModel.cs:9-27), and SemanticModelBinder.SliceMembers.cs:77-99 still reports both as unsupported, despite inventorying reaction attachments. SemanticSpecificationRunner.cs:96-111 on main explicitly does not execute reactions (:81-96 at v4.24.0). The body-attachment inventory alone is not portable occurrence/effect behavior (#139).

Why it matters

Stage cannot admit Automation/Translation slices from the ESM without inventing trigger identity, source-to-local-fact mapping or effect semantics; it correctly fails closed (Cratis/Stage#79).

Proposed change

For this issue's external boundary, define a typed source occurrence, distinct resulting local fact, identity/correlation propagation and normalized execution outcome; admit it in ESM and add deterministic reference/specification vectors. Leave delivery topology to a realization profile. Coordinate view-driven/local automation and due-time triggers with #69 rather than broadening #73 to all reactions; #139 supplies opaque body contracts, not their effects.

Scenario

A named occurrence from another modeled application is translated into a local fact with its source identity and correlation intact. A specification asserts the fact and context; absent/ambiguous source ownership returns Unsupported rather than dropping the effect. Stage can render the admitted translation or name the missing capability.

[woksin]

Ruled and recorded as accepted decision 0009 (PR #255): an external event's origin is an opaque store name on the event declaration or its import (mirroring Chronicle's [EventStore]), and translating an external event into a local fact is a Translate slice. Origin on the reaction trigger and first-class "other application" declarations are not adopted. Ready to implement.

[woksin]

Correction to my earlier comment, from an independent review against decision 0009 (v4.30.0 and main):

• Out of scope in 0009. My comment asked for typed cross-application identity/correlation and for "absent/ambiguous source ownership returns Unsupported". Decision 0009 puts typed correlation out of scope, and says an opaque name cannot fail closed: that check belongs to the realization. The same two items are also in this issue's acceptance criteria, so they should be rewritten to match 0009 or moved to a follow-up.
• Phasing. 0009's "Done when" covers syntax, printer and docs only. ESM admission goes through decision 0004: a new ESM version, golden and corpus vectors, reference execution or typed Unsupported, and consumer tracking issues. This work splits into (a) syntax and docs, and (b) a new ESM version with a Translation kind. Automation and Translation slice types are not admitted by the Cratis ESM planner Stage#79 is unblocked only by (b).
• Naming. Translate already names the slice that hosts a capture (slices.md, captures.md). The implementation should state how the binder tells a capture apart from a translation that turns an external event into a local fact in the same slice kind.