A transparent local method for planning model routes

Choosing a model for each task is a policy problem as much as a capability problem. Sensitivity, acceptable latency, cost preference, capability coverage, and fallback behavior can conflict. When routing logic is opaque, teams cannot explain why one profile was selected or why another was rejected.

Routiva makes a proposed route inspectable before any real system uses it. It does not claim that a profile will be fast, cheap, available, or high quality in production.

• Local first: task contracts, profiles, scenarios, manifests, and receipts remain in the browser.
• Deterministic: identical inputs produce identical ordering.
• Privacy before ranking: ineligible profiles never receive a score advantage.
• Explainable: every eligible score and exclusion reason is visible.
• Explicit actions: saving, copying, downloading, wallet connection, and proof execution are separate.
• Honest states: blocked, unconfigured, pending, confirmed, failed, recovery, and unavailable are first-class outcomes.

The application is delivered as a web interface and executes its planning logic in the browser. React state holds the active edit. Browser storage can retain the model catalog, current task, up to three scenarios, manifests, and local proof receipts. Browser Web Crypto hashes the exact JSON manifest and receipt evidence.

There is no model invocation layer, prompt upload, account database, cloud synchronization service, API-key store, billing system, or team control plane in this MVP.

A task contract contains a name, category, sensitivity level, maximum latency tier, cost priority, quality priority, and whether external profiles are allowed.

A model profile contains an ID, display name, capability tags, context tier, latency tier, cost tier, permitted sensitivity levels, local or external availability, planning quality level, and enabled state. Profiles are user-controlled examples; they are not live provider facts.

Routiva first excludes disabled profiles and profiles that fail privacy, capability, or maximum-latency gates. Each remaining profile receives an additive planning score: exact capability match contributes 1000; quality contributes quality level × quality priority × 10; inverse cost contributes inverse cost tier × cost priority × 8; inverse latency contributes inverse latency tier × 12.

Results sort by descending score. The profile ID, in ascending lexical order, resolves an exact score tie. This final key makes order stable even if the catalog array arrives in a different order.

For a sensitive task with external profiles disallowed, every external profile is excluded before ranking. A profile is also excluded when its privacy availability does not include the task sensitivity. If no profile survives, the result is Blocked. If every profile is disabled, the result is Needs configuration.

The highest ranked eligible profile is Primary. The next two eligible profiles, if present, are Fallback 1 and Fallback 2. Routiva does not execute a fallback, monitor health, retry calls, or observe real availability. It only records the planned order.

A manifest contains version, creation time, complete task contract, summarized model profiles, published rule descriptions, route status, Primary profile ID, up to two Fallback IDs, and exclusions with reasons. The receipt pairs this object with a lowercase 64-character SHA-256 digest of its serialized JSON.

The digest proves byte-level consistency between a receipt and the manifest that produced it. It does not prove that the model data is accurate, that a route was executed, or that an organization approved the policy.

Connect Wallet requests only the public account list and active network identifier. Connection does not sign a message, submit a transaction, approve spending, transfer value, activate points, prepare a proof, or pay.

A successfully connected wallet can be attached as public identity to a local receipt. This is not an ownership signature or authorization claim. Routiva has no points, transfer, or airdrop workflow.

Publish Route Proof is separate from wallet connection. Without a verified contract target, the workflow runs only as a Local Demo. Preview, pending, confirmed, failed, and recovery describe local processing; the receipt keeps contract address, transaction hash, and block time unavailable. It never invents an explorer confirmation.

Routiva reduces prompt exposure by not accepting or transmitting prompts. Residual risks include malicious browser extensions, compromised devices, modified local storage, copied receipts shared with the wrong party, inaccurate user-entered profiles, and a hostile deployment origin. A SHA-256 digest detects manifest changes but does not authenticate the author.

Users should validate profile data, protect their device, inspect wallet requests, and avoid treating a local receipt as third-party certification.

• No model calls, gateway traffic, retries, availability checks, or real benchmarks.
• No guarantee of cost, speed, quality, safety, uptime, or model compatibility.
• No prompt storage, cloud sync, user account, API-key management, billing, or team administration.
• No real cost estimate; cost and latency are user-defined ordinal tiers.
• No policy certification, legal compliance decision, security audit, or operational enforcement.
• Browser storage can be cleared, blocked, corrupted, or unavailable.

Possible future work includes import/export validation, signed manifests, configurable proof targets, richer policy testing, and adapters that translate an approved manifest into external infrastructure. These are directions, not commitments. Any execution adapter would require a separate trust and security review.

Routiva is demonstration and planning software provided as-is. Example profiles and scenarios are fictional planning inputs. A route result is not professional, security, financial, legal, or procurement advice. Users remain responsible for validating data and deciding whether and how to implement a policy.