RFC: erp-agent — bscode sibling for ERP / business-API agents

[telleroutlook]

Summary

Proposes a fourth repository in the WasmAgent ecosystem — erp-agent
— positioned as a sibling of bscode rather than a replacement.
The two reference apps share the same runtime (wasmagent-js) and
data factory (trace-pipeline); they differ only in their tools,
verifiers, and target deployment surface.

The thesis: the wasmagent flywheel is task-agnostic by design.
bscode is the first reference app (coding); ERP / business-API
agents are a different vertical with materially different economics
and a much weaker public data baseline. Adding a sibling proves the
task-agnostic claim and opens a market with stronger willingness
to pay than coding tools.

This is a scoping RFC: it asks for agreement on the structure
and the boundary between "what lives in the new repo" vs. "what gets
upstreamed into wasmagent-js / aep / trace-pipeline". It is not yet
a build plan.

Why this is structurally possible

The current ecosystem already separates task-agnostic primitives
from task-specific glue, even though we've only ever instantiated
one task (coding via bscode). The split:

Layer	Repo	Task-agnostic?
WASM runtime, model adapters, ranking, AEP emitter	wasmagent-js	yes
MCP firewall, gateway, taint, consent, lease	wasmagent-js	yes
Compliance verifier framework + repair planner	wasmagent-js	mostly — verifier interface is task-agnostic; concrete verifiers are not
AEP record schema (v0.2, v0.3 in #7)	wasmagent-js	yes
validate-aep, trust-score, audit-report	trace-pipeline	yes
TrainingDataExporter (SFT / DPO / PPO / router records)	trace-pipeline	yes
Cloudflare worker shell, auth, session, KV, rate-limit, rollout-adapter	bscode	mostly — could be lifted to a template
Concrete tools (fs_write, bash, read_file, ...)	bscode	task-specific
Concrete verifiers (BuildPassesVerifier, VisualAssertVerifier)	wasmagent-js (lib) + bscode (adapter)	task-specific

Concretely, packages/core/src/agents/verifiers/types.ts:38-44 already declares the
verify_method field as an open string union — built-ins are
listed for autocomplete, but applications can register custom kinds
via VerificationPipeline.register(). The docstring explicitly says:

This keeps the protocol product-agnostic — bscode's "build_passes"
or a CI's "lighthouse_score_min" verifier registers without
touching WasmAgent core.

ERP-specific verifiers (order_state_machine_valid, ledger_balanced,
permission_boundary_respected, ...) fit the same registration
pattern. Nothing in the runtime needs to know they exist.

Proposed structure

erp-agent/                                ← new sibling repo
├── apps/
│   ├── worker/                           ← runtime shell (mirrors bscode)
│   │   ├── src/
│   │   │   ├── tools/                    ← ERP-specific tools
│   │   │   │   ├── odoo-xmlrpc.ts
│   │   │   │   ├── netsuite-suiteql.ts
│   │   │   │   ├── sap-odata.ts
│   │   │   │   └── domain-glossary.ts
│   │   │   ├── verifiers/                ← ERP-specific verifiers
│   │   │   │   ├── order-state-verifier.ts
│   │   │   │   ├── ledger-balance-verifier.ts
│   │   │   │   ├── permission-boundary-verifier.ts
│   │   │   │   └── dual-write-consistency-verifier.ts
│   │   │   ├── rollout-adapter.ts        ← copy bscode pattern
│   │   │   ├── trajectoryExport.ts       ← AEP emission, mirrors bscode
│   │   │   ├── auth.ts                   ← strict auth like bscode
│   │   │   ├── mcp.ts                    ← gateway mounted at /mcp
│   │   │   └── ...
│   │   └── package.json                  ← depends on @wasmagent/* via npm
│   └── web/                              ← operator approval UI (optional)
├── .githooks/                            ← same pre-push hook
├── docs/
│   └── BRANCH_PROTECTION.md              ← pointer to wasmagent-js canon
└── README.md

The shared-with-bscode surface is roughly:

• apps/worker/src/app.ts (Hono app skeleton)
• apps/worker/src/middleware/auth.ts, rateLimit.ts
• apps/worker/src/config/productionGuard.ts
• apps/worker/src/build-results.ts → renamed to verifier-results.ts (same shape, different semantic)
• apps/worker/src/rollout-adapter.ts (same pattern, adapted to ERP verifiers)
• apps/worker/src/trajectoryExport.ts
• apps/worker/scripts/test-aep-roundtrip.ts

The diff-from-bscode surface is:

• apps/worker/src/tools/ (all ERP API SDK wrappers + governance metadata)
• apps/worker/src/verifiers/ (domain logic — the moat)
• apps/worker/src/policies/ (lease shapes specific to financial/order side-effects)

Verifier taxonomy

Coding verifiers operate on deterministic build artifacts
(exitCode === 0). ERP verifiers operate on business-state
invariants which are mostly post-condition checks against the
target system's API. Proposed taxonomy:

Verifier family	What it checks	Example
State machine	Did the entity transition through a legal state edge?	quote → sales_order requires customer.credit_status == "ok"
Ledger / balance	Do debits == credits across the affected accounts?	After AP voucher post: AP↑, Cash↓ or Expense↑, sum balanced
Dual-write consistency	If the agent wrote to two systems (e.g., CRM + ERP), do they agree?	Salesforce Opportunity.amount == NetSuite Estimate.totalAmount
Permission boundary	Did the call respect the principal's role / segment / region?	Buyer in EMEA cannot approve PO over €5k without VP sign-off
Idempotency	Did a retry produce the same observable effect?	Two POSTs with the same idempotency-key → one row, not two
Audit-trail completeness	Did the underlying ERP create the expected audit records?	Approval action → audit_log row with principal + reason
Schema-drift detection	Did the response still match the contract we trained on?	NetSuite added a field, our prompt template now drifts

The first four are the high-value moat; the last three are
defensive. All seven plug into VerificationPipeline.register()
exactly like BuildPassesVerifier does today.

Compatibility with AEP v0.2 / v0.3

ERP tool calls map cleanly onto the current AEP record shape and
benefit from the v0.3 additions in #7 more than coding does:

AEP v0.3 field	Why it matters more for ERP than for coding
side_effect_class	Coding: read vs write vs network. ERP: read vs financial-mutate vs network-egress-to-third-party. Distinction is regulatory.
state_digest_kind: "db-rowset" + coverage descriptor	Pre/post digest over an explicit table + row predicate is exactly the shape an ERP post-condition verifier needs. The coverage descriptor (database, table, rows_predicate) was designed with this in mind even though the prompt was @armorer-labs.
argument_drift	High-stakes: a model that "approves PO #1234" then drifts to "approves PO #5678" is a real bug class in production. v0.3's one-record-per-event rule makes the audit trail explicit.
approval_mode: "bounded-lease"	The natural shape for "this agent can post journal entries in cost-centre X for the next 60 minutes, up to 10 entries, total ≤ $50k".
deny_reason_class: "missing-delegation"	Maps directly to SoD (segregation-of-duties) violations in financial controls.

No new AEP schema needs to be invented for ERP. The v0.3 RFC fields
work as-is. This is the strongest argument that the architecture
is task-agnostic in practice, not just in slides.

Training-data strategy

Coding has abundant public training signal (SWE-bench, MBPP,
HumanEval, IFEval). ERP has near-zero — every customer's business
rules, fields, and permissions are different, and no one publishes
training data over real ledger data.

This is both the opportunity and the constraint.

Opportunity

Training records produced by an ERP agent operating under real
business constraints are scarce by definition. They are the moat
that bscode-derived coding data cannot be.

Constraint

You cannot fork-execute ERP API calls the way you can fork
sandbox builds. There is no "try 100 branches, see which one
posts the right journal entry" — every call has externally-visible
side effects (or audit-log entries even if "rolled back"). Three
implications:

1. Generation happens in production runs, not in synthetic
   sweeps. A human operator + AI assistant produces one
   trajectory per real task. Trust-score gating and AEP signature
   verification become more important, not less.

2. Verifier-based reward, not fork ranking. RolloutForkRunner
   doesn't fit. Instead, RolloutSingleRunner + verifier ensemble
   produces a labelled record. Routes more like RLHF-from-real-use
   than DPO-from-ranked-rollouts.

3. Training stays close to customer data boundary. Two
   acceptable shapes:

   • Local training: customer runs trace-pipeline inside
     their VPC, model weights never leave.
   • Federated contribution: customer opts in to share
     redacted training records (using AEP's existing
     redaction_profile field at packages/aep/src/types.ts:55) in exchange for
     improved model weights.

Provenance

trace-pipeline/evomerge/schemas/training.py already carries a
Provenance.source: str field on every SftTrainingRecord /
DpoTrainingRecord. bscode emits source = "bscode-trajectory";
erp-agent would emit source = "erp-agent-trajectory" (or finer,
e.g. "erp-agent-odoo"). Downstream training can either filter by
source (separate domain models) or pool them (general capability
SFT across both verticals).

Pooling decision matrix:

Training stage	Pool bscode + erp-agent?
SFT — general capability (tool use, instruction following)	yes
SFT — domain reasoning	no (separate models)
DPO — "follow tool schema correctly"	yes
DPO — "right answer"	no
Router training (which task → which capability)	yes
Verifier ensemble for trust score	yes (each verifier reports independently)

Choice of first ERP target

PoC should target one ERP, not a portfolio. Three candidates:

Target	Pro	Con
Odoo (open source, XML-RPC + REST)	Source-available; testable locally; large SME market; SDKs in many languages	Less brand presence with enterprise procurement
NetSuite SuiteQL	Strong mid-market; reasonable API; query-rich	Account access expensive; auth (TBA) tedious
SAP S/4 OData	Largest TAM; API is well-typed	Sandbox access locked behind partner agreements; long sales cycle

Proposed first target: Odoo. Reasons:

• Lowest friction to set up a real test environment (Docker compose).
• Open source means the schema and the SDKs are public — we can write
  reference verifiers without an NDA.
• SME segment ≈ best fit for an MIT-licensed reference app: customers
  willing to self-host AI tooling tend to also self-host their ERP.
• Once Odoo proves the pattern works, the SAP/NetSuite adaptation is
  mostly a different SDK call inside the same tools/ shape.

Open question: is there appetite for a parallel erp-agent-netsuite
branch / fork from day one, or pick-one-and-finish-it?

What needs to change in existing repos

Mostly nothing. The reference design is "drop a new sibling
repo, depend on the same npm packages, define your own tools and
verifiers." Concrete required changes:

1. wasmagent-js — optionally extract apps/worker from bscode
   into a reusable template package (@wasmagent/worker-template).
   This is not blocking the erp-agent PoC; it's a quality-of-life
   refactor that would let future siblings (feat: zero-tech-debt — brand, schema, tier, stability, e2e data loop #3, chore: release packages #4, ...) skip the
   90% boilerplate copy.

2. wasmagent-js/packages/aep — no schema change beyond what
   v0.3 (#7) already proposes. ERP-specific fields stay in tool
   payload, not in the AEP envelope.

3. trace-pipeline — no schema change. Add an entry to the
   documented list of recognised Provenance.source values
   (purely documentation; the field is already str).

4. docs/ecosystem.md — update the diagram to show two
   reference apps under the same runtime + data factory. The
   "How the loop closes" pseudocode becomes generic ("agent runs
   tasks → …") with bscode and erp-agent as parallel instances.

5. docs/BRANCH_PROTECTION.md — extend the scope sentence to
   include the new repo. Already a shared canonical doc per the
   recent reorg, so this is a one-line edit.

Phased rollout

Three phases. Phase 1 commits to nothing concrete; phase 2 commits
to engineering work; phase 3 commits to customers.

Phase 1 — Architecture lock (1 week, this RFC's scope)

• Agree on the structure proposed here (or its revisions in
  comments).
• Pick first ERP target.
• Decide whether to extract @wasmagent/worker-template now or
  later. (Recommendation: later — copy bscode first; extract once
  the pattern is proven across two repos.)

No code changes.

Phase 2 — PoC (≤ 4 weeks)

• Stand up erp-agent repo, mirror bscode's worker structure.
• Implement 3–5 Odoo tools (read partner, read invoice, create
  quote, update customer, read journal entry).
• Implement 2–3 verifiers (order_state_machine_valid,
  customer_field_consistency, permission_boundary_respected).
• Run one end-to-end loop: operator says "create a quote for
  customer ABC" → AI calls Odoo → AEP records the action →
  trace-pipeline computes trust score → output the first ERP
  training record (Provenance.source = "erp-agent-odoo").

Success criterion: produce one verified ERP training record.
That's enough to prove the pipeline; everything after is volume.

Phase 3 — 1–2 paying customers (3–6 months)

• Recruit two design-partner customers (one Odoo, one larger ERP
  for the upgrade path).
• Local-training shape: customer runs trace-pipeline inside their
  VPC; we ship updates as model-merge recipes, not weights.
• Federated-contribution shape: customer opts in to share
  redacted SFT/DPO records; in exchange they get improved adapter
  weights.

Success criterion: a verified ERP-domain DPO record set that
outperforms a coding-only-trained baseline on the customer's own
held-out tasks.

Risks

1. Verifier-development cost is real. ERP verifiers need
   domain experts who've actually implemented SAP / NetSuite /
   Odoo flows. Hiring or partnering for this is a different
   problem than hiring engineers. Mitigation: start with
   permission-boundary and idempotency verifiers (cheap, general);
   take state-machine and ledger verifiers as a learning curve.

2. Customers won't share ledger data even if anonymized.
   This is the open-source-AI version of every healthcare data
   problem. Mitigation: lead with local-training, treat
   federated contribution as opt-in upside, not the default.

3. A bad PoC could damage the bscode story. If erp-agent
   ships visibly buggy verifiers, anyone evaluating bscode will
   wonder if the runtime is at fault. Mitigation: clear
   labelling (erp-agent is experimental); separate maturity
   tiers in the org README; don't cross-link until erp-agent is
   beta.

4. Engineering bandwidth. With three repos and one
   maintainer + one new contributor, adding a fourth is
   ambitious. Mitigation: Phase 2 is ≤ 4 weeks of one
   contributor's time, ~80% copy-paste from bscode. The
   expensive parts are tools + verifiers, which are
   straightforwardly parallel work to add a contributor for.

Non-goals

• Not a generic "ERP integration platform" (Mulesoft / Boomi /
  Tray.io territory). The point is agent training data, not
  integration plumbing.
• Not a hosted SaaS product. The reference app is MIT
  self-host like bscode; commercial offering (if any) sits at
  the trace-pipeline data-loop layer.
• Not a Salesforce / Workday / SAP partner integration. Those
  are sales channels, not engineering deliverables.
• Not changing the AEP v0.3 design to accommodate ERP. The
  v0.3 fields already fit; if they don't, we report back to
  #7 as a finding from a second runtime — which is exactly
  the empirical bar #7 sets for promoting decision_envelope
  to normative in v0.4.

Open questions

1. @wasmagent/worker-template — extract now or later? Extract
   now means erp-agent and any future sibling share a real package;
   later means we copy bscode and refactor after the pattern is
   proven twice. (Recommendation in this RFC: later.)
2. First ERP target — Odoo (recommended) or NetSuite?
3. Verifier ownership — @wasmagent/erp-verifiers as a npm
   package that lives in wasmagent-js (next to
   @wasmagent/core/agents/verifiers/), or kept inside
   erp-agent until a third consumer needs it?
4. Repo visibility — public from day one (matches bscode)
   or private until PoC is presentable?
5. Domain expert recruiting — does this RFC's acceptance
   imply a hiring commitment? (Not necessarily; could be
   contractor / advisor for the verifier portion.)
6. AEP v0.3 ERP feedback loop — if erp-agent finds the v0.3
   schema insufficient for some ERP scenario, that's a strong
   signal for the v0.4 design. Should we instrument the PoC to
   report back v0.3-coverage findings to #7?

Related

• AEP v0.3 RFC: #7 — pre-condition for several
  ERP-specific record shapes
• Verifier interface: packages/core/src/agents/verifiers/types.ts
• bscode rollout adapter (the pattern erp-agent should mirror):
  apps/worker/src/rollout-adapter.ts
• Trace-pipeline provenance: evomerge/schemas/training.py
• Ecosystem diagram (will need updating): docs/ecosystem.md

---

Comments welcome from anyone who has built agents against a
production ERP, particularly on the verifier taxonomy (which
classes I'm missing, which ones are too general to be useful) and
on the federated-vs-local training-data shape.

[armorer-labs]

From the agent-runtime side, I think the main thing to preserve is that ERP-specific logic should live in verifiers and tool metadata, not in a new audit-record shape.

A few practical checks I would add to the RFC before Phase 2:

• Treat every mutating ERP tool as having two scopes: the API endpoint scope and the business-object scope. For example, POST /invoices is not enough; the receipt also needs customer, subsidiary, cost center, currency, and amount boundary where available.
• Make idempotency a first-class verifier rather than a defensive afterthought. In ERP workflows, retries are not only a reliability concern; they are an authority concern because the second call may be outside the operator's intended one-shot approval.
• Keep permission-boundary verifiers separate from business-correctness verifiers. "This quote is valid" and "this principal was allowed to create it" fail for different reasons and should produce different receipts.
• For local training, log the redaction transform as part of the provenance. Six months later, a customer will ask whether a training record was produced from raw fields, hashed identifiers, bucketed values, or a synthetic replacement.
• Add a negative-path success criterion for the PoC, not only one verified positive ERP training record. A good first demo would include one denied or re-approval-required action where the receipt shows exactly why it did not execute.

On the Odoo vs. NetSuite question, Odoo seems right for the first public reference because it gives you replayable fixtures and inspectable schema. I would still design the verifier API as if NetSuite is next: rowset digests, principal/role evidence, and tenant/account boundaries should not assume a single open-source database shape.

The strongest version of this sibling repo is probably not "ERP agent can call APIs." It is "the same AEP authority model can describe a coding file write, a browser action, and a business-system mutation without inventing a new compliance story for each vertical." If the PoC proves that, it makes the task-agnostic claim much more credible.

Disclosure: I work on Armorer Labs.

[HainingYin]

Two notes from the runtime side that follow on from @armorer-labs's review.

Verifier interface: declare required scope

The distinction between API-endpoint scope and business-object scope highlighted in @armorer-labs's first point points to a real technical gap: today Criterion carries verify_method, arg, and an optional path, but a verifier has no way to declare what scope dimensions it actually reads. A permission_boundary_respected verifier needs principal + role + business-object (customer / cost-centre / region); if the runtime dispatches it with only the API endpoint info, the verifier returns a verdict that silently means "no scope evidence" rather than "boundary respected".

One implementation option for a future verifier-interface bump (not v0.3 AEP — different repo concern, but worth thinking through before erp-agent's Phase 2) would be to make the requirement explicit at the verifier interface layer:

export interface Verifier {
  readonly methods: readonly string[];
  // OPTIONAL — what scope dimensions this verifier reads from the action context.
  // If the runtime supports this field, it could fail-closed when a registered
  // verifier declares a scope dimension the current action evidence does not carry.
  readonly requires_scope?: readonly string[];
  verify(criterion: Criterion, ws: WorkspaceReader, ctx?: VerifyContext): Promise<CriterionVerdict>;
}

Backwards-compat: omitted requires_scope means "no scope requirements" (today's behaviour for BuildPassesVerifier, LLMJudgeVerifier, etc). If this lives on the verifier interface, the runtime check could be a pre-dispatch validation, not a runtime exception — same shape as the current "unknown verify_method" error path in VerificationPipeline.

Keeping permission-boundary verifiers separate from business-correctness verifiers becomes structurally checkable this way: a permission_boundary_respected verifier declares requires_scope: ["principal", "role", "business_object"] and a ledger_balanced verifier declares requires_scope: ["accounts", "currency", "amount"]. Two different receipts, two different failure modes, both inspectable from the receipt.

@wasmagent/worker-template extraction — concrete criterion

For the RFC's first open question (template extraction timing), a concrete promotion criterion would keep the decision measurable rather than indefinite:

Extract @wasmagent/worker-template once a file-by-file diff of apps/worker/src/ between bscode and erp-agent shows that more than 70% of files (or 70% of LOC, whichever is tighter) are byte-identical or only string-substitution different.

Below that threshold, premature extraction creates a "common subset" template that doesn't actually fit either repo — both end up overriding 40% of it and the indirection is pure cost. Above that threshold, the duplication tax across two sibling apps is large enough that future siblings (a third / fourth reference app) will copy from whichever sibling they like best, fragmenting the conventions.

This criterion is measurable from a single diff -r bscode/apps/worker/src/ erp-agent/apps/worker/src/ after Phase 2, so it doesn't require subjective judgement at the time the extraction call gets made.

Smaller: negative-path PoC criterion

A negative-path acceptance test alongside the positive one in Phase 2 would also be worth pinning down concretely:

• positive: produce one verified ERP training record with Provenance.source = "erp-agent-odoo".
• negative: produce one record where approval_grant: "bounded-lease" was active, argument_drift.result = "drifted" fired, and approval_decision = "drift-requires-reapproval". The receipt alone should let a reviewer reconstruct what was approved, what was attempted, and why the runtime declined to execute.

The negative case exercises the v0.3 fields RFC #7 is adding precisely where ERP needs them most, and the receipt failing to reconstruct the decision is what would tell us v0.3 is under-specified for this vertical (the "report back v0.3-coverage findings" loop the RFC's non-goals already names).

[armorer-labs]

This is the right place to draw the line. I would treat requires_scope as verifier metadata, but make the runtime outcome explicit in the receipt rather than hiding it as a generic verifier failure.

Concretely, I would split the checks into three stages:

• registry/load time: reject duplicate verify_method registrations unless they declare the same scope contract
• pre-dispatch: if a verifier declares a scope dimension that the action evidence does not carry, return a typed scope-evidence-missing verdict without invoking the verifier
• verifier execution: once scope evidence is present, the verifier returns the domain verdict, e.g. boundary-respected, boundary-violated, ledger-balanced, or ledger-unbalanced

That separation matters for ERP because "we could not prove the principal/customer/cost-center boundary" and "we proved the attempted action crossed the boundary" are different operator decisions. The first is environment or instrumentation readiness. The second is a policy denial. Both should be visible in the receipt, but they should not collapse into the same failed boolean.

For the requires_scope shape, I would keep the field low-level and enumerated at first, something like readonly requires_scope?: readonly ScopeDimension[], with dimensions owned by the runtime or app package. Free-form strings are convenient, but they make interop weaker unless there is also a registry of canonical dimensions. A practical middle ground is a small built-in set (principal, role, business_object, amount, currency, region, tenant) plus namespaced extension values for app-specific dimensions.

The worker-template extraction criterion also looks good, with one addition: measure duplicated behavior, not only copied files. I would include route shape, receipt emission, verifier registration, approval-gate wiring, and replay/export fixtures in the comparison. If the code is 70% identical but the receipts or verifier lifecycle differ, extraction will preserve the wrong thing. If those behaviors are identical, then byte-identical or string-substitution-identical files are strong evidence that the template boundary is real.

On the Phase 2 negative path, I would add one more assertion: the declined execution should leave no durable business-side mutation, and the receipt should say what was not executed. For ERP, a clean denial is only useful if the operator can distinguish "attempted but blocked before side effect" from "side effect happened and we need compensation." So the negative record should carry both the drift/reapproval decision and a side-effect outcome such as not_executed or no_business_mutation_observed, depending on how much evidence the harness can honestly collect.

That would make the Phase 2 PoC useful beyond erp-agent: it becomes a compatibility test for whether AEP v0.3 can represent missing scope evidence, policy denial, and no-mutation proof without forcing every vertical to invent its own receipt vocabulary.

Disclosure: I work on Armorer Labs.

[HainingYin]

Walking through the four points in order — three at the implementation layer, one deferred to the v0.3 spec call.

Three-stage verifier check with typed verdicts

Splitting the lifecycle into registry/load-time, pre-dispatch, and execution stages, with distinct verdict types per stage, lines up with how a non-failing receipt should read. "We could not prove the principal/customer/cost-centre boundary" (instrumentation gap) and "we proved the attempted action crossed the boundary" (policy denial) describe different operator actions, and collapsing them into a single failed boolean loses information that an audit reviewer needs.

Concretely on the wasmagent-js side, VerificationPipeline.register() is currently last-registered-wins (VerificationPipeline.ts:101) — silent overwrite. The three stages map to three changes that are independent of v0.3 AEP shape:

• registry/load-time: turn the silent overwrite into a rejection unless the second registration declares an identical scope contract (same methods set + same requires_scope shape). Error path mirrors the existing "no verifier registered for verify_method=..." branch (VerificationPipeline.ts:129), so the error surface stays uniform.
• pre-dispatch: when requires_scope declares a dimension the current action evidence does not carry, the pipeline emits a scope-evidence-missing verdict and skips the verifier call. Distinct from "verifier threw" (line 139) and distinct from a domain verdict — the receipt should be able to tell the three apart.
• verifier execution: domain verdicts (boundary-respected / boundary-violated / ledger-balanced / ledger-unbalanced / ...) come back from the verifier itself. The pipeline does not synthesize these.

This is a runtime-shape change rather than an AEP envelope change, so it can ship independently of the v0.3 schema timing.

requires_scope as readonly ScopeDimension[]

An enumerated dimension type makes interop checkable in a way free-form strings do not. A workable zod shape:

const BUILTIN_DIMS = [
  "principal", "role", "business_object",
  "amount", "currency", "region", "tenant",
] as const;

const ScopeDimension = z.union([
  z.enum(BUILTIN_DIMS),
  z.string().regex(/^[a-z0-9-]+\.[a-z0-9._-]+$/), // namespaced extension, e.g. "armorer.lease-window"
]);

export interface Verifier {
  readonly methods: readonly string[];
  readonly requires_scope?: readonly z.infer<typeof ScopeDimension>[];
  // ...
}

The regex enforces a vendor.dimension-name namespacing rule on extension values so two apps using "escalation" for different meanings cannot collide silently — they would each declare "acme.escalation" and "contoso.escalation" instead. Whether the canonical dimensions live next to the existing verifier types in packages/core/src/agents/verifiers/types.ts or in a separate file under the same package is a maintainer call; the regex / built-in list / extension namespacing pattern is the part worth pinning here.

Worker-template extraction — behaviour parity, not only file parity

A 70% file-identical metric combined with divergent receipt behaviour represents the failure mode where an extraction "succeeds" while encoding the wrong thing. Adding behaviour-parity gates alongside the file-diff threshold:

• route shape parity: dump the worker's HTTP surface (path + method + auth requirement) as an OpenAPI fragment for each repo, diff them. Mismatches are template-disqualifying unless explicitly justified.
• receipt emission parity: same input fixture run through both workers should produce AEP records whose top-level + actions[] shapes are equal under a defined canonicalization (aep/canon-1.0-equivalent), ignoring run-specific fields (run_id, timestamps, signatures).
• verifier-registration parity: the set of verify_methods registered at pipeline construction time should match, and any registered verifier with requires_scope should declare an identical scope contract across repos.
• approval-gate parity: the gate's decision surface (allow / deny / ask_user / dry_run + approval_mode) over a defined fixture set should be byte-identical between repos.
• replay/export-fixture parity: trace-pipeline export records produced from identical input fixtures should match under the same canonicalization.

All five are mechanical to check from outside either repo, so the extraction call doesn't depend on a subjective read of "are they really doing the same thing?". When file diff says yes and behaviour parity says no, the template is wrong; when file diff says no and behaviour parity says yes, the divergence is in incidental scaffolding that doesn't belong in a shared template anyway.

Phase 2 negative path — side-effect outcome alongside drift/reapproval

Carrying a side_effect_outcome such as not_executed / no_business_mutation_observed next to the drift / reapproval decision is the difference between a clean denial and a denial-the-operator-still-has-to-compensate-for. For ERP that distinction is the whole point of having a receipt: an operator looking at a denied action needs to know whether to do nothing or to issue a compensating transaction.

Where this outcome lives in the v0.3 AEP record (a new field on ActionEvidence like side_effect_outcome, a refinement of the existing side_effect_class, a sibling field on argument_drift, or somewhere else) is a v0.3 spec call rather than a runtime call — that's @telleroutlook's territory and I'll defer to whatever shape lands. Once the spec field exists, the runtime side can emit it from the gate path: when the gate denies before the tool invocation reaches the side-effect boundary, not_executed is asserted; when the verifier ensemble post-conditions confirm no business-side mutation after a partial execution, no_business_mutation_observed is asserted with the verifier evidence attached.

That last point also generalises past erp-agent: the Phase 2 negative-path record becomes a compatibility test for whether v0.3 can carry "missing scope evidence" + "policy denial" + "no-mutation proof" in one envelope — the same evidence shape a coding-task denial or browser-action denial would need.

[telleroutlook]

All five practical checks are well-placed — adding them to the Phase 2 spec directly.

API-endpoint scope + business-object scope as two separate dimensions

This is the right framing. A receipt that carries only the endpoint (POST /invoices) without customer, subsidiary, cost-centre, and currency boundary is not auditable in any ERP with multi-entity or multi-currency structure. I'll make the tool descriptor shape for ERP tools require both endpoint scope and business-object scope explicitly, rather than treating the second as optional enrichment.

Idempotency as an authority concern, not just reliability

Agreed. The idempotency verifier goes into the P0 verifier list alongside permission-boundary — not P2 defensive. A retry outside a bounded-lease invocation count is structurally the same as a new action without approval; the receipt needs to distinguish them.

Permission-boundary and business-correctness as separate verifiers

Confirmed as a design constraint for Phase 2. They produce different receipts, fail for different reasons, and should never be collapsed into one boolean. This also maps cleanly onto the three-stage verifier lifecycle (registry, pre-dispatch, execution) that came out of the v0.3 thread — scope-evidence-missing is a pre-dispatch result, not a verifier verdict.

Redaction transform logged as provenance

Good catch. The redaction_profile field on OutputRef exists but doesn't record what transform was applied — only which profile name. For training data provenance, the transform type (hash, bucket, synthetic replacement, raw) matters for reproducibility and for downstream model audits. I'll add this to the Phase 2 spec as a required field on the training export record, not on the AEP envelope itself.

Negative-path PoC criterion + side-effect outcome

The side_effect_outcome: "not_executed" | "no_business_mutation_observed" field will go on ActionEvidence in the v0.3 spec — it generalises cleanly to coding and browser actions too, not just ERP. A denied action that left no durable mutation and a denied action that requires compensation are operationally different; the receipt should say which one.

Odoo + design for NetSuite from the start

That is the approach — Odoo for the first reference, but rowset digests, principal/role/tenant boundary, and the verifier scope contract designed without assuming a single open-source schema. The requires_scope field and the namespaced ScopeDimension type will be part of the verifier interface spec in wasmagent-js before Phase 2 starts, so the ERP verifiers register correctly from day one.

The strongest version framing

That framing — same AEP authority model describes a file write, a browser action, and a business-system mutation without a new compliance story per vertical — is exactly what the PoC needs to demonstrate. I'll make that the stated goal of the Phase 2 summary doc, not a side note.