Gaps, risks, and validation criteria for Traverse to become a general software development model (not just a strong architecture)

[enricopiovesan]

Traverse (UMA runtime) is one of the clearest attempts at contract-governed, WASM-portable business capabilities that can run across browser, native, edge, cloud, and AI agent surfaces. Callweave is a useful early existence proof of the model applied to a non-trivial domain.
This issue collects concrete gaps, concerns, and validation criteria that still need to be closed (or measured) before the claim “this changes how software is built” is fully earned. The goal is constructive: surface the hard problems so they can be tracked, prioritized, or deliberately deferred.

1. Cross-runtime behavioral identity
   Concern
   Portability is the core value proposition. It is not yet demonstrated at the level of “same capability binary → contract-identical results across hosts.”
   What would close the gap

Same WASM artifact + same contract version executed in at least: browser (WASM), Node/CLI, one native host (e.g. Swift), and ideally one more (edge or cloud function).
Public, reproducible comparison of outputs and full execution traces.
Explicit policy for what “identical” means (bit-identical vs contract-identical under allowed non-determinism).

Until this is visible and repeatable, the “run anywhere” claim remains partially aspirational.
2. Composition vs. glue-code reality
Concern
A rich catalogue of atomic capabilities is only valuable if non-trivial workflows can be assembled mostly by wiring published capabilities rather than by writing a large custom orchestration / policy layer.
What would close the gap

A reference workflow (e.g. Callweave’s recording → classify → plausibility → unknown clustering → sanitize → review → knowledge update) implemented with minimal custom glue.
Metrics or qualitative evidence showing how much of the workflow is pure capability composition vs. host-specific or one-off code.
Patterns (or runtime support) for sagas, compensation, retries, and multi-capability transactions without each app reinventing them.

3. Reuse across products, not just within one product
   Concern
   One application using its own capabilities is good modularity. The transformative claim requires the same governed capability to be usefully reused by different products/teams with only contract-level configuration.
   What would close the gap

At least a few capabilities published and consumed by two or more independent applications in different domains.
Evidence that versioning, deprecation, and contract evolution work in practice across consumers.
Clear guidance on when a capability should be public/reusable vs. app-private.

4. AI agents productively using contracts (C-DAD in practice)
   Concern
   Machine-readable contracts + MCP exposure are a strong foundation. The open question is whether agents can discover, reason about, compose, and respect placement/policy constraints without large custom system prompts that re-describe the whole system.
   What would close the gap

Demonstrations of agents composing multi-capability workflows using primarily the contracts and traces.
Measurement of how much additional prompt context is still required.
Failure modes when an agent proposes an invalid composition or violates a placement constraint (and how the runtime + traces make this recoverable).

5. Governance cost vs. benefit
   Concern
   Immutable contracts, registry PRs, CI gates, traces, and human review are excellent for auditability and AI safety. They become a liability if the process of publishing or evolving a small capability is heavier than just writing ordinary code.
   What would close the gap

Honest data (or at least qualitative reports) on time-to-publish for small vs. complex capabilities.
Clear “escape hatches” or private/app-scoped publication paths that stay lightweight.
Criteria for when governance overhead is justified vs. when it should be relaxed.

6. Authoring experience: Rust requirement vs. LMM skill path
   Current state (as of FAQ)

Authoring new capabilities from scratch officially requires Rust.
Consuming existing capabilities does not.
Claude skills (traverse-capability-author and related) already aim to interview the user, write the contract, generate ABI-compliant WASM, and open a human-reviewed PR.

Concern / gap
There is a tension between the official “you need Rust” stance and the intended skill-driven path (“describe the capability in natural language”). For the framework to reach non-Rust developers and product people, the skill path needs to be first-class and reliable.
What would close the gap

Documented success rate / review burden of skill-generated capabilities (correctness, security, ABI compliance).
Explicit product stance: is “author by description + review” a supported primary path, or still experimental?
Guidance on what kinds of capabilities are safe for pure LMM generation vs. which still need human Rust expertise.
Clarity on the residual skill required of the human reviewer (can a non-Rust person meaningfully approve?).

