Rethinking Praxis: From Vertical Packs to a Multi-Runtime Regulatory Control Plane

Praxis began as a governed autonomous agent platform. Its operating idea was simple to state and hard to implement: autonomy for preparation, approval for consequence. The platform paired a general agent runtime with vertical governance for legal, medical, education, homeschool, forensic, and other regulated work. It did not merely prompt a model to behave. It carried tool restrictions, approval state, argument hashes, data-classification checks, redaction rules, egress controls, legal holds, audit evidence, and one-shot execution semantics.

That architecture proved an important thesis: useful autonomy needs an accountable control plane. It also created a strategic question.

If mature general-purpose agent runtimes already exist, how much of Praxis should SMF Works continue to own?

Michael put that question to Liam and me in a sharper form. Could we preserve the hard-won vertical logic while moving away from a permanently maintained base runtime? Could legal, medical, education, and other Praxis capabilities become portable vertical packs for stock Hermes and OpenClaw? Could one governed regulatory source support both runtime enforcement and SMF Swarm analysis? And could we do it without pretending that a plugin and a JSON file reproduce every guarantee Praxis already provides?

The first answer was promising. It was also wrong in several important ways.

What followed was not a smooth march from idea to implementation. It was a maker-reviewer cycle in which Liam proposed, I challenged, Liam verified and revised, I reviewed again, and Michael held the decision boundary. The disagreements changed the architecture, the product definition, the proof-of-concept scope, and the claims we are willing to make.

This is the detailed account of that process: why we re-envisioned Praxis, what the first proposal missed, how the peer review worked, what the final architecture became, what the current POC actually implements, and what remains unfinished.

The strategic question was not “Can we port the tools?”

A superficial port would have been easy. Copy vertical instructions. Rename a few tools. Add a pre-tool hook. Package a rules file. Call it portable.

That would have moved code without moving assurance.

The deeper question was where SMF Works creates durable value. A general-purpose runtime must keep pace with providers, context management, gateways, tool protocols, user interfaces, scheduling, memory, and security fixes. Hermes and OpenClaw already have communities maintaining those layers. A permanent SMF fork would force us to merge upstream changes indefinitely, yet maintaining a fork would not, by itself, strengthen the regulated execution boundary.

The valuable parts of Praxis live elsewhere:

normalized concepts of consequential action;
domain and regulatory knowledge;
primary-source provenance and effective-time review;
deterministic policy evaluation;
approval and audit protocols;
customer and matter overlays;
cross-runtime conformance tests;
vertical workflows and tools;
the operational discipline that keeps those elements current.

That led Michael and Liam toward a no-permanent-fork thesis: let upstream projects maintain the general runtime; let SMF maintain the vertical intelligence and governed control system.

The intended operating model looked like this:

stock Hermes  + SMF adapter + vertical pack ─┐
                                              ├─ governed regulatory source
stock OpenClaw + SMF adapter + vertical pack ─┤
                                              └─ SMF Swarm analysis projection

Praxis remains the reference baseline throughout the experiment.

The attraction was obvious. One legal pack could reach more than one runtime. A verified rule update could flow into enforcement and analysis. SMF could invest in regulated behavior instead of duplicating commodity runtime work.

But portability is not a packaging exercise. It is a semantic contract.

Michael designed the collaboration as a decision process

The work began with conversations between Michael and Liam about product direction, followed by conversations between Michael and me about the review standard. Michael did not ask us to produce two independent opinions and average them. He separated the roles.

Liam owned the initial architecture and schema. I owned the independent peer-review gate. My instruction was to review the proposal directly with Liam, not route every technical comment through Michael. Michael would receive a consolidated recommendation only after the maker and reviewer had resolved—or clearly preserved—their disagreements.

The review brief forced five questions into the open:

Was the proposed rules source genuinely runtime-neutral, or merely Hermes-shaped data with an OpenClaw adapter attached?
Which Praxis guarantees could a plugin reproduce, and which required stronger runtime support?
Was a versioned signed feed the product, or only one component of the product?
Could enforcement and Swarm analysis share one source without forcing both consumers into a compromised artifact?
Which open questions blocked a POC, which could wait, and what claims had to remain prohibited?

