Rulings of 2026-10-04

Rulings of 2026-10-04

The operator’s answers to the eight open design questions in
research synthesis section 19, and to the Elysia question (section 11).
These are decisions, not proposals. The implementation plan follows them.

Elysia

Agreed: Elysia is not core. The operator’s earlier weight on Elysia should not shape the
transport contract. Elysia stays a candidate HTTP adapter once the generic contract exists.

Consequences for the proposal (synthesis Step 3)

• Section 15 “Server and API protocol” adapter: no transport is chosen as first. The core’s
  interface is an in-process function call; every transport is an optional adapter over it.
• Section 17 phase 1 “Enter”: every transport, the CLI included, obtains the caller’s scope
  through the actor-resolver adapter contract. Mesh core defines no flags, no tenant and no
  login; tenant belongs to the multitenancy extension. (Corrected 2026-10-04: an earlier line
  here made the CLI define actor/tenant/context, which pulled app concerns into core.)
• A new research document (durable engines, adapter-interface focus) feeds the jobs and
  workflows adapter contract.

Lead decisions (operator may overrule)

• Composed contracts module. Mesh generates one self-contained mx.contracts module from
  core plus the enabled extensions, so extensions add tags without any MX change. Follows
  ruling 5 (contributions only through declared points: a closed resource.children must
  accept children an extension contributes). Stated to the MX lead in
  Mesh’s answers to MX on mx.contracts, 2026-10-04; no decision-142 addendum needed.

Implementation-plan rulings (2026-10-04)

Review note (2026-10-04, later)

The operator asked for a review of every decision above. Until that review is closed, read the
tables with these corrections:

• “Plan ruling Q4” was never an operator ruling. The operator said only that app-specific
  concerns must not enter Mesh’s architecture. The actor-resolver adapter, “scope = actor and
  context” and “tenant belongs to the multitenancy extension” were the lead’s inventions.
• “Plan ruling Q3” records the operator’s position (“the more we can rely on well-established
  tools the better”); choosing Drizzle and drizzle-kit specifically was the lead’s application
  of it.
• Q2, Q5–Q7, Q9–Q12 and Q14 were accepted by the lead in one line without analysis. They are
  provisional.
• “CLI only” in Q1/Q13 follows the misreading of ruling 8 and is void; “M0–M14, SQLite and
  Postgres, HTTP after” is what the operator chose.

Rulings after the decision review (2026-10-04, operator)

Implementation note, 2026-10-04: the first live-spec set grew to seven new pages. Calling actions, Configuration and Command-line tool supplement the four named in the ruling to make their examples complete. The ruling above is preserved verbatim.

Lead decisions of the architecture-docs brief (2026-10-04)

Decided by the lead; the operator may overrule. Quoted from the brief the lead gave for the roadmap and the decision records.

• Scope is a plain argument. The caller passes { actor, context } on every action call, as Ash’s actor: option. Drop the actor-resolver contract, the actor-dev package, the action registry and the transport contract from v1. N4 is moot.
• Tenant: open. In Ash, tenancy is in core. Nobody ruled where it lives in Mesh and multitenancy is not scheduled. Write it as a Proposed ADR with options; drop the “scope contribution point” from the extension host.
• Walking skeleton ends in a function call: a test and a ~20-line script in examples/blog call the generated handlers against SQLite. No transport-cli, no exit codes, no --stdin, no worker command.
• public and default-deny before policies (old D10, D6): no transport exists in v1, so public has nothing to filter yet, and the authorization: "none" flag is wiring for nothing. Drop both from M2; deny-by-default arrives with the policies extension. Record what public will mean as a Proposed ADR.
• Outbox relay and rule R3 are deferred with the workflow milestones. durable engines stays the design input for a future workflow/job adapter contract; a small spike “DBOS worker on Bun” precedes any engine choice. No engine is a clear winner (DBOS best fit on paper for workflows, pg-boss for plain jobs on Postgres).
• Validations are classified like changes now that an in-memory evaluator exists: a translatable validation folds into the atomic statement; rework the atomic-by-default rule and the publish example accordingly.
• N1 Zod behind Standard Schema: accepted. N3 OpenTelemetry API direct: accepted. N2 (in-memory data adapter vs SQLite :memory:): reconsider now that the in-memory evaluator exists; decide, with reasons, in an ADR.
• The vocabulary on main is provisional. The 26 tag contracts were copied from an MX test fixture; several rules were inferred by the dev or ruled by the lead during code review (PR #1 report, “Inferred by me”; rounds 1–4). Write a Proposed ADR plus a “Vocabulary design” page listing every open vocabulary question (inferred rules, review rulings, and the new tags each v1 milestone adds) so the operator can rule on them in one pass before M1 builds a model on them.

Later the same day

Further decisions by the lead on 2026-10-04, given while the roadmap and the decision records were written. The operator may overrule each.

• public attributes. public is recorded in the model, as Ash records public?, and nothing in v1 reads it. It is not a not-implemented build error.
• Atomic updates in v1. “In v1 a validation or change that reads the stored record makes the action non-atomic, and the action must say require_atomic? false, as in Ash. Folding record-reading validations into the statement, with the failure protocol you designed, becomes a Proposed ADR for after v1.” This replaces the brief’s “a translatable validation folds into the atomic statement”. Translatable validations that need no stored record still run before the statement on either path; the in-memory evaluator runs validations on the non-atomic path.
• Write policies on atomic actions. A record-reading write policy on an atomic action folds into the statement as a filter; a forbidden row reports not found. Accepted first as Ash’s behaviour; the research shows Ash compiles the check as an expression that raises and reports forbidden, so the lead kept not-found as a deliberate deviation and a working assumption, and made the point a Proposed record for the operator to rule.
• has-one. An implicit unique index for v1, recorded as a Proposed deviation from Ash, with the alternative “a build error unless the foreign key is declared unique” once identities exist.
• Spelling of names. The MX maintainers measured on MX main (7a404916) that _ is accepted in tag and attribute names and that a trailing ? in an attribute name is not accepted and never will be (Marko’s syntax rule: letters, digits and ._:-). “Mesh names are Ash’s names in kebab-case with ? dropped: belongs_to → belongs-to, allow_nil? → allow-nil, require_atomic? → require-atomic. The mapping is mechanical and one-to-one, it matches what is on main, and it avoids renaming twice.”
• Adapter-contributed commands. mesh db push and mesh migrate are contributed by the SQL adapters. The rule that MX is imported only by packages that declare tag contracts is checked by verify from M1.
• Expression semantics. The record stays Proposed and must be ruled before M4.
• Deciders on public pages are named by role only: operator, lead, roadmap author.
• In-depth pages for policies and for relationships, calculations and aggregates are written in the milestones that build them, not before: the rule is to document what cannot be understood from one code file, and that code does not exist yet.
• Published history. The rulings log is published verbatim, corrections included, with a banner saying the decision records are authoritative. Plan revision 2 is published as a superseded page, excluded from search and from llms.txt.