Contract Application Manifest (CAM) 1.3.0

CAM model

A CAM application is advertised by a deployed contract, called the CAM host contract. To load the application, an agent or viewer needs the chain ID of the network hosting that contract and its deployed address. The agent or viewer calls camManifest() on that contract to obtain one coherent manifest URI and SHA-256 digest; ICamApp defines these discovery methods. The repository's EVM adapter validates the URI, asks its supplied resource loader for manifest bytes, and checks their SHA-256 digest before JSON parsing. Its default loaders reject a mismatch; the viewer displays integrity warnings and continues loading. The manifest declares ABI/UI resources, contract calls, and continuations. The agent or viewer uses the parsed routes and arguments to prepare requested contract calls.

The manifest joins each contracts.Name namespace to an ABI resource. This repository's EVM profile resolves Name to a destination address through the host contract's contractAddress(string) binding API. That resolver belongs to the ICamApp interface together with the paired manifest getter. The manifest's ui namespace selects a UI resource; its routes namespace selects routes declared in the same manifest. Mutable address bindings are outside the manifest hash.

Each route joins one contract call to a next invocation. A read exposes normalized results as $outputs while resolving its continuation arguments for a named UI node. A write prepares a transaction and names another route to follow after success. It may first read one host-bound contract to resolve the transaction destination and arguments. The agent or viewer prepares requests; called contracts enforce their business rules. An agent can inspect the resolved UI and action model without drawing an interface, while following the declared read-to-UI handoff.

A bundle author supplies the manifest and ABI/UI resource bytes under their declared URIs. For publication, the author makes those resources available through a chosen transport. The authorized CamRoot owner advertises the manifest URI/hash and configures address bindings through separate transactions; the owner need not be the bundle author. Editing resource bytes does not update CamRoot's stored hash.

Document rules govern the manifest/UI graph. EVM profile rules describe this repository's @cam/evm-viem adapter; UI resolution describes @cam/screen. Viewer policies describe the @cam/viewer session library and the web viewer that uses it. Conformance checks inspect supplied bundles for publication defects, without establishing live state, account authority, or transaction success.

Security and trust boundaries

Start with a trusted choice of chain, host address, and RPC transport. The chain check compares the RPC's reported chain ID; it does not authenticate that network independently. The bootstrap checks establish that the exact manifest bytes match the SHA-256 digest returned by the selected host. That manifest commits to the protocol, ABI, and UI resource digests, so verifying each resource extends the same integrity check to its exact bytes.

An agent can automate these checks headlessly and inspect resolved calls independently of the publisher's frontend and its displayed claims. Compatible viewers can perform the same checks: SHA-256 provides the same integrity evidence to either consumer. Both paths depend on a trusted verifier: a malicious frontend or agent tool can claim checks passed without performing them.

Authenticated content can still describe a malicious or buggy workflow, and committed UI text can mislead. Hash verification does not establish that the selected host is trustworthy or that an ABI matches deployed code. Address bindings are outside the manifest commitment and may change separately; the manifest commitment itself can also be updated. See binding lifetime and viewer lookup policy.

The viewer can also display content whose hash is unchecked or mismatched, as described in its integrity warning behavior. In that case, displaying the workflow does not establish its authenticity. If the manifest is unauthenticated, matching hashes for its declared resources do not restore the connection to the host's commitment: those declarations came from the same unauthenticated manifest.

Labels, descriptions, and protocol reference text are application-supplied content. Agents must keep that content within the user's delegated task: a matching hash does not authorize overriding user instructions, exposing secrets, or granting network access or signing permission. Resource-fetch admission remains the caller's policy; apply the URI and loader policies before fetching advertised resources.

Before authorizing a transaction, the signer or its delegated policy must verify the actual destination, calldata, native value, and chain against the intended action. A route declaration or UI label grants no authority to spend or sign. Called contracts enforce their business rules onchain; integrity checks and simulation do not establish that a transaction is safe or will succeed.

Bootstrap an unfamiliar application