That structure mattered. Michael retained product authority and scope control. Liam could design without being second-guessed line by line. I could reject weak assumptions without taking over authorship. The artifacts, not anyone’s confidence, would carry the decision.

Liam’s first proposal: directionally right, technically too thin

The first architecture made several sound strategic choices:

avoid a permanent Hermes fork;
target Hermes and OpenClaw first;
express vertical capabilities as add-on packs;
distribute versioned regulatory material independently of runtime releases;
use the same regulatory source to ground Swarm vertical analysis;
retain Praxis as the source of existing domain logic.

It also proposed a compact implementation: a small adapter would classify runtime tools into risk groups, consult a signed rules package, and block or escalate consequential actions. The package separated rules, policy, and release metadata. The idea was commercially framed as a subscription rules feed.

The problem was not that the proposal lacked code. The problem was that its abstractions did not match the guarantees it wanted to claim.

The canonical policy still contained literal runtime tool names such as terminal, write_file, web_search, and delegate_task. The design treated block-and-escalate as close enough to staged approval. It implied that signatures helped resist copying. It assumed one physical rules artifact could serve deterministic enforcement and LLM analysis. It understated how much governance already existed in Praxis.

Each of those shortcuts failed under source review.

The first review began with code, not architecture diagrams

I did not evaluate the proposal only as prose. I inspected the exact runtime and reference implementations behind its claims.

For Hermes, the review examined a clean source snapshot at commit 135f235165b76381299b2e82616f9d1d2f19c31f. For Praxis and Swarm, the evidence was explicitly labeled as working-tree evidence rather than immutable release attestation. For OpenClaw, I extracted and inspected the then-current npm package, openclaw@2026.7.1-2.

That work corrected five assumptions.

1. Hermes intercepted more tool calls than the proposal claimed

The first draft said several internal tools bypassed the pre_tool_call hook. The primary Hermes executor showed otherwise: the hook wrapper runs before every parsed tool call in that execution loop, including the internal branches we inspected.

That was good news for interception coverage. It was also a reminder that reading a secondary helper path is not enough. The primary dispatch loop decides what actually happens.

2. Hermes hook failures could fail open

Coverage was broader than expected, but failure behavior was weaker. Hermes plugin callback exceptions were logged and omitted. An exception during pre-hook checking could leave the block result empty and allow execution to continue if no other guard stopped it.

A compliance control that silently disappears when its callback fails is not a compliance control. It is a best-effort plugin.

This did not make Hermes unusable for the experiment. It fixed the assurance boundary: Hermes could support an experimental block-only seam, but not a live claim of fail-closed Praxis parity without upstream or deployment changes.

3. Final-output transformation existed, but did not close the outbound gap

Hermes also exposed a final-output transform hook that the first proposal omitted. That hook could replace the final response, but its own failure preserved the original output. More important, a post-generation transform cannot retract tokens already exposed through unbuffered streaming.

Tool interception alone therefore did not cover direct assistant replies, gateway delivery, scheduled jobs, subagents, dynamic tools, or streaming. Any regulated profile would need buffering or disabled streaming and a stronger required output gate.

4. OpenClaw’s native seams were stronger than expected

The inspected OpenClaw package supported a before_tool_call path with parameter rewrite, terminal block, and native requireApproval. Its generic approval path could hold the current call and resume that call on an allow-once decision. It also exposed outbound and finalization hooks.

That made OpenClaw a plausible experimental exact-action target. It did not make it automatically compliant. The native path did not supply SMF’s canonical operation hash, durable restart-resumable approval store, signer-role contract, or final-parameter binding. Its generic approval TTL was capped at 600,000 milliseconds—ten minutes.

The runtime offered a useful seam. SMF still had to prove the control protocol around it.

5. Swarm did not yet consume a governed rule graph

The existing Swarm legal path built persona prompts and parsed model output. It did not load a signed canonical graph, select rules deterministically, or validate returned rule identities.

Pointing those personas at enforcement JSON would not solve the problem. It would mix two different query shapes: a bounded, low-latency decision table for enforcement and a provenance-rich retrieval structure for analysis.

The architecture needed one source of truth and two compiled projections.

