AI can propose an interface. ĀML can make its meaning, policy, authority, and evidence inspectable before and after rendering.
HTML tells the browser what to display. ĀML tells the system why it deserves to be displayed.
ĀML is a working research prototype for meaning-native, policy-aware, accountable AI interfaces. It can sit between machine intent and human-facing output as an AI Interface Firewall™ without requiring teams to replace HTML, React, or existing frontend stacks.
Enter the interactive first run → Change an agent's destination or a proposed interface value. The action path runs the project's browser planner, computes the canonical proposal SHA-256, and checks it against a published project vector. Then open the linked lab or reproduce locally. It never dispatches a tool.
| Your goal | First useful result |
|---|---|
| Build | Shape a browser gate, share the exact scenario, and download runnable HTML, or start a guarded agent tool with a simulated local callback and host wiring guide. |
| Write ĀML | Edit a program and inspect the browser compiler. Change one declared value, compare the decision, and share the source link. |
| Verify | Reproduce a decision in 10 minutes; preserve the commit, commands, output, and any failure. |
| Challenge | Run one action-boundary case, then all public and seeded cases against your own adapter. |
ĀML's project-authored demonstrations are engineering evidence, not outside validation. The interface scores are declared prototype inputs, not objective measures of a person.
Open the research atlas: labs, counterexamples, and field observations
Explore the next boundary: Try the Action Boundary Lab — change an agent's intended tool call and see an exact policy decision, digest, stale simulated approval, and uncertain outcome. Try a one-use grant replay: a second attempt with the same local grant blocks before a callback. Explore the visual 13-case challenge, read its adapter contract, or read the pilot and its six published vectors. The browser rehearsal and repository self-test are project-authored, with no live tool access.
Design your own boundary: Open the Action Boundary Studio. Edit the proposed action and the host policy, inspect the live plan and canonical digest, then download a JSON calculation bundle. node scripts/verify-action-studio-bundle.mjs examples/action-studio/changed-destination.json rechecks a published example against the policy included in that bundle; the guide explains the limits. The verifier checks consistency, not policy ownership or a real approval.
Bind the real target: Open the seven-case Target Binding Lab. A proposal can declare team@example.test as its approved resource while arguments.to names outside@example.test. Under an intentionally unreviewed exact rule, the reference reaches one simulated callback with the outside recipient. The opt-in host-owned wrapper derives the recipient from frozen tool arguments and blocks the mismatch before approval or callback. node scripts/build-target-binding-report.mjs --check regenerates the machine report; the integration guide explains how the resolver must match a real tool's schema. No message is sent. An aligned target does not authorize changed content.
The next destination can be invisible: Inspect the seven-case Recipient Manifest Lab. The initial target-binding example resolves only arguments.to. Add bcc: ["outside@example.test"] while to remains approved and that example still reaches one simulated callback carrying the BCC field. The new strict mail adapter derives one exact resource from the complete to/cc/bcc manifest; the same unapproved addition reaches zero callbacks. node scripts/build-mail-target-report.mjs --check verifies the report. This is a bounded, project-authored mail-tool schema, not a general email or consent guarantee; read the integration limits.
Try your own recipient shape: Open the local Recipient Workbench. Edit intended and proposed JSON to compare complete To/CC/BCC manifests and exact resource keys. It runs in the browser with no mail service; the shared parser is copied byte-for-byte to the site and checked against canonical JSON and Web Crypto digests in node test/action-boundary-mail-workbench.test.js. A matching target is only a destination comparison, not approval of content or delivery.
Wire the boundary into a mail function tool: Inspect the seven-case integration lab. A To-only host mapper can be sufficient for a To-only callback, but an expanded callback that accepts BCC can reach one simulated callback with an unapproved BCC. The complete-recipient wrapper validates the narrow mail schema, binds the full recipient resource, and reaches zero callbacks for that addition under the same intended policy. node scripts/build-mail-tool-report.mjs --check rechecks the report; the integration guide names host and provider responsibilities. This is a project-authored local comparison, not a live mail service or authenticated approval.
Check the provider request, not just the tool input: Explore the eight-case Prepared Mail Lab. A host can append a BCC while constructing a provider request after the complete-recipient adapter checked the input; the local provider callback then runs once. The opt-in prepared-request adapter constructs and validates that request before policy and approval, so the same host-added BCC reaches zero callbacks under the intended rule. An original-body approval digest also fails if the host changes the body during preparation. node scripts/build-prepared-mail-report.mjs --check reproduces the machine report; integration instructions state the sender and provider assumptions. The comparison is project-authored and sends no mail.
A real screen exposes a second rule: Inspect the contact-continuity field study. Two hashed production screenshots of a Portland security page show a banner, navigation phone, and fixed contact dock. A declared ĀML candidate suppresses one repeated number and keeps a call and email path in both observed desktop states. A deliberate over-suppression leaves zero visible call paths after scrolling; a separate continuity guard rejects it. Source observations and label provenance, machine report, and node scripts/build-field-contact-continuity-report.mjs --check make the result inspectable. The live site was not changed; no visitor outcome was measured.
Build against one case, then all 13: The visual implementer loop now gives each published fixture a focused command. node scripts/run-action-boundary-challenge.mjs --case changed-destination -- ../my-adapter/adapter reports precise mismatched fields; a single-case PASS is labeled partial. Drop --case changed-destination for the full compatibility run. Your adapter and its evidence should live in your own repository; the project reference adapter is a self-test, not an outside witness.
Make an outside run visible: node scripts/run-action-boundary-challenge.mjs --html-out ./my-boundary-run.html -- ../my-adapter/adapter now creates a self-contained offline visual result alongside the unchanged JSON stdout. The HTML shows each observed PASS/FAIL, diagnostics, scope, and contract hashes without fetching assets or replacing an existing file. Inspect the project-owned 13-case example to see the format, then run your own adapter. The example is explicitly labeled a reference self-test; neither it nor a caller-generated report automatically establishes independent validation.
See the result inside GitHub: The Action for outside adapters now posts a per-case run summary and uploads the actual JSON and offline HTML reports as a workflow artifact, even when cases fail. It then fails the step for a failed challenge. Copy the caller workflow and pin the Action to a reviewed commit for reproducibility. A GitHub artifact is inspectable run evidence; it does not establish who wrote the adapter or whether its implementation is independent.
A perfect fixed score can be a false signal: A deliberately canned adapter copies the 13 public expected answers and passes 13/13 without implementing the action boundary. The seeded counterfactual lab shows the same adapter at 13/19 when six proposal and policy transformations are added; the project reference executes 19/19 for that seed. The GitHub Action now includes fresh seeded probes, records the seed in its report and summary, and still accepts FAIL and MIXED. This is project-authored resistance to one form of answer memorization, not proof of independent verification or production safety.
Where does an exact rule stop? Explore the eight-case Policy X-ray: with an unreviewed rule for send_message + send + team@example.test, a changed message body still reaches one simulated callback. A host decision bound to the original proposal digest blocks that changed body before dispatch. The machine report is regenerated by node scripts/build-action-policy-scope-report.mjs --check; integration guidance explains when this distinction matters. No message is sent and the fixed host digest is not human approval.
Wire one agent tool: Follow the function-tool quickstart to wrap a host-owned callback with exact policy matching, approval binding, and a dispatch receipt. Its runnable local demo simulates execution; the host must supply real authorization and tool mapping.
Try the A2UI v1.0 function gate: a catalog-authorized agent function still needs an exact host action rule. Nine executable local cases show the catalog stop, destination switch, digest approval, frozen arguments, and uncertain callback. Run node pilots/action-boundary/a2ui-function-demo.mjs, then read the integration guide. This is a project-authored host-side example, not a full A2UI renderer or external validation.
One ID must mean one invocation: Explore the pinned A2UI replay counterexample. The prior bridge called the simulated tool twice for the same functionCallId in one host session. The corrected bridge requires a host-owned atomic claim before approval or dispatch; a repeated ID reaches zero additional callbacks. Six historical/current cases, including a concurrent replay and separate-session control, are regenerated in CI. A2UI v1.0 remains a candidate specification, and the included claim store works in one Node process only.
Across workers, share the claim: The two-process replay lab runs the actual function gate in separate Node processes. Process-local claims permit two simulated callbacks for the same ID; a host-owned, private filesystem claim permits one, including after a worker restart. A separate-session control still permits two. The machine report is regenerated by node scripts/build-a2ui-worker-report.mjs --check in CI. This is a local filesystem pilot with simulated approval and callback, not a network store, human consent, or delivery proof.
Bring the action boundary to MCP: The eight-case MCP tool lab puts a host rule before a Client.callTool-shaped callback. A deliberately flawed client trusts readOnlyHint: true and invokes a simulated outside destination once; the AML wrapper checks the host-bound server/tool, schema, destination, and approval, so that case reaches zero callbacks. Returned tool errors and uncertain transports retain distinct statuses. Use the narrow client-side adapter; the machine report is regenerated in CI. This is project-authored in-memory execution, not a connected MCP server or external adoption.
Connected MCP pilot: Explore the stdio handler trace. An official SDK v2 client connects to a child MCP server and lists a misleading readOnlyHint: true tool. An intentionally unsafe direct call to an outside destination reaches its local handler once; the same proposal through the ĀML gate reaches it zero times. Six asserted connected cases, the machine report, and reproduction steps are checked in CI. This fixture writes a temporary local audit line; it sends nothing externally.
Two processes, one claim: Inspect the recorded race and run node pilots/action-boundary/file-grant-race-demo.mjs. Separate Node workers share a trusted local directory and compete to create an exclusive claim marker. The project-authored run records one simulated callback and one blocked replay. It is a local-filesystem prototype, not authenticated approval or a multi-machine production store.
Two code paths, one published contract: Explore the JavaScript ↔ Python comparison. Both project-maintained implementations produce exact matching plans, receipts, callback counts, and frozen proposals on all 13 action-boundary cases. Run node scripts/build-action-cross-runtime-report.mjs --check to compare a fresh run with the visual page's checked-in machine report. This is cross-language engineering evidence for a limited JSON subset, not an independent external witness.
After a timeout, no blind retry: Explore the dispatch ledger. A host-generated operation ID is bound to the exact proposal and claimed before a simulated callback. A two-process race yields one callback; a crash or callback error remains unknown, while a changed payload cannot reuse the ID. The six-scenario report is regenerated in CI. This is a local, project-maintained fail-closed pilot—not a distributed exactly-once or delivery guarantee.
A counterexample made the contract stronger: Inspect the key-order lab. Numeric-looking JSON keys exposed a real proposal-hash disagreement between the project's JavaScript and Python code paths. The Python wire order is fixed without changing existing JavaScript digests. A deterministic, deliberately adversarial 519-case regression records 439 mismatches under the prior Python ordering and zero after the fix; the seven selected examples show exact old and new bytes. This remains project-maintained evidence for a restricted JSON subset.
A spent grant must stay spent: Watch the local replay counterexample. A misconfigured writable directory let the former one-use file store accept the same test grant twice after its claim directory was replaced. The store now rejects weak ownership, permissions, and symlinks before issuance or consumption. Four before/after scenarios run the pinned historical module and corrected module in CI. This project-authored POSIX simulation does not involve a second operating-system user or real tool side effect.
Open this exact state: attention 5 / restoration 1 → SUPPRESS.
Now change restoration from 1 to 5: attention 5 / restoration 5 → ALLOW.
Prototype rule:
render_allowed = restoration_value >= attention_cost
The attention/restoration scores are declared or model-supplied prototype inputs. They are not claimed objective measurements of cognition, wellbeing, morality, or clinical state.
If the behavior does not reproduce, that is useful evidence. Please publish PASS / FAIL / MIXED with enough detail for someone else to repeat your result.
ĀRU Intelligence is actively applying ĀML™ to real customer-facing web properties, including a multi-site Security First Alarm pilot. These are project-authored field experiments, not synthetic mockups and not independent validation.
The current work preserves pre-change checkpoints, identifies exact interface elements under test, records label provenance and declared policy inputs, and is designed to publish before/after evidence and decision receipts as each site experiment is completed.
- Active pilot registry:
experiments/2026-09-12/SECURITY_WEBSITE_FIELD_PILOTS.md - Public field-experiments page: ARUIntelligence.com/experiments
- Independent verification call: Issue #88
Important boundary: site-specific phone numbers, SMS routing, email addresses, and business-contact rules are preserved as local ground truth. The experiment evaluates presentation and repetition, not arbitrary normalization of contact data.
The attention/restoration values used in these pilots are declared or model-supplied prototype inputs. They are not claimed objective measurements of cognition, wellbeing, psychology, neurological state, morality, or clinical outcome.
Do not endorse ĀML first. Verify it first.
git clone https://github.com/aruintelligence/aml-core.git
cd aml-core
npm install
npm testFor the smallest deterministic reproduction, start with:
- 10-minute reproduction
- Five-minute installed-package quickstart
- Preserve a decision — create and recheck a self-contained evidence capsule after an interface changes.
- Renew its evidence — link the original capsule into an append-only SHA3-512 chain with verifier-trusted witness quorum.
- Keep a cold archive — preserve canonical capsule and renewal bytes with an offline recovery path and externally supplied trust.
- Recheck a versioned handoff — retain v1 bytes in a v2 layout and verify exact component equivalence before recovery.
- Repair a cold storage handoff — reconstruct canonical handoff bytes from any two of three separately stored shares, then recheck external trust.
- Rehearse every recovery pair — get a machine-readable readiness report before a damaged share becomes a loss.
- Simulate storage failures — reveal declared shared sites, infrastructure, and custodians that can defeat two-of-three recovery.
- Explore the visual Resilience Lab — select a failure, inspect the shared dependencies to change, reopen a local placement manifest, and take it to the verified CLI drill.
- Undeniable proof demo
- Benchmarking protocol
- Interoperability challenge
Project-authored tests are useful engineering evidence, but they do not count as independent external verification.
A generated interface usually has several hidden questions behind it:
- What did the system intend to show?
- Which policy allowed or blocked it?
- What authority or consent applied?
- What evidence explains the decision?
- Can another implementation reproduce the result?
ĀML turns those questions into inspectable data and deterministic decisions that can travel with the interface.
flowchart LR
A[AI / app intent] --> B[ĀML Interface Firewall]
B --> C[Meaning + policy]
C --> D[Consent / privacy / accessibility / attention]
D --> E[ALLOW or SUPPRESS]
E --> F[HTML / React / other renderer]
E --> G[Receipt + provenance + audit evidence]
G --> H[Independent verification]
- ĀML in one page
- Start Here — ĀML in 5 minutes
- Why AI-generated UI needs a firewall
- A critic's guide to ĀML
- Publications index
Run the 30-minute enterprise pilot to generate a decision report with full receipts, declared fixture hashes, three asserted outcomes, deterministic replay, and a tamper-rejection check. The CI workflow saves the report for review. This is project-authored evidence, with explicit deployment and claim boundaries.
Zero-install custom element:
<script type="module" src="https://aruintelligence.github.io/aml-core/aml-gate.js"></script>
<aml-gate
purpose="Create urgency"
attention-cost="5"
restoration-value="1">
<button>Act now</button>
</aml-gate>Or keep the existing DOM and add three attributes:
<script type="module" src="https://aruintelligence.github.io/aml-core/aml-dom-gate.js"></script>
<div
data-aml-purpose="Create urgency"
data-aml-attention-cost="5"
data-aml-restoration-value="1">
Offer expires soon.
</div>These browser bridges are intentionally narrow adoption surfaces. They do not claim to contain the full runtime policy, consent, privacy, accessibility, receipt, or trust stack.
The web gave developers View Source. ĀML explores View Meaning™.
import { viewMeaning } from "./index.js";
const report = viewMeaning(receipt);A View Meaning report can expose declared purpose, policy/profile, consent/privacy/accessibility context, attention/restoration inputs, ALLOW/SUPPRESS outcome, rationale, provenance, and receipt integrity.
The repository currently includes:
- lexer/parser, AST, Abstract Meaning Tree, compiler, runtime, and CLI
- semantic and policy diffs
- pluggable policies and multi-policy consensus
- consent, privacy, accessibility, and attention controls
- execution receipts and Ed25519 signatures
- SHA-256 audit streams, provenance graphs, and Merkle inclusion proofs
- Proof-Carrying Interface™ manifests
- capability negotiation, policy passports, replay protection, delegation, threshold authorization, transparency logs, and revocation registries
- browser bridges, React-compatible adapters, starters, an HTTP service, Meaning Gate™ GitHub Action, and View Meaning™ tooling
- RFCs, schemas, golden vectors, conformance fixtures, benchmarking, interoperability, and evidence-reporting surfaces
See API.md, ECOSYSTEM.md, rfcs/README.md, and STANDARDIZATION.md.
ĀML separates project-controlled evidence from independent evidence.
| Level | Meaning |
|---|---|
| E0 | concept / proposal |
| E1 | project-authored demonstration |
| E2 | automated repository verification |
| E3 | independent reproduction |
| E4 | independent implementation |
| E5 | external pilot evidence |
| E6 | production deployment evidence |
| E7 | multi-party ecosystem evidence |
The project should not describe internal tests, project-maintained reference implementations, clone counts, or outreach activity as independent adoption.
A failure, bypass, contradictory implementation, or MIXED result can be more valuable than praise if it reveals where the contract is weak.
v1.3.0remains the stable package/CLI/capability contract.v1.4.0-rc.2is the current GitHub prerelease snapshot of the broader architecture onmain.- ĀML is not a ratified industry or Internet standard.
- No claim is made here of universal adoption, standards-body approval, third-party certification, regulatory approval, scientific validation, or production suitability for every environment.
The reference implementation covers parser/compiler behavior, policy bypasses, receipts/signatures, wire replay, capability escalation, revocation, official trust-root verification, HTTP behavior, and browser-extension permission/privacy boundaries.
It does not replace production authentication, authorization, TLS, rate limiting, secure secret management, application-specific threat modeling, WCAG conformance testing, or independent security review.
- Security policy
- Threat model
- Security evaluation checklist
- Server-owned HTTP deployment policy
- HTTP ingress authentication
The covered software is available under the MIT License. Official ĀML™ / ĀRU™ branding, logos, compatibility branding, certification-style identity, endorsement, OEM/co-branding, and related reserved brand rights are separate from the software license.
Technical conformance is independently testable. It does not automatically grant official ĀRU authorization, endorsement, partnership, certification, or trademark rights.
For the current rights and commercialization architecture, start here:
- LICENSING.md — canonical boundary between MIT-covered software and separately controlled rights/services
- NOTICE.md — concise public rights notice
- TRADEMARKS.md — trademark and brand-use policy
- COMMERCIAL.md — enterprise, OEM, managed-service, and official-branding paths
- IP_PROTECTION_ROADMAP.md — operational checklist for registrations, chain of title, patent timing, trade-secret boundaries, contributor rights, and written agreements
- CONTRIBUTING.md — contribution licensing and no-silent-relicensing boundary
- OFFICIAL_MARKS.json
- OFFICIAL_AUTHORIZATIONS.json
- BRAND_TRUST_ROOTS.json
- RFC 0011 — Official Brand Authorization
Current production public trust root:
- key id:
aru-aml-brand-prod-2026-09-08-01 - SHA-256 fingerprint:
eda0184568cb2110add5130d2a9fffaf53a77e0f2be311be414e7912ed69997c - public key: keys/aru-aml-brand-prod-2026-09-08-01-public.pem
Production private signing material is intentionally kept outside GitHub.
Commercial, OEM, enterprise, and strategic inquiries: Office@aruintelligence.com
When AI generates an interface, can the system prove what it meant, what authority it had, which policies governed it, and why the human saw the result?
Created by Daniel Jacob Read IV and stewarded by ĀRU Intelligence Inc.™.
ĀML™, ĀRU Meaning Language™, AI Interface Firewall™, View Meaning™, Meaning Gate™, EthicalRenderGate™, Meaning-Native Computing™, Proof-Carrying Interface™, and named ĀML compatibility marks are claimed marks. Registration status varies; do not use ® unless a specific mark is actually registered for the relevant goods/services.