7. Trustworthiness of generated WASM
   Concern
   If capabilities are increasingly authored via LMM skills, the generated binaries must be consistently correct and safe. Governance catches many failures, but generation quality determines whether review stays about intent or becomes constant bug-fixing.
   Ideas / needed work

Stronger test generation and property-based checks tied to the contract.
Sandbox / permission boundaries that limit the blast radius of a bad capability.
Provenance linking contract → source → binary → review decision.

8. Performance and operational reality under continuous / heavy load
   Concern
   Callweave’s domain (continuous audio, local models, retention) is deliberately demanding. Other real domains will be too. The capability model must not impose unacceptable latency, memory, or recovery costs.
   What would close the gap

Benchmarks for realistic workloads (not only micro-benchmarks).
Clear stories for storage, retention, back-pressure, and recovery when capabilities are interrupted.
Guidance on when a local companion service is required vs. pure browser/WASM.

9. Capability library density (the condition for token / cognitive savings)
   Observation
   If a rich, high-quality public (and private) capability library exists, AI-assisted development can shift from “re-derive business logic, validation, provenance, privacy, versioning…” to “select and compose existing governed units.” That is where large token and cognitive savings appear.
   Gap
   We do not yet have evidence of the density and quality threshold at which composition becomes the dominant activity for new apps.
   Ideas

Track library growth and reuse metrics.
Publish example “green-field app built mostly from existing capabilities” case studies with rough token/effort comparisons.
Identify the cross-cutting capabilities that unlock the most leverage (provenance, retention, privacy redaction, model gating, review/approval workflows, etc.).

10. Developer experience for the median user
    Concern
    Even with skills, the system must feel approachable. Current surface area (contracts, registry, WASM, hosts, traces, MCP, governance) is large.
    Ideas

First-class “app from workflow description” path (workflow-planner → gap list → author/extract → compose).
Better progressive disclosure: simple consumption first, authoring second, deep governance third.
More reference apps that demonstrate the thin-shell + shared capabilities pattern on multiple platforms.

Suggested validation milestones (proposal)
These could be tracked as separate issues or a project board:

Identity: Same capability binary, multiple hosts, public traces + comparison.
Composition: Non-trivial multi-step workflow with minimal custom glue.
Cross-product reuse: ≥2 independent apps consuming the same published capabilities.
Agent composition: Agent builds a working multi-capability flow primarily from contracts.
Authoring path: Documented, measured LMM skill → reviewed capability path with clear quality bar.
Governance cost: Publish time and friction data for small capabilities.
Library leverage: At least one case study of an app built mostly by composition, with effort/token notes.

Closing
Traverse already demonstrates unusually clear thinking about trust boundaries, portable units of behavior, and AI-consumable contracts. The gaps above are not reasons to abandon the approach; they are the concrete tests that would turn a strong architecture into a credible shift in how software (and AI-assisted software) is built.
Happy to refine any of these into separate, actionable issues or to help draft acceptance criteria for the milestones.

[enricopiovesan]

Thanks for the concrete framing — a shared stage-level evidence matrix across hosts is exactly the kind of proof we care about (capability version, tool result, retry/compensation, latency, terminal state).

On the ranking question: we do not publish a comparative “most expensive to diagnose” scoreboard yet, so I will not invent one. What is already visible as a real cross-host pain today is composition / placement under host planner limits (e.g. browser-local planning currently builds single-parent chains, so multi-input report.* graphs stop composing mid-chain — see website#79 / registry follow-ups), plus the usual honesty rule that fail-closed unsupported surfaces (IndexedDB private records / maintenance, some Stateful ABI imports) are deferred until a named consumer is blocked.

Streaming vs tool-calls vs retries vs state persistence as a cost ranking is still an open measurement question, not a settled Traverse claim. If you have a specific host pair + workflow where one of those four dominates, drop the repro details here and we can treat that as demand signal.