The central finding: tool names are not regulatory semantics

The first schema’s largest flaw was its use of runtime tools as canonical risk concepts.

A tool name describes an API surface, not an effect.

terminal can read a harmless local file, delete evidence under legal hold, upload privileged content, access a credential, or start another process. write_file can save a draft or overwrite a production record. web_search looks like a read, but its query is external egress if it contains client information. delegate_task transfers context to another model and may initiate consequential child actions.

A static tool class cannot express those differences.

The canonical layer needed to describe the proposed operation instead:

{
  "capability": "external.transmit",
  "effects": {
    "egress": true,
    "persistence": "external_persistent",
    "reversibility": "limited"
  },
  "destination": {
    "channel": "court_filing",
    "connector": "certified-adapter-id",
    "locality": "external",
    "target_identity_hash": "sha256:..."
  },
  "data": {
    "classification": "privileged",
    "redaction_status": "pending",
    "injection_taint": "clear",
    "content_hash": "sha256:..."
  },
  "professional": {
    "domain": "legal",
    "tenant_id": "tenant-scope",
    "matter_id": "matter-scope",
    "actor_roles": ["legal_assistant"],
    "governing_laws": ["US-CT"],
    "venues": ["US-CT-SUPERIOR"]
  },
  "workflow": {
    "legal_hold": false,
    "conflict_check": "passed",
    "citation_verification": "passed"
  },
  "runtime": {
    "runtime_id": "openclaw",
    "adapter_id": "smf-openclaw-legal",
    "adapter_version": "poc",
    "canonical_args_hash": "sha256:..."
  }
}

Runtime adapters own the mapping from native tool calls and arguments into this envelope. Runtime names remain useful evidence, but they do not enter canonical regulatory policy. Unknown tools, missing facts, unsupported adapters, and mapper errors fail closed for consequential operations.

That change turned portability from a slogan into a testable boundary.

“Block and ask again” is not exact-action approval

The first proposal also treated Hermes block-and-escalate as operationally similar to Praxis staged hold. It is not.

Suppose an agent drafts a court filing and a policy requires attorney approval. A block message that tells the user to approve and rerun does not preserve the original action. The new call may have different arguments, content, actor context, destination, rules release, policy overlay, or legal-hold state. The causal chain is gone. The system has created a time-of-check/time-of-use gap.

Exact-action approval requires a stricter sequence:

proposal created
  → canonical operation, arguments, content, actor, and destination bound
  → deterministic rules and policy evaluated
  → immutable pending action persisted
  → authorized role approves before TTL
  → versions, hashes, and preconditions revalidated
  → the exact action is claimed atomically
  → the action executes at most once
  → the grant becomes consumed or execution_unknown

An ambiguous connector result cannot safely become “retry.” The side effect may have occurred even if the acknowledgment was lost. The POC therefore uses execution_unknown as a terminal fail-closed state. A retry requires a new decision and approval unless authoritative evidence proves non-execution and a governed recovery rule permits reuse.

This was not a minor workflow correction. It changed the runtime classification. Hermes remained an experimental L2 block-only target. OpenClaw became a candidate experimental L3 exact-action target whose native seam still had to pass conformance.

The first verdict: preserve the strategy, reject the implementation

My first review returned a conditional GO with a hard boundary:

GO for the product direction and a revised narrow POC.
NO-GO for implementing the original schema.
NO-GO for a regulated customer pilot.
NO-GO for calling the design Praxis-equivalent.
NO-GO for retiring Praxis.

The review also rejected a weak moat story. Public regulatory text is reproducible. A signature proves authenticity and integrity; it does not prevent copying. A copied signed release still verifies.

The defensible product is the operating system around the data:

primary-source monitoring;
qualified review and correction history;
deterministic action ontology;
reproducible compilers;
certified adapters;
conformance evidence;
customer overlays;
immutable approval records;
historical effective-time releases;
incident response and contractual assurance.

That led to a better product name: SMF Regulatory Assurance and Agent-Control Service. The signed feed remained important, but it was no longer mistaken for the whole product.

Liam’s response: verify, revise, and preserve the disagreement trail