An agent can discover an application through RPC and authenticated resource bytes, then interpret its workflow headlessly. A browser or web frontend is unnecessary. Discovery needs no viewing account or draft task inputs; executing the selected entry read may require user inputs declared by that route.

Human discovery

A person can find an application through its publisher, a shared link, or a directory. That initial lookup supplies the chain and host address outside CAM; CAM discovery starts from that host and reveals its published workflow. A compatible viewer receives the selected chain and host through a viewer link or supported manual inputs. RPC access is configured separately or supplied through supported viewer launch parameters; CAM defines no universal viewer-link syntax or directory registry.

The viewer performs the discovery and resource checks below on the person's behalf and presents the discovered workflow, including when integrity warnings apply. A viewer may also request a viewing address to run account-dependent reads; this repository's web viewer requires one at startup. A viewing address does not require a connected wallet: discovery and reads can proceed without wallet signing, while submitting a transaction requires a signer.

Deployment-specific handoff

A trusted initial handoff supplies the selected chain identifier, an RPC transport for that chain, and the CAM host contract address. A chain identifier does not locate an RPC endpoint. The caller also supplies resource-fetch admission: permitted transports and origins, redirect policy, byte limits, and timeouts. An advertised URI or matching digest does not grant network access. The selected chain identifier matches eip155:[1-9][0-9]*, with a number no greater than 9,007,199,254,740,991.

Application-independent bootstrap rules

The agent knows the following host ABI, interface ID, minimal manifest protocol declaration and its URI/integrity rules, and authentication sequence before discovery. These fixed rules let it authenticate the advertised protocol instructions; they must not first be learned from that unauthenticated resource. The same rules apply across applications.

function supportsInterface(bytes4 interfaceId) external view returns (bool);
struct ManifestRef { string uri; bytes32 sha256Digest; }
function camManifest() external view returns (ManifestRef memory);
function contractAddress(string contractName) external view returns (address);

The ICamApp interface ID 0xb6a5fc7c is the XOR of the selectors for camManifest() and contractAddress(string); it excludes inherited ERC-165. The ABI output of camManifest() is one tuple whose components are string uri and bytes32 sha256Digest. The shared type permits every bytes32 value, including zero, and reserves no sentinel. The pair is coherent within the getter call; subsequent binding reads and route execution are separate operations.

The sequence below authenticates a bundle. The EVM adapter's default loaders follow this strict behavior, including comparing a zero digest. The repository's viewer uses the separate warning behavior described under Viewer integrity warnings.

1. Check that the RPC client is on the selected chain, then call supportsInterface(0xb6a5fc7c) on the host. Require boolean true; a failed read or any other return value blocks loading.
2. Read camManifest() from that host. Validate the returned URI against the resource profile and the caller's fetch admission, load bounded bytes, and compare SHA-256 of those exact bytes with sha256Digest. A mismatch blocks parsing.
3. Decode the authenticated manifest as strict JSON, rejecting invalid UTF-8 and duplicate object keys. CAM 1.3 requires a top-level protocol object with exactly uri and integrity fields, for example protocol: {"uri": "./protocol.html", "integrity": "sha256:0x…"}. The integrity string is the literal prefix sha256:0x followed by 64 lowercase hexadecimal digest digits.
4. Resolve protocol.uri: ./… is relative to the original manifest URI's directory, dropping its query and fragment; supported ipfs://CID/… uses an admitted IPFS transport. Apply the resource profile and caller's admission before fetching bounded bytes. Compare SHA-256 of the exact protocol bytes with the digest in protocol.integrity, and stop on mismatch.
5. Read the authenticated protocol document to learn how to validate the manifest graph, load and authenticate declared ABI/UI resources, resolve address bindings, and proceed to workflow execution.

Resolve and verify a bundle

The bootstrap sequence uses the URI and loader policies below. ABI and UI declarations use the same integrity spelling and exact-byte verification as the protocol resource.

