Axiom Comparison Matrix

What Axiom adds beyond existing languages.

Axiom is not trying to replace Python, TypeScript, Rust, SQL, React, or policy engines. It sits above them as a contract and enforcement layer for intent, capability, policy, sensitive disclosure, approval, brokered execution, audit, and deployment constraints.

Intent Product purpose becomes executable structure, not a comment or README promise.
Authority Agents receive narrow capabilities instead of ambient access to app internals.
Policy Allow, deny, and approval decisions are deterministic software, not model judgment.
Audit Sensitive actions produce semantic traces without logging raw secrets.
Practical position: Axiom should be built as a layer, not a replacement. The ordinary stack can remain FastAPI, Pydantic, SQLAlchemy, Next.js, TypeScript, pytest, Docker, or equivalent tools. Axiom defines the current capability contracts, policy simulation, generated route gates, approval checks, policy artifacts, audit obligations, and generated tests above that stack.

At A Glance

Axiom Is

  • A readable contract layer above normal application frameworks.
  • A capability, policy, approval, broker, and audit contract language.
  • A way to keep AI-assisted apps from silently expanding their own authority.
  • A current generator for TypeScript and Python policy artifacts, route skeletons, approval checks, audit contracts, and tests.

Axiom Is Not

  • Not a replacement for Python, TypeScript, Rust, SQL, React, or browsers.
  • Not JSON/YAML with grander naming.
  • Not a magical zero-day shield.
  • Not a way to make LLMs obey prompts.
  • Not useful for every simple app or static site.

Capability Matrix

Capability Python TypeScript Rust Rego / OPA Workflow Engines Axiom
Express product intent as executable structure LowUsually comments or docs. LowTypes do not encode purpose. LowCorrectness focus, not intent. LowPolicy only. MediumWorkflow intent is present but narrow. NativeIntent is part of the source graph.
Model actors as trusted or untrusted entities Manual Manual Manual Medium Manual NativeActors carry trust posture.
Define sensitive data classes Manual MediumPossible with discipline. MediumPossible with type design. Medium Manual NativeData classes include sensitivity and disclosure rules.
Prevent broad retrieval by design Manual Manual Manual Partial Manual NativeGeneric retrieval can fail build checks.
Require brokered disclosure Manual Manual Manual Partial Manual NativeBroker contracts define what may decrypt and return.
Distinguish masked, summary, tokenized, and task-field outputs Manual Medium Medium Medium Manual Native
Bind approval to request hash, actor, destination, and expiry Manual Manual Manual Partial Medium NativeApproval is a scoped object, not a boolean.
Generate approval UI requirements None Manual None None None NativeUI must show security-critical context.
Generate audit event obligations Manual Manual Manual Partial Medium Native
Treat model output as non-authoritative for access decisions Discipline Discipline Discipline Medium Manual Native Rule
Compile to deployable app artifacts No No No No No IntendedSchemas, tests, policy manifests, UI contracts.
Generate policy matrix tests from capability specs No No No Partial No IntendedFirst useful Axiom Lite feature.

What Axiom Adds

Authority

Capability-first source

Agents request narrow named operations instead of broad access to app data or internals.

actor ExternalAgent
  trust authenticated_but_untrusted
  may request capability
  may_not retrieve raw records
Disclosure

Output modes as contracts

Sensitive outputs are classified as masked, summary, tokenized, task fields, denied, or pending approval.

disclosure:
  mode masked_value | task_fields
  forbidden raw_profile_export
Approval

Approval is bound and expiring

Approval is specific to the request, agent, destination, capability, and expiry window.

approval:
  one_time_default
  binds request_hash, agent_id,
        capability_key, destination_identity
Broker

Action without raw disclosure

The broker can use sensitive data while returning only the minimal allowed result.

broker TaxIdentityBroker
  may_decrypt tax.identity
  may_return task_fields
  forbidden raw_tax_payload
UI

Honest approval screens

Approval UI must show agent, capability, destination trust, data classes, disclosure mode, and expiry.

surface ApprovalCard
  displays agent_name, destination_trust,
           data_classes, disclosure_mode
Guardrail

Anti-drift build checks

The build can reject routes that quietly turn a capability broker into a secret export API.

invariant capability_not_retrieval
  forbid agent_route returns raw_sensitive_record
  forbid agent_route lists all_records

Open Source Shape

The first credible Axiom OS release should stay small and practical: a structured capability spec format, policy simulation, generated policy artifacts, route gates, approval checks, runnable tests, and tiny examples. A full framework compiler can come later.

The point is not to make a beautiful theory or longer prompts. The point is to put risky agent-proposed actions behind checks that ordinary app code can enforce.

Companion text version: comparison-matrix.md. Best first implementation target: capability specs and policy matrix tests for an agent-facing application.