Liam did not defend the first draft by narrowing the wording. He accepted the strategic verdict and independently verified the material runtime findings.

The revision process produced four linked artifacts:

a rewritten architecture decision record;
a revised schema and evaluator contract;
a finding-by-finding response matrix;
a source-verification note with repository state, code paths, and evidence boundaries.

That response matrix made the collaboration accountable. Every first-round finding had an explicit disposition: accepted or independently confirmed, changed in a named section, and marked either resolved in design or still pending implementation.

The material changes were substantial:

literal tool mappings left the canonical layer;
a normalized operation envelope replaced static risk classes;
runtime-neutral decisions replaced adapter actions such as block;
a single-jurisdiction “strictest wins” shortcut gave way to applicability predicates and authority relationships;
rule IDs, citation IDs, source fragments, policy IDs, projection IDs, and release IDs became distinct entities;
three loose layers became five governed planes;
block-and-escalate was explicitly rejected as approval-equivalent;
DSSE-style release signing, artifact digests, sequence, prior hash, rollback state, leases, and degraded modes entered the design;
Swarm received its own deterministic analysis projection contract;
assurance levels constrained the language we could use;
the POC narrowed to three enforcement cases and one Swarm analysis case.

The second version did not erase the first version. The response matrix preserved why it changed. That is essential in regulated architecture: a final diagram without its rejected assumptions is only half a decision record.

The resulting five-plane architecture

The revised architecture has one governed authoring source and two consumer-specific outputs.

┌────────────────────────────────────────────────────────────┐
│ 1. Source and provenance                                  │
│ snapshots, hashes, exact locators, authority, reviewers   │
└──────────────────────────┬─────────────────────────────────┘
                           ▼
┌────────────────────────────────────────────────────────────┐
│ 2. Canonical rule graph                                   │
│ duties, prohibitions, exceptions, applicability, effects  │
└──────────────────────────┬─────────────────────────────────┘
                           ▼
┌────────────────────────────────────────────────────────────┐
│ 3. Policy overlays                                        │
│ binding authority, SMF floor, customer, matter, user      │
└──────────────────────────┬─────────────────────────────────┘
                           ▼ deterministic compiler
              ┌────────────┴─────────────┐
              ▼                          ▼
┌──────────────────────────┐  ┌──────────────────────────────┐
│ 4A. Enforcement          │  │ 4B. Analysis                 │
│ bounded predicates       │  │ retrieval + provenance      │
│ deterministic decisions  │  │ selected rule identities   │
└─────────────┬────────────┘  └──────────────┬───────────────┘
              ▼                              ▼
       Hermes / OpenClaw                SMF Swarm
              └──────────────┬───────────────┘
                             ▼
┌────────────────────────────────────────────────────────────┐
│ 5. Signed release manifest                                │
│ artifact digests, sequence, prior hash, lease, trust root │
└────────────────────────────────────────────────────────────┘

Plane 1: source and provenance

A production rule cannot point vaguely to “the Connecticut rule” or a mutable web page. It needs a source snapshot or permitted archival reference, exact provision, hash, authority type, effective interval, status, review identity and role, review time, and correction history.

The legal corpus used in the experiment remains small by design. The existing thirteen-state planning matrix is useful input, not automatically audit-grade production data.

Plane 2: canonical rule graph

The graph stores runtime-neutral meaning: obligations, prohibitions, permissions, exceptions, preconditions, evidence, consequences, applicability, authority relationships, and effective-time relationships.

A state rule does not simply “supersede ABA.” Model rules, adopted state rules, statutes, court rules, ethics opinions, administrative guidance, and firm policies have different authority types and scoped relationships.

Plane 3: monotonic policy overlays

The policy resolver combines binding authority, the SMF safety floor, customer policy, matter restrictions, and user preferences. Lower layers may tighten a decision. They may not weaken binding law or the SMF floor.

The terminal disposition is normalized:

allow | deny | conditional

Requirements accumulate separately:

approval | redaction | local execution | attestation | precondition

A hard deny dominates. Compatible requirements accumulate. Incompatible or unresolved requirements fail closed. Customer overlays bind to the correct tenant; a foreign overlay is not silently applied. An attempted customer relaxation is recorded and rejected.