The repository publishes this versioned reference at docs/reference/cam/1.3.0/index.html and copies those exact bytes into bundles declaring CAM 1.3.0 as protocol.html. The manifest pins the bundled copy. Refresh publication digests after editing resources; serve the protocol file alongside the manifest, ABI and UI files.

Current URI policy: the EVM adapter rejects data: URIs and raw JSON strings before calling the supplied loader. Replacing that callback does not bypass the URI gate. For permitted URI keys, the callback can return fetched, cached, in-memory, or contract-derived bytes. URI acceptance does not require physical external storage or provide a transport; the shared HTTP loader performs a network fetch.

Supported IPFS forms are CIDv0 base58btc or lowercase CIDv1 base32 with raw or dag-pb codec; both require a SHA-256 multihash with a 32-byte digest. IPFS manifest and resource URIs share the path restrictions above; bare ipfs://CID is allowed, while credentials, trailing slashes, queries, and fragments are rejected. Accepting an IPFS URI does not provide a transport.

Relative resources resolve from the directory of the original manifest URI, dropping its query and fragment. For example, https://example.org/app/main.json?rev=2#section plus ./ui/main.json resolves to https://example.org/app/ui/main.json.

Loader policy: the shared HTTP loader pins an allowed origin, rejects redirects, and bounds decoded responses to 2 MiB inclusive. The adapter also checks returned byte size. Custom loaders own their transport, access, and timeout policies; URI resolution is not an access grant.

Viewer integrity warnings

The repository's generic viewer keeps the UI available when a manifest, protocol, ABI, or UI resource has a hash mismatch or a declared all-zero digest. For a nonzero digest, it compares SHA-256 of the downloaded bytes with the declared digest. A mismatch produces a prominent warning identifying the affected resource and the expected and actual digests. The viewer continues using those bytes; the resource has not passed integrity verification.

An all-zero digest makes the viewer skip that resource's digest comparison and show a milder warning that its integrity is unchecked. This is viewer behavior, not a sentinel defined by ManifestRef or a relaxation of the integrity string format. These warnings remain visible while using the loaded application. Matching child-resource hashes do not authenticate an unchecked or mismatched manifest.

Continuing after an integrity warning does not bypass URI admission, response limits, strict JSON parsing, document validation, ABI validation, or wallet review. Invalid or unavailable resources can still prevent the UI from loading. Warnings do not authorize signing: inspect the actual transaction destination, calldata, native value, and chain before submission. Standalone EVM loaders remain strict by default, and publication and release checks still require matching resource digests.

Address bindings and their lifetime

A contracts.Registry namespace resolves through contractAddress("Registry"), using the bare suffix. Nonstring, invalid, and zero addresses are rejected. Bindings may change independently of the manifest commitment. The manifest URI/digest pair is atomic; bindings and later execution do not share a frozen block snapshot.

Viewer session policy: the repository's viewer session resolves bindings and ABIs at load and reuses them during navigation and preparation. A prepared write carries the resolved destination; simulation and submission use that destination without rereading the mapping. Later binding updates do not retarget that call. Reloading the session resolves bindings again. Other agents and viewers choose their lookup policy.

Interpret the manifest graph

The CAM 1.3 top-level manifest has exactly cam, protocol, entry, namespaces, and routes. Its cam value is "1.3.0". entry names an existing route. Unknown structural fields are rejected at the manifest, namespace, route, and invocation boundaries so unsupported declarations fail instead of being silently ignored.

Invocations have exactly {"namespace":"…","function":"…","args":{…}}, except that a write with resolve must add target to its final call. The namespace must be declared with an allowed type for that edge. In CAM routes, function is a nonempty literal string; argument values may contain expressions recursively. Route names and invocation argument keys need only be nonempty strings, unlike input identifiers.

A route has kind, inputs, call, and then. inputs is its exact callable interface: an array of unique names matching the expression identifier grammar. Resolving either invocation rejects missing or extra inputs, including unused inputs. This catches mismatched caller parameters before the call is made.

The namespace joins in this table are manifest-parser rules for route.call and route.then. ABI mutability is checked separately by the EVM adapter against the loaded ABI. Parsing the manifest alone does not inspect an ABI or deployed code.

