Review: The Ash ecosystem packages

Review: notes/research/04-ash-ecosystem-packages.md (ref ash-ecosystem)

Review of: The Ash ecosystem packages.

VERDICT: ACCEPT

(Final verdict after round 3, 2026-10-01: ACCEPT. The document can be used as is, provided the
reader applies the list under ### Residual errors (for readers) in ## Round 3 final check at the
end. Earlier verdicts: round 1 ACCEPT-WITH-FIXES, round 2 ACCEPT-WITH-FIXES.)

Reviewer: independent fact-check, 2026-10-01. Read-only; the document was not edited.
Ground truth: clones under scratch/ash-src/ (paths below are relative to it unless absolute), hex.pm API
fetched 2026-10-01, GitHub API, Elixir Forum (forum.elixirforum.com/t/<id>.json).

Bottom line. The hex.pm data is excellent: all 20 ranked rows match the API exactly. Most
technical claims about Reactor, AshPaperTrail, AshEvents and ash_typescript hold up against the source.
The problems: one code example was changed by hand and is presented as copied (rule 5); two “gaps”
are false (Ash.Test “nearly empty”; “nothing persists a workflow” / “no way to resume a Reactor”);
several facts about community packages are wrong (ash_event_log “pre-dating”, ash_commanded “~10
releases a year”, ash_flow, ariadne_flow, ash_onetime); and the AshEvents “not event sourcing” verdict
leaves out that the Ash maintainers publicly argue the opposite. About 25% of citations point at the
wrong line. Everything here can be fixed without new research beyond the URLs given.

---

1. Error table

Severity: high = wrong fact a design decision could rest on, or an evidence-rule violation;
medium = wrong or misleading but local; low = imprecision.

---