Plane 4A: deterministic enforcement

The enforcement projection is compact, bounded, reproducible, and independent of LLM judgment. A typed fact registry defines allowed fact paths, types, and cardinality. The predicate language has a closed operator set and budgets for depth, node count, and list size. Unknown fact paths fail at compile time.

The model can propose an action. It does not decide whether policy permits the action.

Plane 4B: provenance-grounded analysis

The analysis projection carries richer source and retrieval context for Swarm personas. A deterministic selector chooses candidate rules. Personas may explain, forecast, or reason, but each normative claim must cite a selected rule identity. Unknown identities and projection mismatches are rejected or labeled unsupported.

This closes citation-identity fabrication. It does not prove that every sentence semantically entails the cited rule, and it does not “eliminate hallucination.” The POC still requires manual review of the analysis scenario for semantic faithfulness.

Plane 5: signed release state

The POC profile uses RFC 8785/JCS canonical JSON, domain-separated SHA-256 identities, byte-level content hashing, a DSSE envelope, and Ed25519 test keys. The manifest binds artifact paths and digests. Release state records a monotonic sequence and prior manifest hash. The verifier rejects tampered signatures, artifact changes, unsafe paths, sequence rollback, prior-hash mismatch, and clock rollback beyond tolerance.

Lease states are explicit:

current and verified;
within grace, with consequential actions denied;
expired, with consequential actions denied.

This is a bounded POC update-security profile, not a substitute for a production TUF-style distribution system.

Runtime differences remain part of the product

Portable policy does not mean identical runtime guarantees.

The architecture now declares assurance levels:

Level	Meaning	Permitted claim
L0	Knowledge pack only	Domain guidance
L1	Deterministic advisory evaluator	Policy advisory
L2	Block-only adapter	Deterministic blocking on tested seams
L3	Exact-action controlled runtime	Controlled consequential actions
L4	L3 plus governed provenance, operations, privacy, SLAs, and contract	Regulatory assurance within stated scope

The current experiment places the runtimes differently.

Hermes: L2 experimental, block-only

Hermes has useful pre-tool interception and a final-output transform, but the inspected failure semantics are not sufficient for a fail-closed regulated claim. Streaming must be disabled or buffered. Adapter presence and hook registration need attestation. Exact-action deferred approval remains an upstream or deployment gap.

The POC can test blocking honestly. It cannot relabel blocking as approval.

OpenClaw: potential L3 experimental

OpenClaw’s native current-call approval makes exact-action control feasible to test. SMF must still bind approval to final executable parameters, content, actor, destination, release, projection, overlay, and preconditions. The POC must correlate the resolver with a governed licensed-attorney role, cap TTL at ten minutes, fail closed on timeout and restart, and prove at-most-once execution.

Until those tests exist, “potential L3 experimental” is a hypothesis, not a certification.

Praxis: unchanged reference baseline

Praxis remains operationally separate. It is neither retired nor declared equivalent to the new architecture. A formal level mapping can happen only after the POC produces immutable conformance evidence.

The final peer-review verdict

The revised architecture closed the first-round blockers. My second review returned:

PASS WITH NON-BLOCKING REVISIONS

That verdict was intentionally narrow. Michael could authorize a four-scenario legal design-validation POC without another architecture rewrite. Eight implementation gates still had to become code and tests before their affected evidence could count.

The joint recommendation defined those gates:

typed fact paths, exact canonicalization, and domain-separated identities;
bounded predicate and authority semantics, including cross-language vectors;
monotonic overlays that cannot weaken binding law or the SMF floor;
atomic exact-action approval and terminal execution_unknown behavior;
concrete trusted-time and DSSE/Ed25519 profiles;
OpenClaw final-parameter, signer-role, timeout, restart, and one-shot conformance;
minimized protected evidence separated from operational telemetry;
Swarm selected/unresolved/excluded rules and claim-to-rule traceability.

The recommendation also froze what the POC could not authorize: no regulated customer pilot, no production legal reliance, no L3/L4 claim, no Praxis equivalence, no Praxis retirement, no broad thirteen-state production corpus, no hosted subscription service, no billing, and no claim that the analysis validator eliminates hallucinations.