then is the continuation descriptor. During a read, the repository's viewer session starts the call with empty outputs, then resolves then.args against the normalized results. The author selects which $outputs values reach the UI node. For static writes, the session resolves both descriptors with empty outputs. A resolved write supplies its read outputs only while resolving the final target and call arguments; its continuation still resolves with empty outputs. The @cam/core route helpers instead resolve the context supplied by their caller.

Read-route then.args and resolved write call.args may select $outputs. Resolver arguments, static call.args, route.value, and write-route then.args cannot use them. Conformance checks diagnose references at unavailable phases; accepting expression syntax alone does not establish that a reference can resolve.

Document parsing and conformance permit a write-to-write continuation. The viewer session does not reject that destination during first-write preparation. If the first transaction succeeds, the web viewer then requests navigation, which rejects the next write route; the web viewer reports transaction success with a view-refresh failure. That failure does not roll back the first transaction. Supporting another write requires an agent or viewer to prepare and authorize it; no declaration automatically submits a second transaction.

Bind EVM calls and results

The EVM adapter matches the resolved contract invocation against the loaded ABI. Its integrity status follows the loader's integrity behavior. A bare function name must be unique; a full signature selects an overload. Signature matching uses the supplied ABI's type spellings without whitespace, expands tuple components as (uint256,address), and retains array suffixes. It does not rewrite supplied uint to uint256 during matching.

Arguments must have exactly the ABI input names, which must be unique and nonempty. The adapter orders them by the ABI and validates values recursively. Decimal strings preserve large integers; accepted numeric inputs are limited to safe integers.

The entire ABI resource is validated, including unused functions. Unsupported parameter types, malformed function declarations, duplicate signatures, and unnamed or duplicate tuple component names reject the ABI. Tuple names are required for both inputs and outputs. Top-level outputs may be unnamed because their positions identify them. Nonfunction entries receive only object/type validation.

Read caller and outputs

A read route must target a view or pure function. A supplied account.address is also the RPC caller, independently of whether any expression references it. Caller-dependent reads may therefore differ across accounts. Without an account, the adapter leaves the caller unspecified. These reads require no wallet signature.

The result is always an outer positional list: no ABI outputs gives []; one output gives [value], even when value is itself an array or tuple. Integers become canonical decimal strings, addresses become lowercase strings, bytes retain hex letter case, and tuples become named objects. Counts, shapes, and ranges that disagree with the ABI are rejected. Use $outputs.0 or $outputs.0.component, not top-level ABI output names.

Native transaction value

Write routes may declare value, separate from call.args. It resolves as a literal or expression to a decimal uint256 value in native base units. Payable targets require an explicit value, including "0", so omitting an amount cannot silently default to zero. Nonpayable targets reject any declared value, including zero. Read routes reject the field.

No unit conversion or token transfer is implied. An amount passed as an ABI argument remains an argument; transferring tokens remains a contract operation. Writes have no modeled ABI return values in route context.

Resolve a write destination

A write route may declare one resolve invocation when its destination belongs to a particular record. For example, a registry can retain an older NFT collection address for an existing record while binding a newer collection for future registrations. Resolving the record's collection prepares a direct NFT transfer to the correct contract.

resolve has exactly namespace, function, and args. Its namespace is a declared, static contract namespace resolved through the host binding. Its function is a literal name or signature for a view or pure ABI function. Arguments can use the route's inputs, host, and account; they cannot refer to prior outputs. The resolver has no target override, nested resolver, list of invocations, or continuation.

The final call retains its own static contract namespace and function. That namespace supplies the loaded ABI. Its required target is exactly "$outputs.N", where N is one positional resolver output index. The selected ABI output must be scalar address, and its returned value must be a valid nonzero address. Literal addresses, editable-input references, tuple fields, arrays, and address-looking strings with another ABI type cannot select the destination. A target without resolve is invalid.