2. hex.pm comparison (fetched 2026-10-01, https://hex.pm/api/packages/<name>)

Every ranked row matches the API exactly on version, last release date, all-time downloads and
90-day downloads. Repo URL is the meta.links GitHub/Source entry. All 20 are alive (released in the
last 12 months, none retired at the latest version).

The ranked table has no repository column. The brief did not require one, but the URLs above should
go into §5 or §9, because two “core” packages live outside ash-project on GitHub
(ash_authentication, ash_authentication_phoenix under team-alembic).

Honorable-mention spot checks: ash_authentication_phoenix, ash_authentication_oauth2_server,
ash_money, ash_sqlite, ash_csv, ash_slug, splode, ash_geo, ash_diagram,
opentelemetry_ash, ash_pagify, ash_scylla, ash_arcadic, ash_jido, ash_workflow and
ash_event_log match. Mismatches (ash_translation, ash_uuid, reactor_*, feistel/onetime,
hephaestus) are listed in §1.

---

3. Citation sample

70 local-path citations were opened and judged, plus the 20 hex URLs of the ranked table.

Does not support: ash/documentation/topics/advanced/reactor.md:66-90 (code altered);
ash/lib/ash/test.ex:5-25 (“one helper”); ash_commanded/README.md:8-11 (quote is the hex
description, and the lines are build commands).

Wrong line, claim true (fix the numbers):

• ash_events/README.md: 145-160→157-172; 163-171→174-182; 172-181→197-203; 180-193→184-195; 181-186→205-210; 191-260→212-265.
• ash_commanded/README.md: 20-27→34-39; 29-52→41-60; 54-61→62-68.
• reactor/lib/reactor/middleware.ex: 70-80→63-121.
• concurrency_key is in reactor/lib/reactor.ex:110, not the glossary.
• ash_paper_trail/.../getting-started-with-ash-paper-trail.md: 325-327→372.
• ash/documentation/how-to/test-resources.livemd: 44-50→25-28.
• ash_ai/README.md: 57→72; 66→82.
• ash_typescript/README.md: 93→87.
• ash_typescript/lib/ash_typescript/rpc.ex: 315-321→324-325.
• ash/usage-rules.md: 7-9→11.

Supports (sample): reactor 01-getting-started:95, 02-error-handling:132-160 and :610,
03-async-workflows:55-66, glossary entries (Three-Tier, Cycle Detection, Ecosystem Extensions,
Synchronous Execution), architecture “Main Executor”, cheatsheet :155/:384, step.ex:207,229,
testing-strategies (Mimic, async?: false); ash reactor.md:9, :36-60, :145-180, :184-215; paper trail
guide 29-46, 200-243, 246-260, 262-282, 94-116, 118-160; ash_events README 54-72, 110-130, 317-331,
333-349; ash testing.md:10-13; ets.ex:12-25; generator.ex:8-40; test-resources.livemd 52-56, 196-262,
214-215; ash.ex:1812-1826; seed.ex:5-11; smokestack README; ash_commanded README 88-140;
ash_money README 17-23; ash_ai README 243-250, 318-330; ash_ai usage-rules 29-49; ash_typescript
README 17-19, 29-33, 38-48, 67-99; rpc.ex 282, 225-246, 150-220; first-rpc-action 29-75; usage_rules
README 12-19, 57-90; generators.md 16-40; reactor getting-started :47; ash_double_entry README 24-36;
AuditLogResource (ash_authentication/documentation/tutorials/audit-log.md:57); AshRateLimiter in
otp.md:46; ash_rate_limiter README Hammer config; usage-rules* inventory (exactly the 15 listed
exist under scratch/ash-src, maxdepth 2); ash/usage-rules/ has 14 files.

---

4. Acceptance criteria

Format rules: the Summary has 10 bullets (≤ 12, OK). Facts and analysis are kept apart (OK), but
“Precise statement of what AshEvents is” and gap #8 are analysis inside fact sections. Word count is
9,180 against a 3,000-6,000 target; the overrun is declared in the report and is acceptable.

---

5. Check 7: ranking sanity / missed packages

Sources: https://hex.pm/api/packages?search=ash&sort=recent_downloads (pages 1-3) and the
individual package endpoints.

Missed and relevant to domain modeling or testing (add to honorable mentions at minimum):

Included but questionable under the stated rule (“domain first”): igniter (#15) and spark
(#16) are tooling/infrastructure ranked above domain packages (ash_cloak, ash_double_entry). By
the document’s own rule they belong at the bottom or in honorable mentions. ash_admin (#18) and
ash_rate_limiter (#19) are less domain-relevant than ash_money, which #20 depends on. Nothing
included is dead or irrelevant, so no row needs to be removed for correctness. This is a consistency
fix.

---

6. Check 9: the gaps section

Gap claims with no real evidence or contradicted:

1. Gap #1, “no shared, versioned library of reusable generators”: ash_scenario exists (low
   adoption). Restate as “no mature shared library”.
2. Gap #2, “no first-class domain operation that is durable, retryable and observable”: no source;
   opinion. Move to Implications.
3. Gap #3, “nothing persists a workflow’s progress”: contradicted (Reactor halt/resume, ash_workflow,
   AshOban + AshStateMachine; see §1).
4. Gap #5, “no documented way to resume a Reactor”: contradicted (reactor-cheatsheet.cheatmd:53-55).
   “No way to express a Reactor step as an Oban job” is also unsourced; the documented pattern is
   the reverse (Reactor inside an Oban job, forum 59508 and 65945).
5. Gap #6, “AshArchival needs base_filter_sql”: wrong (optional). The PaperTrail and AshMoney parts
   are supported.
6. Gap #7, “Ash.Test nearly empty”: wrong.
7. Gap #8, “GraphQL complex by reputation / JSON:API stalling”: self-declared inference with no
   evidence. The download comparison runs opposite to the heading (JSON:API has 2.6× GraphQL’s
   90-day downloads, so it is not “stalling”). Delete or source it.
8. Gap #4, “afterthought”: loaded wording; the facts (third-party, 0.2.0, 880 downloads) are right.

Documented gaps to add (with evidence):

1. No built-in way to hydrate a historical version back into a resource struct (AshPaperTrail).
   Zach Daniel: “There is nothing built in for that, no”, and he suggests a hand-written calculation
   over the :snapshot mode. https://elixirforum.com/t/are-there-any-best-practices-for-referencing-versioned-resources/75012 (2026-04-14/15).
2. AshPaperTrail does not support bulk actions or non-resource actors, and does not scrub sensitive
   inputs. Open issues https://github.com/ash-project/ash_paper_trail/issues/40 (bulk actions),
   /issues/104 (non-referenced actors), /issues/30 (redact sensitive values in stored inputs/changes),
   /issues/171 (errors with managed relationships). Only one actor per version: https://elixirforum.com/t/how-to-pass-second-actor-parameter-to-the-ash-paper-trail/69322 (2025-02-10).
3. Approval / draft-then-publish workflows have no package; people bend PaperTrail into it.
   https://elixirforum.com/t/manager-approval-workflow-with-ash-paper-trail-for-record-changes/67343 (2024-11-08, older than 2025).
4. AshEvents edge cases with generated primary keys and manual/around hooks. Replay fails with
   “No such input id” for auto-generated PKs; the maintainer’s workaround is to make id writable and
   accepted: https://elixirforum.com/t/ashevents-no-such-input-id-for-action-how-to-handle-auto-generated-primary-keys/73950 (2026-01-13/15).
   Open issues https://github.com/ash-project/ash_events/issues/101 (bulk update + around_action raises
   InvalidReturnType, 0.8.1+) and /issues/99 (wrapping discards a declared manual).
5. No snapshots, and a contested event-sourcing model in AshEvents. A user looked for “snapshot”
   and found nothing; another argues it is not ES; the maintainer defends the model.
   https://elixirforum.com/t/ashevents-event-sourcing-made-simple-for-ash/70777 (posts #2, #3, #7-#11, 2025-05).
6. The only CQRS/ES binding is broken on its latest release. 0.1.0 did not compile; 0.2.0 fails
   generating aggregates; the fix was merged 2026-05-12 but not released; process managers are
   unaddressed (the author recommends Reactor).
   https://elixirforum.com/t/ashcommanded-a-declarative-cqrs-es-extension-for-ash/70900 (2025-11 to 2026-02);
   https://github.com/accountex-org/ash_commanded/pull/7.
7. Durable workflows are hand-assembled. Persisted reactors break on redeploy when steps use inline
   run fn (the function name embeds a body hash):
   https://github.com/ash-project/reactor/issues/334 (2026-08-14). Users asking for workflow engines with
   persistence and manual approval steps are pointed at Reactor + Oban, with persistence left to them:
   https://elixirforum.com/t/any-tips-on-building-a-workflow-engine-similar-to-n8n/71782 (posts #10, #14, 2025-07/08).
8. The TypeScript client has no authorization metadata for UI gating. You must write a generic
   action around Ash.can? to tell the frontend what the user may do:
   https://elixirforum.com/t/ash-typescript-pass-list-of-available-policies-to-the-user/73730 (2025-12-22).
   Also open: https://github.com/ash-project/ash_typescript/issues/100 (destroy of a nonexistent record
   reports success).

---

Round 2 re-verification

Document re-read in full (1,765 lines, ending with ## Revision log (round 2)). Line numbers
below refer to the revised document. Sources were re-opened; “fixed” below means I checked the
new text against the source, not only that the text changed.

Verdict: ACCEPT-WITH-FIXES (unchanged).

• Verified fixed: the ExampleReactor block (now verbatim), Ash.Test, error classes, the
  Reactor halt/resume retraction, AshEvents advisory locks / notifiers / encryption / Postgres /
  manual, the AshCommanded release history and compile bug, ash_event_log chronology,
  transaction attribution, undo/4, middleware callbacks, undo_action, ash_flow,
  ash_workflow, hephaestus, ariadne_flow, ash_authentication, the ash_ai security statement in
  §8, the honorable-mention numbers, and archival gap #9.
• Not acceptable as is: the revision log claims several fixes that were not made. Round 2
  introduced one new factual error (the AshEvents write ordering) and leans on one weak piece of
  evidence (reactor #334). The ranking edit left the document contradicting itself. All of this is
  editing work; no new research is needed.

R2-1. Round-1 findings: status (all high/medium; half of lows sampled)

R2-2. Code blocks: verbatim check (every block)

Verbatim: ExampleReactor (l.232-268), generic action (l.276-290), PaperTrail config (l.355-369;
source 29-41), test-resources property and policy blocks (l.576-610), async block (l.157-167),
middleware/around (l.180-191), halt/resume (l.204-208), AshArchival (l.991-1000), ash_typescript
nested-relationship TS (l.1210-1217; reflowed whitespace only).

The revision log (l.1731-1736) says every other block is verbatim or labelled “(abridged)”. That is
false for the following. Label each “(abridged: … omitted)” naming what was dropped, or paste it
verbatim:

R2-3. New round-2 claims

1. “AshEvents replaces the action with a manual implementation.” Correct.
   ash_events/lib/events/transformers/wrap_actions.ex:172-188 sets manual: to
   Create/Update/DestroyActionWrapper, the comment at l.260-263 says so, and
   reject_manual_actions! (l.51, l.264) rejects an action that already declares one.
   Citation problem (l.722-724): issue #99 (open, filed against 0.8.1) reports the opposite
   behaviour: the resource’s own manual was silently discarded, “no compile warning”. The 0.8.2
   clone rejects it at compile time. Cite wrap_actions.ex:51,264 for the rejection and describe
   #99 as “the 0.8.1 behaviour, now a compile error; issue still open”. Do not cite #99 as the
   reason it rejects.

2. §4.1, “events are committed before the projection changes” (l.727) and Implications #8
   (l.1495-1496). Wrong as a general statement for 0.8.2. Order varies by action type:

   • update: event first, then the row (lib/events/update_action_wrapper.ex:28-39).
   • create: row first via data_layer.create/upsert, then create_event! with the real
     primary key (lib/events/create_action_wrapper.ex:25-58).
   • destroy: row first (data_layer.update/destroy), then the event
     (lib/events/destroy_action_wrapper.ex:36-37,106).

   Zach Daniel’s post #11 links create_action_wrapper.ex at v0.1.1, so it describes 2025
   behaviour. Rewrite as: “both writes happen inside the action’s transaction; in 0.8.2 the event is
   written first for updates and after the row for creates and destroys”. Keep Daniel’s quote,
   dated, as his position.

3. Position B paraphrase (l.715-716): “katafrakt … argues it is an audit log”. Inaccurate.
   katafrakt’s post #3 says: “Ability to replay the state is great, but it seems that the state is
   still a primary concept and events are secondary … I would just avoid marketing it as event
   sourcing”. Post #10 adds Fowler’s “all changes … are initiated by the event objects”. He does not
   say “audit log”. Quote post #3 directly. Position A’s quotes (post #7 “AshEvents has this
   property”; post #11 “an event is always committed first, transactionally…”) are accurate. Post #9
   is cited but not quoted; its gist is “fits enough definitions … one way to do event sourcing with
   Ash”, so add it. The README phrase at l.712 is “rather than a full event sourcing solution”
   (README.md:182); quote it with “rather than”, because without that context it reads as a claim.

4. Reactor issue #334 (gap #7, l.1401-1402; Implications #10, l.1515-1517). Weak evidence.
   The issue exists, but it was closed as not_planned the same day (2026-08-14), with the
   reporter’s only comment: “Sorry my claude agent opened this !, I was asking it to report it to me”
   (gh api repos/ash-project/reactor/issues/334/comments). No maintainer confirmed it. The
   mechanism is real, and the source shows it: Spark names lifted anonymous functions
   "#{key}_#{n}_generated_#{fn_name}", where fn_name is the MD5 of the function’s AST
   (spark/lib/spark/code_helpers.ex:15-21 code_identifier/1, :332-336
generate_unique_function_name/2). Re-cite the Spark source as the evidence and describe #334 as
   “an AI-filed report closed as not planned”. (My round-1 review also cited #334 too readily.)

5. fully_reversible as half of the durability assembly (l.211-213, 339-340). Misread. The
   option is fully_reversible? (with ?), and its doc says: “When this option is set the Reactor
   will return a copy of the completed Reactor struct for potential future undo”
   (reactor/lib/reactor.ex:112-116). It concerns undoing a completed run later, not persisting
   progress. Fix the name, and drop it from the durability sentence (or say it is an undo-after-
   success option).

6. “Durability is hand-assembled from Reactor + AshOban + AshStateMachine” and the core-team
   guidance (l.335-340, 1398-1406). Supported. Forum 59508 post #3 (jimsynz, 2023-11-06):
   “Oban is the way to go … We have ash_oban … You can run a reactor inside your Oban job … Also look
   at ash_state_machine”. Forum 65945 post #4 (zachdaniel, 2024-09-09) notes “the sync nature of
   reactor”. Both predate 2025 and are labelled as such. Fine.

7. The 10 gaps (every URL fetched).

   • #1: supported (hex API; smokestack/README.md:6-7).
   • #2: supported; forum 75012 post #2 quote is exact.
   • #3: supported. ash_paper_trail issues #40, #104, #30 and #171 are all open with matching
     titles; forum 69322 post #2: “There is only ever one actor”.
   • #4: supported (forum 67343, 2024).
   • #5: supported (forum 73950 post #2, Torkan’s workaround is accurate; ash_events #101 and
     #99 open; forum 70777 post #2 on snapshots). Fix the #99 framing per item 1.
   • #6: supported (forum 70900 posts #3-#5, #10-#12). PR #7 was merged 2026-05-12 per the
     commit list.
   • #7: see item 4.
   • #8: supported (forum 73730 post #3; ash_typescript #100 open).
   • #9: supported.
   • #10 (ash_grant/ash_rbac → “the core policy model leaves work to do”): the hex numbers are
     right, but the conclusion is inference from existence, not evidence of a community complaint.
     It also leaves out that ash_rbac’s last release is 2024-10-01 (hex), i.e. dormant. Mark it as
     inference or move it to Implications.

R2-4. Ranking

The 20 rows still match hex.pm exactly (re-checked; ash_money 0.2.6 / 2026-06-08 /
163,618 / 46,717 and splode 0.3.2 / 2026-08-06 / 1,810,058 / 670,174 match). Honorable-mention
additions (ash_credo, ash_appsignal, ash_grant, ash_rbac, ash_jason 2026-03-04, ash_oaskit
2026-09-16, ash_scenario, ash_random_params) match hex. The ranking rule is still not applied
consistently, and the edit created contradictions:

1. splode promoted to #20 (l.836) for the same reason igniter/spark were demoted. The table
   itself calls it “plumbing”, and l.809-810 demote igniter/spark as “infrastructure”. Either demote
   splode too and fill slot #20 with the best-adopted domain-relevant honorable mention by the stated
   rule (for example ash_onetime, idempotency, or ash_workflow, durable workflows), or state a
   rule that admits splode.
2. “Ranked candidates I deliberately cut” (l.838-849) still lists ash_money and splode as
   cut, and §9 honorable mentions still list both (l.1315, l.1320), while they are ranked #19 and
   #20. Delete those entries.
3. The stated rule (l.801-804) says transport/storage packages rank below domain packages “even at
   10× the downloads”. Yet ash_postgres (storage) is #2 and ash_phoenix/ash_json_api/
   ash_graphql (transport) are #12-#14, above ash_cloak (#15), ash_double_entry (#18) and
   ash_money (#19), which the table categorises as “Domain”. Reorder, or amend the rule to say
   storage and transport are ranked by adoption within a separate band.
4. §6 was not renumbered. Headings still run ### 15. igniter, ### 16. spark, ### 17. ash_cloak
   … ### 20. ash_double_entry (l.1069-1132). There are no per-package notes for ash_money or
   splode, which criterion 3 requires for every ranked package. The revision log (l.1750-1751)
   says “DSL examples added for the packages that lacked them”, but §6 #6 ash_authentication, #12
   ash_phoenix, #13 ash_json_api, #14 ash_graphql and #18 ash_admin still have no DSL example, and
   ash_rate_limiter has only config. Add them, from ash_phoenix/documentation/,
   ash_json_api/documentation/, ash_graphql/documentation/, ash_admin/README.md,
   ash_authentication/documentation/tutorials/ and the rate_limit do … end block in
   ash_rate_limiter/README.md:100-140.

R2-5. Other residual errors

R2-6. Fresh citation sample (30 citations not checked in round 1)

• Supports: reactor.ex:108-110 (concurrency_key); architecture.md:78; cheatsheet:53-55;
  reactor.md:168-180; reactor.md:64-97 (verbatim); ash_events/README.md:515-525, :174-182,
  :205-210, :182, :490-513, :596-622, :644-651; ash_events/mix.exs:146; forum 70777
  posts #7/#11 quotes; test.ex:25,118,179-201,238-283; error.ex:10-14; generator.ex:753,764, 814,870,932,988,1035 (all seven function heads at the stated lines); ash/usage-rules/testing.md:19-32;
  ash_commanded/README.md:4, :34-39/:41-60/:62-68; forum 70900 posts #3-#5, #10; PR #7
  merge date; ash_double_entry/mix.exs:156; ash_ai/README.md:133-137.
• Wrong line, claim true: reactor.md:50-52 (the sentence is at :41); usage_rules/README.md:86
  (the tip is at :87).
• Does not support:
  • 01-getting-started.md:70-110 as an “abridged” copy (the body is rewritten).
  • reactor.ex:108-127 for fully_reversible as durability.
  • Forum 70777 post #3 as “argues it is an audit log”.
  • Reactor issue #334 as community evidence (closed not_planned, AI-filed).

R2-7. ash_typescript wire transport: factual account (from the clone, v0.18.4)

All paths are under scratch/ash-src/ash_typescript/.

• What the developer declares.
  • On the domain: use Ash.Domain, extensions: [AshTypescript.Rpc] and a
    typescript_rpc do resource MyApp.Todo do rpc_action :list_todos, :read; rpc_action :get_todo, :read, get_by: [:id]; … end end block (documentation/getting-started/installation.md:150-162).
  • On each resource: extensions: [AshTypescript.Resource] with typescript do type_name "Todo" end; the example attributes are public? true (installation.md:112-136).
  • Referenced actions must be public? true, verified at compile time (README.md:135-137).
  • An app-wide manifest module (use AshTypescript.Manifest, otp_app:) registered as
    config :ash_typescript, manifest: is mandatory (README.md:26-45).
  • Codegen: mix ash_typescript.codegen or mix ash.codegen (installation.md:224-230).
• Endpoints. Two POST routes, /rpc/run and /rpc/validate, served by a controller the
  installer generates (installation.md:69-75). The controller calls
  AshTypescript.Rpc.run_action(:my_app, conn, params) and validate_action/3 and returns
  json(conn, result) (installation.md:171-196). Endpoint paths are configurable via
  run_endpoint/validate_endpoint (installation.md:212-221). otp_app does not scope which
  actions are reachable; actions resolve from the single manifest (lib/ash_typescript/rpc.ex:667-671).
• Request shape. Every generated function builds a JSON payload starting with
  action: "<rpc_action_name>", plus, depending on the action: tenant, identity (for
  update/destroy), getBy, input, fields, filter/sort/page, metadataFields
  (lib/ash_typescript/rpc/codegen/helpers/payload_builder.ex:48-110). Typed queries send
  typed_query_action instead of action (lib/ash_typescript/rpc/pipeline.ex:381-406). The
  server pops input and identity, converts other keys from the configured
  input_field_formatter (camelCase by default, installation.md:219-220), takes the actor, tenant
  and context from the Plug conn (or socket assigns for channels), then validates required
  parameters, top-level query params, requested fields, input, get_by and pagination
  (pipeline.ex:59-140).
• Response shape. Always a map, never a tuple: %{"success" => true, "data" => …} or
  %{"success" => false, "errors" => [...]}. Key casing follows output_field_formatter
  (rpc.ex:673-686, run_action/3 at :686-695).
• Errors. Each error has type, message, shortMessage, vars, fields, path and
  optional details (documentation/guides/error-handling.md:36-52). A non-2xx HTTP response is
  turned client-side into a synthetic network_error with statusCode (lib/ash_typescript/rpc/ codegen/typescript_static.ex:529-547). Since 0.18, unusable top-level filter/sort/page
  return filter_not_supported/sort_not_supported/pagination_not_supported
  (README.md:49-53).
• Field selection and typed results. fields is an array of attribute names plus nested objects
  for relationships/embedded values (first-rpc-action.md:96-108). The generated runtime includes
  utility types (TypedSchema, InferResult) that derive the result type from the selected fields
  (typescript_static.ex:10-13). Relationship envelopes (page/filter/sort/fields) are gated
  in the types by capability (README.md:55-87).
• Fetch layer. executeActionRpcRequest/executeValidationRpcRequest do POST with
  Content-Type: application/json, merge headers and fetchOptions from the call config, and use
  config.customFetch || fetch (typescript_static.ex:433-552). fetchOptions (e.g.
  AbortSignal.timeout, credentials) and customFetch (e.g. an axios adapter) are documented in
  documentation/advanced/custom-fetch.md:10-70. A buildCSRFHeaders() helper is generated for
  browser apps (first-rpc-action.md:23,152-157).
• Lifecycle hooks. Configured by name: rpc_action_before_request_hook,
  rpc_action_after_request_hook, rpc_validation_before_request_hook and
  rpc_validation_after_request_hook (all default nil;
  documentation/features/lifecycle-hooks.md:57-86). The before-hook receives (action, config)
  and returns a modified config; the after-hook receives (action, response, result, config)
  (typescript_static.ex:471-492). Channel equivalents also exist (typescript_static.ex:555-620).
• Validation functions. validate<Action> functions are generated when
  generate_validation_functions: true. They call /rpc/validate, which builds the
  changeset/query without executing and returns {success: true} or the same error array
  (documentation/guides/form-validation.md:159-215; server side rpc.ex:704-717). Channel
  variants exist (form-validation.md:216-235).
• Zod/Valibot. Opt-in via generate_zod_schemas: true / generate_valibot_schemas: true, with
  import paths and suffixes configurable, written to ash_zod.ts / ash_valibot.ts and covering
  resources, RPC actions and typed-controller routes (documentation/reference/configuration.md: 26-67,138-139).
• Typed controllers. use AshTypescript.TypedController with a typed_controller do module_name …; get :auth do run fn conn, params -> … end end … end DSL. It generates an ordinary
  Phoenix controller plus TypeScript path helpers and typed fetch functions. Route arguments are
  validated (and since 0.18 enforced at runtime with 422s), and router path params must match
  arguments (documentation/guides/typed-controllers.md:1-70,454; README.md:97). Intended for
  cookie/session-style endpoints “where an rpc action isn’t a natural fit” (typed-controllers.md:14-16).
• Multitenancy.
  • With require_tenant_parameters: true, a tenant parameter is required in every generated
    signature.
  • With the default false, the tenant is optional and otherwise taken from the conn
    (documentation/features/multitenancy.md:18-36; server fallback
    normalized_params[:tenant] || Ash.PlugHelpers.get_tenant(conn) at pipeline.ex:77-81).
• Stated limits.
  • Ash ≥ 3.27 and a manifest module are required (README.md:28).
  • Types with no TypeScript mapping fail compilation (“Unsupported types found”,
    documentation/advanced/custom-types.md:95).
  • Hand-rolled custom types degrade to z.any() / z.record(z.string(), z.any()) in schemas unless
    you use Ash.Type.NewType or mapping overrides (documentation/reference/troubleshooting.md:221-240).
  • An Ash version bump alone can change generated output (README.md:102).
  • Open issues: #100 (destroying a nonexistent record reports success), #95 (the igniter installer
    creates invalid routes), #84 (control over custom-type generation), #51 (TanStack Query factories
    requested).
  • There is no UI-facing authorization metadata; the maintainer’s workaround is a generic action
    around Ash.can? (forum 73730).

R2-8. Criteria after round 2

---

Round 3 final check

The document was re-read in full (2,135 lines, revision log with truthful Round 2 and Round 3
sections). Line numbers below are for the round-3 document. Every item was re-opened in the
clones, on hex.pm (moved and added rows re-fetched today), on GitHub or on the forum.

Final verdict: ACCEPT.

• All round-2 “still wrong” items are fixed correctly, apart from one citation that the revision log
  says was fixed and was not (reactor.md:50-52).

• Every code block is now verbatim or labelled as abridged, except two minor mislabels.

• The ranked table matches hex.pm. Section 7.1 matches the clone.

• Two kinds of problem remain:

  • The ranking rule’s “adoption orders the rest” is not what the table does inside the domain band.
  • A handful of small factual slips.

  None of these changes a design conclusion, and all are listed under Residual errors with the
  correct fact, so readers can use the document without another revision.

R3-1. Round-2 “still wrong” items

R3-2. Code blocks

Each block was compared with its source.

• Verbatim:
  • Reactor getting-started: 01-getting-started.md:64-112. The cited range :64-110 stops two
    lines early.
  • ExampleReactor; generic action; PaperTrail config; middleware/around; halt/resume; async.
  • Generator, with its label naming the added comma and the reflow.
  • test-resources blocks; ash_archival; the ash_typescript typescript_rpc domain block
    (installation.md:154-162); createTodo (first-rpc-action.md:53-71); getTodo (source
    :99-109); the controller in §7.1.
  • All the new §6 examples, except ash_onetime (below).
• Abridged, correctly labelled and only by omission: compensate, AshEvents event_log/events,
  replay, Smokestack, AshCommanded, ash_ai tools, AshOban, AshStateMachine (stitched; labelled),
  AshCloak, ash_typescript manifest (merged; labelled).
• Abridged, but the label also admits a modification: usage_rules (l.1082-1084). One comment
  is reworded, and the label says so. This is not “abridged only by omission”, but it is disclosed.
• Mislabelled: ash_onetime (l.1253-1267) is labelled “verbatim”, but the README quick-start
  block continues with a second protect :redeem do … end (strategy :one_time_nonce,
  window(...), commit :independent) that is omitted (https://github.com/baselabs/ash_onetime,
  README l.108-114).
• Hand-written blocks: none remain.

R3-3. Ranking

Hex.pm re-fetched for the moved or added rows: ash_onetime 1.4.0 / 2026-09-24 / 2,831 / 2,831;
ash_postgres, ash_phoenix, ash_admin, ash_graphql, ash_money, ash_rate_limiter and
splode. All match the table. No package is both ranked and listed in the cut list or §9.

• ash_onetime facts: right on version, downloads, AshOnetime.Resource, Postgres-mandatory,
  rejection of read-only/non-transactional actions, and “not end-to-end exactly-once delivery”
  (README l.11-16, 43-55, 67).

  • Wrong: “released 2026-09-24 … all of them in its first days” (l.1252-1253). The package was
    first published 2026-08-09 and has 19 releases; 2026-09-24 is only the latest one
    (hex inserted_at, releases).
  • Also wrong: the revision log’s “both are days old” (l.2133).

• ash_workflow / ash_credo / ash_scenario evaluations (l.897-901): factually right (dates,
  downloads, descriptions).

• The rule is not applied as written inside the domain band. l.887-888 say the mandatory areas
  come first and then “adoption orders the rest”. Rows 7-15 are not in adoption order:

  • usage_rules (301,065) sits below ash_ai (100,126);
  • ash_authentication (216,171) below ash_typescript (41,363);
  • ash_money (46,717) below ash_rate_limiter (43,309) and ash_double_entry (21,137).

  ash_typescript’s position is an explicitly stated exception; the others are not. Also, the
  storage/transport band contains ash_admin (category “Admin UI”), which is neither storage nor
  transport.

  Choosing ash_onetime over ash_workflow while calling ash_workflow “more domain-relevant”
  contradicts “relevance first”; the log admits adoption was used as a tiebreaker. This is a
  judgement call, not a factual error.

• Storage/transport band order (postgres 305k > phoenix 272k > json_api 164k > admin 119k >
  graphql 62k) is correct.

R3-4. Did round 3 break content that was right after round 2?

No loss found:

• igniter/spark notes moved intact into §9 (“Notes on the demoted infrastructure packages”).
• Honorable mentions are unchanged apart from removing ash_money.
• §7’s pre-existing content is kept; the “Limits and sharp edges” list now partly duplicates §7.1’s
  “Stated limits” (redundant, not wrong).
• One internal inconsistency is new (Implications #8, below).

R3-5. Fresh citation sample (25 not checked in rounds 1-2)

• Supports: installation.md:151-162; installation.md:224-230; first-rpc-action.md:53-71;
  ash_authentication/.../get-started.md:183-199; ash_rate_limiter/README.md:104-113; ash_money
  tutorial :34-36 and :40-43; ash_money/README.md:20-22 and :24-26;
  references.md:13-19; ash_phoenix.ex:133-138; forms-for-relationships-between-existing-records.md:180-183;
  ash_json_api tutorial :145-147; ash_admin tutorial :63-68; graphql-generation.md:36-43;
  ash_state_machine tutorial :140-143/:161-165; ash_oban tutorial :76-95;
  wrap_actions.ex:172-188; update_action_wrapper.ex:28-39; destroy_action_wrapper.ex:36-37,106;
  spark/lib/spark/code_helpers.ex:15-21,332-336.
• Wrong line, claim true: first-rpc-action.md:96-108 (block is :99-109);
  getting-started-with-ash-cloak.md:26-41 (block is :23-52); configuration.md:26-30,64-67,136-140
  for the Zod/Valibot opt-in (flags are at :40-45).
• Does not support: the ash_onetime README block labelled “verbatim” (it omits
  protect :redeem).

Residual errors (for readers)

Every statement in the round-3 document that is still wrong, with the correct fact. Apply these when
reading; everything else checked in the three rounds is reliable.

No other residual errors were found. Hex.pm numbers, the AshEvents, AshCommanded and Reactor
technical claims, §7.1, the gaps’ URLs, and the honorable-mention data were all re-verified as
correct.