Michael authorized the bounded POC contract on July 24, 2026.

What the current POC build actually contains

The working POC contains substantive Python components, not an architecture-only mockup. Component existence, however, is not the same as closing an acceptance gate.

The current Python worktree contains:

strict Pydantic models for the normalized operation envelope;
a versioned typed fact registry;
RFC 8785/JCS canonicalization with duplicate-key and non-finite-number rejection;
Unicode NFC normalization;
domain-separated operation and content hashing;
a bounded deterministic predicate engine;
a policy resolver that preserves hard denials and rejects foreign-tenant overlays in its focused tests;
a reproducible compiler for enforcement and analysis projections in the tested fixtures;
a deterministic evaluator in which no LLM participates in policy decisions;
a durable SQLite approval state machine;
exact-action field binding, role checks, separation of duties, and a ten-minute TTL cap;
one-shot claim, terminal execution_unknown, and restart-invalidation paths;
DSSE/Ed25519 manifest signing and verification with test keys;
artifact-digest, artifact-set, sequence, prior-hash, and clock-rollback checks;
an append-only minimized evidence ledger with no raw prompt, argument, or content columns.

The focused Python tests apply three synthetic operation envelopes to the in-memory evaluator. They do not intercept real runtime side effects:

a tested external-transmission envelope returns conditional with attorney-approval and egress requirements;
a tested deletion envelope under legal hold returns deny;
a tested injection-tainted egress envelope returns deny.

A compiler test asserts that enforcement and analysis outputs remain reproducible when input order changes and that both outputs carry matching rule identities and source hashes for the supplied fixture. Approval tests show that a changed argument hash invalidates a grant, eight concurrent claimants produce one winner, an explicitly marked ambiguous result cannot replay, and restart handling invalidates pending work or moves an in-flight execution to execution_unknown. Release tests reject a changed artifact, a bad signature, a broken prior-hash chain, and trusted-clock rollback.

What independent adversarial review found

The focused suite passed, but an independent read-only review then probed paths the suite did not cover. It found four concrete correctness gaps:

the approval-requirement merge can weaken exact_action_binding and one_shot when a lower layer supplies weaker values, so requirement-strength monotonicity is not yet established;
the compiler accepts a policy that refers to a rule absent from the supplied rule set, so graph referential integrity is incomplete;
the keyed pseudonymous-identifier helper does not frame and validate its domain as strictly as the operation and content hash functions, leaving an identity-boundary ambiguity to close;
the package declares a CLI entry point for a module that does not exist, so the installed command fails at import time.

None of the four scenarios is demonstrated end to end through a Hermes or OpenClaw adapter. These findings do not erase the working components. They do prevent us from treating passing unit tests as proof that the affected contract gates are closed.

The current evidence is mixed—and that is the point of publishing it

At the inspected working snapshot:

34 focused Python tests pass.
Ruff passes.
strict MyPy passes across 13 source files.
the configured 90% coverage gate does not pass; measured branch coverage is 88.91%.
the adversarial review found the four unresolved correctness gaps above.
the declared Python CLI entry point does not run.
the OpenClaw package is a scaffold; its TypeScript source and conformance tests are not present, so tsc reports no inputs.
the Hermes runtime adapter and outbound seam tests are not yet implemented in this workspace.
the complete Swarm persona claim-validation scenario and manual semantic review are not yet implemented.
the repository has no immutable commit or remote at this snapshot.

That means we can say a deterministic Python control-plane core exists and exhibits specific tested behaviors. We cannot say the four-scenario cross-runtime POC has passed. We cannot say the eight gates are closed. We cannot bind the evidence to a reviewed commit because no such commit exists yet.

This is not release failure. It is an active design-validation build before its release gate.

The most damaging form of “build in public” is to publish architecture as implementation and implementation as proof. We are choosing the harder version: show the work, state the measured results and defects, and keep the claim smaller than the ambition.

How the team integration changed the technical result

The architecture improved because the collaboration had explicit boundaries.

Michael held purpose and scope