Normalize the resolver result against its ABI before resolving call.args. Those arguments can select other resolver outputs and must satisfy the final function's ABI inputs. Resolver outputs are available only to call.target and call.args. Neither the route's native value nor then.args can use them. The write itself still supplies no modeled outputs.

Conformance limit: the publication checker compares complete direct output arguments using exact ABI type-string equality. It does not infer safe conversions or compare tuple components. Outputs nested inside constructed arguments and concrete resolved values remain checked against the final function's ABI at runtime.

The route below assumes a host-bound Registry whose tokenReference(string serialNumber) returns (address collection, uint256 tokenId), and a Collection namespace declaring the ERC-721 transfer ABI. Both namespaces must be declared and bound at load. The collection binding supplies the ABI namespace's ordinary address; this write replaces that destination with the record's returned collection.

"transferComponent": {
  "kind": "write",
  "inputs": ["serialNumber", "to"],
  "resolve": {
    "namespace": "contracts.Registry", "function": "tokenReference",
    "args": { "serialNumber": "$inputs.serialNumber" }
  },
  "call": {
    "namespace": "contracts.Collection", "target": "$outputs.0",
    "function": "safeTransferFrom(address,address,uint256)",
    "args": {
      "from": "$account.address", "to": "$inputs.to", "tokenId": "$outputs.1"
    }
  },
  "then": {
    "namespace": "routes", "function": "component",
    "args": { "serialNumber": "$inputs.serialNumber" }
  }
}

Preparation and review: the repository's viewer runs the resolver once when the action is requested, then captures the destination, selected function, arguments, native value, and continuation in the prepared call. Simulation and submission consume that call without rerunning the resolver or substituting the current namespace binding. An account or view change while resolution is pending invalidates its result. A failed read, invalid result, or invalid target blocks preparation; there is no fallback to the namespace's configured address.

Trust boundary: a host-bound resolver is the declared source of the destination, not proof that the destination's code implements the ABI or that the action is authorized. Review the actual prepared address and calldata. The resolver read, simulation, and transaction execute at different times; freezing the prepared call does not freeze chain state or guarantee transaction success.

Resolve expressions and handoffs

Expression strings select supplied context values. They occupy the whole string and resolve recursively within argument arrays and objects, without changing keys. A single leading $ starts a reference; $$ escapes one dollar sign. Other strings remain literal. There is no arithmetic, interpolation, operator-object DSL, JavaScript evaluation, or resource fetch in this mechanism.

reference  = "$" identifier ("." segment)*
identifier = [A-Za-z][A-Za-z0-9_]*
segment    = identifier | arrayIndex
arrayIndex = "0" | [1-9][0-9]*  (at most 9,007,199,254,740,991)

Indexes are canonical nonnegative decimals. Brackets, empty segments, minus signs, and leading-zero indexes are invalid. Arrays are selected by index and objects by own fields. Missing roots or segments fail resolution; an existing null leaf is valid, but traversal through null fails. A selected string is not reinterpreted as another expression.

Resolved values are inert: JSON scalars with finite numbers, arrays, and plain objects. Undefined, functions, bigint values, and cycles are rejected. EVM integer outputs have already become decimal strings.

"$inputs.itemId"    → the supplied value, preserving its type
"$outputs.0.name"   → a named field in the first result
"$$inputs.itemId"   → the literal "$inputs.itemId"
"ID: $inputs.id"    → literal text, without interpolation

Do not manufacture write outputs from events, receipts, or simulation results.

Interpret UI 1.0.0

The UI resource is another declared graph, joined to routes by named node invocations. The repository's UI runtime resolves a selected node into a structured interface tree with action descriptions. An agent can inspect that tree without drawing it, and a viewer can render it; read continuations still target the UI namespace.

The document has exactly ui: "1.0.0" and a nonempty nodes object. Node names are nonempty strings. Named nodes declare requires as [] or ["view"], and receive exactly those argument names. Inline children cannot declare requires. A supplied view becomes $view during resolution; it is the handoff value, not the UI tree. Node arguments cannot shadow runtime roots.

