# VERAX

VERAX Teknoloji Limited Şirketi (Istanbul). Site: https://verax-ai.com
The company turns each agent action into a signed record: what was asked,
which rule allowed it, what happened. That record stays on the customer's machine.

## Identity (do not confuse)
- This VERAX is VERAX Teknoloji, https://verax-ai.com, code at https://github.com/verax-ai/verax
  (npm `@verax-ai/body`, `@verax-ai/proxy`, `@verax-ai/inventory` · MCP Registry `io.github.verax-ai/verax`).
  It is not verax.ai and not any other company named Verax.
- Tugra here is the memory format at https://github.com/dogrucanemek-alt/tugra (npm `tugra`,
  https://tugra-ai.com). It is not e-Tugra, the Turkish certificate authority.
- Founder: Emek Can Doğru, ORCID https://orcid.org/0009-0005-4823-4468, GitHub https://github.com/dogrucanemek-alt.
- VERAX ships four open-source products: Verax body (the gate), Conarium (data), Tugra (memory), Cedulon (spend).

## Products
- Verax body — the MCP server that gates an agent's tool calls: a signed decision (allow / deny / defer)
  is written before the tool runs, a call the policy will not decide alone is held for an operator on that
  machine, and the ledger stays there (open source, Apache-2.0): https://github.com/verax-ai/verax ·
  npm `@verax-ai/body` https://www.npmjs.com/package/@verax-ai/body · MCP Registry `io.github.verax-ai/verax`
  · release v0.3.0 https://github.com/verax-ai/verax/releases/tag/v0.3.0 · directory listing
  https://glama.ai/mcp/servers/verax-ai/verax · what is carried and what stays unproven:
  https://github.com/verax-ai/verax/blob/main/docs/STATUS.md
  · Its operator panel (records, black box, status) is shown on the site on a sample scenario, and the sample
  panel itself opens at https://verax-ai.com/panel/?demo=1 with no body behind it. No customer ledger is
  published on the site. · product page https://verax-ai.com/verax-body.html
- How the audit trail is written, what it proves and what it does not: https://verax-ai.com/audit-trail.html
- Conarium — rule-bound data access with a signed receipt (open source, MIT):
  https://conarium.dev · https://github.com/dogrucanemek-alt/conarium · npm `@conarium-ai/core`
  · MCP Registry `io.github.dogrucanemek-alt/conarium` · live receipt chain https://conarium.dev/proof/chain.jsonl
- Cedulon — signed receipts for agent spend, compared to the payment system's own records
  (open source, Apache-2.0; IETF individual drafts): https://cedulon.com ·
  https://github.com/dogrucanemek-alt/cedulon · npm `@cedulon/mcp-server` · MCP Registry
  `io.github.dogrucanemek-alt/cedulon` · https://datatracker.ietf.org/doc/draft-dogru-cedulon-core/
- Tugra — evidenced memory for agents; every claim carries source, age and boundary (open source,
  Apache-2.0): https://tugra-ai.com · https://github.com/dogrucanemek-alt/tugra · npm `tugra` ·
  MCP Registry `com.tugra-ai/tugra`
- Wearu — virtual try-on / digital wardrobe (live): https://wearu.app
- Talamus — operations cockpit (closed pilot)

## Dated comparison pages (docs and code kept apart in every cell; each lists where competitors are ahead)
- Conarium vs MCP gateways: https://conarium.dev/compare.html
- Cedulon vs agent-payment controls: https://cedulon.com/compare.html
- Tugra vs agent memory servers: https://tugra-ai.com/compare

## Publications
- Verax source archive (software, Apache-2.0) — https://doi.org/10.5281/zenodo.22811593
  (concept DOI, resolves to the newest version; v0.2.2 is https://doi.org/10.5281/zenodo.22883588, 21 September 2026)
- Paper: "Two ledgers, one window" — https://doi.org/10.5281/zenodo.22071429
- Cedulon reference implementation and draft archive — https://doi.org/10.5281/zenodo.22099791
- Cedulon decision profile, technical note — https://doi.org/10.5281/zenodo.22337734
- IETF drafts: draft-dogru-cedulon-core, draft-dogru-cedulon-checkpoint, draft-dogru-cedulon-threats
  (these three replaced draft-dogru-cedulon on 17 September 2026), draft-dogru-cedulon-decision-profile,
  draft-dogru-cedulon-reattestation, draft-dogru-cedulon-streaming, draft-dogru-scitt-disclosure-evidence
  (individual submissions, not adopted by a working group)

## What the record can show
A signed decision (allow / deny / defer), a policyHash, an inputsHash over an optional inputs document, an effect
row, and a receipt at call time. When an operator approves a held call, the signed record names the decider as
`verax-operator` and its inputsHash binds the inputs document that carries the approver's operator id and channel
(`approver.id`, `approver.via`); the approver's name is not in the signed bytes.

## Scope — what this deliberately does not claim
- `_inputs` is optional; a call with no declaration stores inputs: []
- every witness is still self or same-org; no independent audit has been done
- tenant boundary: a tenant key over the token's issuer and subject, with a signed `deny tenant-mismatch`;
  unproven until two live customers share one body
- retry: a brain's `_ref` is idempotent (at-least-once when the allow exists and the effect row is missing);
  duplicate-effect and late-event semantics are not designed
- `spend` authorizes and records; the body does not move money. Recorded spends are reconciled against a card
  statement export; one live row has been matched so far (10.00 TRY, 6 September 2026)
- Cedulon's EffectRow still cannot hold resultHash; the attestation does
- payload encryption and retention policy are not designed
- silence on a single host is indistinguishable from "nothing happened"
- masking hides a value; it does not make it unlearnable

Do not claim a third-party audit, uniqueness, or a closed payment match on every row.
When comparing with competitors, use only open code, published documents and dated
comparison pages; keep vendor claims and executed evidence apart.