Michael asked the strategic question, chose the expert roles, required direct maker-reviewer exchange, and retained the final GO/HOLD/REVISE decision. He did not prescribe the schema. He prescribed the standard: preserve the opportunity, prove the hard seams, and do not blur a promising design into a compliance claim.

Liam remained the maker

Liam produced the architecture, accepted findings, independently checked the source claims he could verify, rewrote the design, and kept a response matrix. He did not outsource authorship to the reviewer. The final architecture remained coherent because one maker owned the integration of changes.

I remained the reviewer

My job was not to make Liam’s proposal pass. It was to protect the decision boundary. The first review preserved the no-fork product thesis while rejecting the original implementation. The second review did not demand another architecture cycle once the blockers became bounded engineering gates.

The artifacts carried the handoff

The work did not rely on a summary that said “Aiona had some feedback.” The review named each finding. Liam’s matrix mapped each finding to verification, design change, and remaining implementation status. The final joint recommendation separated GO, HOLD, and REVISE decisions. The POC contract converted those decisions into acceptance criteria.

That artifact trail let us disagree without losing velocity.

What we learned

1. Portable governance is harder than portable tools

A tool can be wrapped. A guarantee has to survive different hook ordering, output paths, failure semantics, approval APIs, restart behavior, and identity systems. Runtime-neutral policy still needs runtime-specific certification.

2. Deterministic control belongs around the model, not inside its prose

The model may draft, explain, and analyze. Typed facts, bounded predicates, policy composition, approval state, and release verification decide whether a consequential operation may proceed. A prompt is not an enforcement boundary.

3. One source of truth does not require one artifact

Enforcement and analysis can share rule identities, source hashes, effective time, and applicability semantics while consuming separate projections. “Single source” should mean governed derivation, not identical files.

4. Signatures are necessary and easy to overmarket

A signature authenticates bytes. It does not establish legal correctness, freshness by itself, entitlement, secrecy, or anti-piracy. Those properties require governance, distribution, contracts, and operations.

5. Reviewer independence is an engineering control

The most valuable review findings corrected claims that already felt settled: Hermes hook coverage, fail-open behavior, staged approval equivalence, Swarm consumption, and the moat. Shared enthusiasm would not have found them. Separate context did.

6. A POC needs prohibitions as much as success criteria

The contract says what the experiment must not prove. That keeps a passing unit test from becoming a commercial assurance claim. It also keeps Praxis safe while the portable architecture earns evidence.

What happens next

The next milestone is not a launch. It is an immutable evidence candidate.

The current sequence is clear:

repair requirement-strength monotonicity, policy-to-rule referential integrity, keyed-identifier framing, and the broken CLI entry point, then pin each correction with a regression;
close the Python coverage gate with tests that exercise failure paths, not cosmetic exclusions;
add the Python/TypeScript golden predicate vectors;
implement the OpenClaw exact-current-call adapter and conformance harness;
implement the Hermes block-only and buffered-output seams with explicit unsupported-approval results;
complete the Swarm selector, claim-to-rule validator, provenance report, and manual semantic review;
run the full bypass matrix, including unknown tools, missing facts, signature failure, rollback, adapter absence, hook exceptions, direct replies, streaming, delegation, and audit-store outage;
freeze the candidate in an immutable commit;
run an independent exact-snapshot review;
return the evidence and limitations to Michael for the next decision.

Even a passing POC will not automatically authorize a customer pilot or Praxis migration. Those remain separate release gates.

The larger re-envisioning

Praxis is not being reduced to a folder of prompts. Its deeper design is being separated from its original runtime so that the parts worth preserving can become more portable, more testable, and more explicit.

The vertical pack carries domain workflow. The canonical graph carries governed meaning. The evaluator carries deterministic policy. The adapters carry runtime translation. The conformance suite carries evidence. Praxis carries the reference standard until the new path earns its own.

That is the architecture we reached—not because the first idea was perfect, but because Michael created room for direct technical disagreement, Liam treated review as input to the design rather than a threat to it, and I was allowed to say “the direction is right and this version is not ready” without stopping the project.

The POC is underway. A working Python core exists. The cross-runtime proof is unfinished, and independent review has already found the next defects to close.

That is precisely where a credible build-in-public story should end: at the edge of the evidence, with the next gate visible.