Elements have closed structures and props. String props may contain references but must resolve to strings. There are no arbitrary HTML, style, script, or event-handler fields.

Nft may declare string props.metadataURI, usually supplied by a contract read through $view. It does not infer ERC-721 versus ERC-1155 or make another contract call. Loading a preview in the web viewer loads metadata and then its image, without a second action. The metadata editor displays embedded image data URIs automatically; fetching an external draft image requires a user action. It accepts HTTP(S) and data URIs, with limits of 256 KiB for UTF-8 JSON and 4 MiB for PNG, JPEG, WebP or GIF bytes. Other schemes need a directly readable HTTP(S) URL. Browser CORS failures remain local preview errors. These requests are separate from contract-anchored CAM resource loading.

NftMetadataField binds one URI passed to a route. The web viewer offers Hosted JSON and Embed JSON tabs, with separate local URI and JSON drafts. Tabs preserve the selected URI; each source has an explicit Use action. The selected URI is shown under URI to submit. Editing preserves extension fields and attribute values. Copying or downloading does not select, publish or mint anything. Embedded JSON uses a data URI and increases transaction size; external image URLs remain separate references. Editing an applied embedded draft clears its generated URI until reapplication. JSON edits leave a selected hosted URI unchanged; editing the selected hosted URI clears that selection until reapplication.

Status with stringList requires an array of strings. bytes/durationSeconds/timestampSeconds require unsigned decimal integer strings or safe nonnegative integer numbers. Unformatted value presentation belongs to the viewer. Timestamps display UTC and exact Unix seconds; integers beyond the UTC calendar range retain their exact seconds with an explicit range message. Zero means the Unix epoch unless the app declares a nonempty string zeroText; the renderer never infers absence from a field name. Timestamp formatting does not determine transaction readiness.

Publication policy: conformance follows statically known reference types through route/UI handoffs. For Nft.tokenId, known references must supply an integer or string; boolean, tuple, or array references receive a diagnostic. This check does not restrict literals at that site. The UI runtime accepts any inert token ID, with no contract call implied.

DurationField edits four whole-number parts: Days, Hours, Minutes, Seconds. The canonical value is their exact weighted sum in seconds (86,400, 3,600, 60, 1). Parts are not normalized during editing: 90 seconds stays as entered. All blank means unavailable (null); once any part is entered, other blank parts count as zero. Invalid or composing parts make the whole value unavailable. Defaults and agent state patches use canonical seconds, decomposed into parts. Inclusive min/max bounds apply to the total seconds. The repository’s viewers retain compatible part drafts on Back/Refresh and revalidate them against current bounds.

Includes and route actions

An Include invokes ui; its function resolves to one node name or an ordered array of distinct names. Empty arrays include nothing. Targets must exist, receive their exact required arguments, and form no Include cycle. Selected nodes share runtime/state and replace the Include in selection order. A Button invokes routes; its function resolves to one nonempty route name and its arguments supply that route's inputs.

State initialization and current resolution

Fields declare state.key and state.defaultValue as expression-capable values. The key resolves to an expression identifier, the default to a string. Duration defaults use whole seconds. Use the UI runtime's initial resolution when constructing a new view's field state: that operation collects defaults into empty state, then resolves the UI and actions. Duplicate keys reject initialization even if defaults agree. Defaults and Includes selecting fields cannot depend on editable $state; Includes selecting only actions may use state once initialized.

Use current resolution to resolve the interface again with state supplied by the agent or viewer, such as an edited draft. This UI operation does not merge defaults, prune old keys, or initialize newly selected fields. Draft editing alone does not submit a transaction or change contract storage. The repository's viewer session starts fresh state for ordinary route navigation; Back may restore compatible saved drafts after rereading the prior route. Other agents and viewers choose persistence, account-change, focus, wallet, and confirmation behavior; UI JSON has no fields that prescribe these policies.

Typed drafts

Numeric fields expose canonical decimal strings for valid drafts, including "0". Empty, incomplete, invalid, or input-method-composing drafts expose null. Editing is bounded to 2,048 UTF-16 code units and 1,024 canonical significant digits (for durations, per part and for the weighted total); these limits do not replace ABI ranges or business constraints.

For every numeric field, state.defaultValue must resolve to a digit string or an empty string. An AmountField default always uses base units, regardless of its interactive editing mode. With unit.decimals: 2, default "125" initializes canonical state "125", corresponding to display value 1.25. Default "1.25" is invalid and rejects initialization. A user may instead type "1.25" during display-unit editing, which produces canonical state "125". Empty defaults initialize null; invalid or out-of-bounds defaults reject initialization rather than becoming null.

Integer/base-unit editing permits only ASCII digits; leading zeros are removed canonically. Integer bounds resolve with empty editable state to nonnegative decimal strings, are inclusive, and require min ≤ max when both are supplied. There is no implicit uint256 editor maximum. Display amount editing additionally permits one decimal point: .5 and 1. can be valid, while . is incomplete. Signs, whitespace, separators, hexadecimal notation, and exponents are invalid.

AmountField.props.unit contains exactly the literal nonempty strings assetId, baseLabel, displayLabel, and integer decimals from 0 to 255. Scaling is exact: excess fractional precision is accepted only for zero digits, without rounding. The unit declaration does not verify an asset or authorize spending.

DocumentHashField declares algorithm sha256, a state binding, and optional sourceURI. On request, the repository's web viewer can calculate a 0x-prefixed 32-byte digest from selected file bytes or bytes fetched from that URI. Resolving the UI node itself does not fetch or hash a document. Manual/default strings are not digest-validated by the UI runtime; the receiving ABI or contract owns acceptance. This requested calculation is separate from ABI/UI resource integrity checking.

Availability

"enabledWhen": {
  "member": "edit",
  "in": "$view.availableActions"
}

Only Buttons and fields accept enabledWhen. It has exactly a nonempty literal member and in, either a reference resolving to an array of nonempty strings or a literal such array. Membership is case-sensitive; absence disables but retains the control. Disabled controls still resolve props, arguments, and defaults. This is not an authorization check.

Literal membership strings reject single-dollar references and do not unescape doubled dollars: "$$edit" compares with those two dollar signs.

Execute and report outcomes

The repository's viewer session starts a read with the selected CAM host contract identity, optional account, exact inputs, and empty outputs. Through the core and EVM helpers, the session resolves and ABI-checks the call, requests RPC execution without committed transaction effects, normalizes the result, then resolves then.args with those outputs. Failed calls and invalid results cannot produce an ordinary successful UI view.

The session's write preparation either resolves a static call with empty outputs or runs the declared resolver and resolves the final call from its normalized outputs. The continuation always resolves with empty outputs. The prepared call captures the destination and arguments for review; simulation and submission do not rerun resolution. An agent or viewer may request simulation as an RPC trial against current node state, without committed effects. Wallet submission returns a transaction hash; successful included execution can apply contract changes. Reverted execution does not apply the attempted contract changes. Neither a simulation nor a hash establishes successful confirmation.

The repository's web viewer waits for a successful receipt, then requests session navigation to the route named by the prepared write continuation. Successful read navigation refreshes the UI. The web viewer reports a rejected write-route destination or failed refresh separately from the already successful transaction; that UI failure does not roll back transaction effects.

Agents and viewers choose confirmation, timeout, replacement, reorg, and stale-interaction policy. An application also decides when an account change requires rereading caller-dependent results and whether drafts or prepared calls remain usable. CAM does not prescribe confirmation or wallet policies. The repository viewer rejects in-flight resolved-write preparations after an account or view change. A timeout or uncertain submission is not proof of failure; resolve wallet/chain status before retrying a consequential write.

Worked route and UI example

The first code block is a partial manifest containing only namespaces and routes. A complete manifest also supplies cam: "1.3.0", the authenticated protocol: {uri, integrity} declaration, and entry: "show" selecting the route used here; see the manifest graph rules.

Assume a CamRoot host binds Registry with labelOf(uint256 itemId) view returns (string) and setLabel(uint256 itemId, string label) nonpayable. The manifest joins that ABI to an editor UI and routes show/save. The registry contract owns edit authorization.

The digests below match the exact UTF-8 text in the resource code blocks, without an added trailing newline. Changed resource whitespace requires new digests.

{
  "namespaces": {
    "contracts.Registry": {
      "type": "contract", "abiURI": "./abi/Registry.json",
      "integrity": "sha256:0xe11b67b27adf4e4ff5a34bb0b2c91afcc61cfae6a90aa33223e3d954063dc8e3"
    },
    "routes": { "type": "routes" },
    "ui": {
      "type": "ui", "uri": "./ui/main.json",
      "integrity": "sha256:0x78d72558471330294d9bccf3d53a7f3f1e66a83fde3fa4c7665e43374f7c2da1"
    }
  },
  "routes": {
    "show": {
      "kind": "read", "inputs": ["itemId"],
      "call": {
        "namespace": "contracts.Registry", "function": "labelOf",
        "args": { "itemId": "$inputs.itemId" }
      },
      "then": {
        "namespace": "ui", "function": "Editor",
        "args": { "view": { "itemId": "$inputs.itemId", "label": "$outputs.0" } }
      }
    },
    "save": {
      "kind": "write", "inputs": ["itemId", "label"],
      "call": {
        "namespace": "contracts.Registry", "function": "setLabel",
        "args": { "itemId": "$inputs.itemId", "label": "$inputs.label" }
      },
      "then": {
        "namespace": "routes", "function": "show",
        "args": { "itemId": "$inputs.itemId" }
      }
    }
  }
}

show requires {"itemId":"7"} or another explicit item ID. An entry invocation does not invent inputs; an agent or viewer starting an entry without inputs needs a separate input-free entry design.

{
  "ui": "1.0.0",
  "nodes": {
    "Editor": {
      "requires": ["view"], "element": "Screen",
      "props": { "title": "Edit label" },
      "children": [
        {
          "element": "TextField", "props": { "label": "Label" },
          "state": { "key": "labelDraft", "defaultValue": "$view.label" }
        },
        {
          "element": "Button", "props": { "label": "Save" },
          "call": {
            "namespace": "routes", "function": "save",
            "args": { "itemId": "$view.itemId", "label": "$state.labelDraft" }
          }
        }
      ]
    }
  }
}

Registry ABI

[
  {
    "type": "function", "name": "labelOf", "stateMutability": "view",
    "inputs": [{ "name": "itemId", "type": "uint256" }],
    "outputs": [{ "name": "", "type": "string" }]
  },
  {
    "type": "function", "name": "setLabel", "stateMutability": "nonpayable",
    "inputs": [{ "name": "itemId", "type": "uint256" }, { "name": "label", "type": "string" }],
    "outputs": []
  }
]

The agent or viewer requests labelOf(7), obtaining one normalized string at $outputs.0. The continuation constructs view: {itemId, label} for Editor. Initial UI resolution sets labelDraft from that label; editing changes only the draft. Invoking Save captures itemId and labelDraft, prepares the nonpayable setLabel call without native value, and prepares show as its next route.

After successful submission and confirmation, the repository's web viewer requests show again and resolves the updated interface. These examples establish document and handoff shapes, not a deployment or live transaction.

Evidence and limits

This experimental revision documents CAM 1.3.0 with UI 1.0.0. The source links below follow the main branch and may change; the manifest integrity field authenticates the exact bundled reference bytes.

• ICamApp contract interface and CamRoot host and bindings.
• Wire versions, CAM parser, and core route and parser tests.
• URI, integrity, and resource bounds, expression grammar and resolution, and protocol tests.
• Loading from a CAM host contract, read/result conversion, write submission, and EVM tests.
• UI parser, UI resolution and state, and UI tests.
• Viewer write preparation and web viewer lifecycle.

The examples and repository tests do not establish interoperability with independently implemented agents or viewers.