Question 1

What if OpenAI or Anthropic adds verification?

Accepted Answer

It is entirely possible, and we would welcome it. Canon is a CC0 open standard — anyone can implement it, including the largest model providers. If Anthropic ships native attestation tomorrow, Canon artifacts remain interoperable because the standard does not depend on any single implementer.

The Meridian Mandate §3.1 (Implementation Neutrality) explicitly requires that “competing implementations are structurally on equal footing with NORA’s own.” This is not a defensive posture — it is the point. A verification standard that only one party implements is not a standard; it is a proprietary feature. Canon’s value comes from being the lingua franca across providers.

The real risk is not that a large provider adopts verification, but that they adopt a closed, proprietary version that locks recipients into a single trust authority. Canon exists precisely to prevent that outcome. If OpenAI or Anthropic builds on Canon, the ecosystem wins. If they build something incompatible, Canon’s independence becomes even more important.

Question 2

What if Ed25519 breaks?

Accepted Answer

This is a real cryptographic risk, and we take it seriously. Algorithm agility is designed into Canon from the start. Canon §versioning allows signature-algorithm rotation without invalidating prior attestations — each sealed artifact records the algorithm used, so verifiers apply the correct one.

The Meridian Mandate §4.2 (Cryptographic Continuity) specifies that the custody chain must support algorithm migration: new attestations can be sealed with a successor algorithm while old ones remain verifiable under the original. This is the same model TLS uses, and it has survived multiple algorithm transitions over three decades.

Practically, Ed25519 is widely regarded as secure for the foreseeable future. The more likely near-term threat is quantum computing, which would affect all elliptic-curve schemes. Canon’s architecture anticipates this: the hash-chain integrity is separate from the signature scheme, so even a signature break does not retroactively corrupt the custody record. When post-quantum primitives stabilize (ML-DSA is the current NIST candidate), Canon will add them as a supported algorithm family.

Question 3

What stops you from secretly mutating signed records?

Accepted Answer

Three structural guarantees, each independently verifiable. First, public keys are published to a verifier registry that any third party can query — NORA cannot silently swap keys without detection. Second, the custody chain is append-only and Merkle-linked: any mutation breaks the hash chain, and any verifier can detect the break by recomputing hashes from the artifact forward.

Third, and most importantly, the Meridian Mandate §2.3 (Falsifiability Without Cooperation) requires that verification never depend on the issuer’s cooperation. Independent verifiers — not controlled by NORA — can audit any artifact at any time using only the artifact itself and ordinary network access. The design makes silent tampering cryptographically detectable by parties who have no relationship with us.

We also publish our own verification infrastructure as open source, so anyone can inspect the code that seals and verifies attestations. The honest answer is that you should not trust us — you should trust the math. That is the entire architectural premise.

Question 4

Why should I trust NORA’s reference implementation?

Accepted Answer

You should not have to. That is precisely why the Canon standard is published CC0 and the verifier registry is open to independent operators. You can verify artifacts with third-party tooling that NORA does not control, build, or host.

The Meridian Mandate §3.1 (Implementation Neutrality) states: “Canon defines the artifact and the falsification protocol — not the internal operations of any stage. Competing implementations are structurally on equal footing with NORA’s own.” The reference implementation exists to bootstrap the ecosystem, not to gatekeep it. If our implementation has a bug, a third-party verifier will catch it — that is the point of structural independence.

We actively fund adversarial review of the reference implementation (Mandate §5.1, Adversarial Review Program). External reviewers are invited to find flaws, and every successful refutation is published. The strongest argument for trusting the implementation is that we pay people to try to break it and publish the results when they succeed.

Question 5

Is Canon actually independent or just marketing?

Accepted Answer

Canon is licensed CC0 — public domain, no strings. This is not a permissive license with attribution requirements or patent grants that could be revoked. It is an irrevocable dedication to the public domain. Anyone can fork, reimplement, or extend Canon without asking permission or paying fees.

Governance is structurally separated from NORA Foundation product decisions. The Meridian Mandate §6.1 (Governance Separation) requires that specification changes follow an open RFC process, not internal product roadmap decisions. The verifier registry accepts operators with no commercial relationship to NORA.

The concrete test is simple: could a competitor build a Canon-compliant product that directly competes with Meridian? Yes, and the standard is designed to make that easy. If Canon’s independence were marketing, we would have chosen a license with more control. We chose CC0 specifically to make the independence irrevocable. Read the license and governance provisions at /canon to verify this yourself.

Question 6

What happens to my archive if Meridian shuts down?

Accepted Answer

Your data remains yours. Meridian supports full data export at any time — this is not a goodwill feature but a structural requirement. The Meridian Mandate §7.1 (Data Sovereignty) specifies that user data must be exportable in standard formats without platform cooperation.

Canon artifacts are portable by design: they are self-contained, signed files that any conforming verifier can read. They do not phone home to Meridian servers. Even in a worst-case shutdown, every attestation you have sealed remains independently verifiable by anyone with the artifact and ordinary network access.

A self-hosted deployment option is on the roadmap (see /roadmap). The architecture — per-user Postgres databases, stateless API layer, portable Canon artifacts — is designed for exactly this scenario. We are also exploring escrow arrangements for the codebase to ensure continuity even if the foundation itself ceases operations.

Question 7

How do you prevent embedding leaks?

Accepted Answer

We acknowledge the risk directly: vector embeddings preserve enough semantic structure that an attacker with white-box access to the embedding model and a corpus snapshot can reconstruct fragments of the original text. We do not pretend this attack surface does not exist.

Meridian addresses this through three architectural decisions. First, per-user database isolation ensures embeddings never cross tenant boundaries — your vectors are stored in your database and nowhere else. Second, the embedding model runs local-by-default: your text never crosses the network at embedding time, eliminating the most common exfiltration vector. Third, embeddings are stored alongside their custody chain, so any unauthorized access produces an auditable, tamper-evident record.

The Meridian Mandate §4.4 (Embedding Threat Model) requires that the residual attack surface be documented publicly rather than obscured. We publish the threat model at /canon §threat-model, including the specific reconstruction attacks we have tested against. The honest position is that embeddings are lossy representations, not ciphertext — and we design accordingly.

Question 8

Why isn’t the challenge vocabulary finalized?

Accepted Answer

Because finalizing it prematurely would be dishonest. The challenge vocabulary defines the types of refutations a verifier can issue against an attestation. Getting this wrong means either missing real failure modes (too narrow) or creating unfalsifiable catch-all categories (too broad). Both outcomes undermine the standard’s credibility.

Canon v1.0 will freeze the core challenge types: witness conflict, scope omission, inference-type mismatch, hash-chain break, signature failure, and a small set of standard refutations. These cover the structural failure modes that apply across all domains. Domain-specific vocabularies — legal citations, journalism source classes, audit findings — will continue evolving via versioned extension packs, as required by Mandate §3.3 (Vocabulary Extensibility).

Each attestation records the vocabulary version it was sealed against, so old artifacts remain verifiable even after newer challenge types ship. The v1.0 core vocabulary ratification target is Q3 2026; see /roadmap. We would rather ship a smaller, correct vocabulary than a comprehensive one that includes categories we have not tested under adversarial conditions.

Question 9

Why should I trust NORA with my data?

Accepted Answer

You should not have to trust us with your data — and the architecture is designed so you do not need to. Per-user database isolation means your archive lives in its own Postgres instance, not in shared tables. The sensitivity-tiered router ensures privileged content never leaves your machine when configured for local inference.

Every operation on your data is recorded in an append-only custody chain. If NORA ever tampered with your data, the hash chain would break, and any independent verifier could detect it. The Meridian Mandate §2.3 (Falsifiability Without Cooperation) requires that verification never depend on our cooperation.

The practical answer: your data is encrypted at rest and in transit, isolated per-user at the database level, and every action on it is cryptographically logged. But the architectural answer is stronger: we built a system where trusting us is not required, because the math works without us.

Question 10

How is this different from just using ChatGPT?

Accepted Answer

ChatGPT is a general-purpose conversational AI. Meridian is a custody-grade workspace for evidence-quality work. The core differences: (1) Meridian cites every source with click-through to the specific paragraph — ChatGPT often generates plausible but unverifiable references. (2) Every Meridian answer ships with a Canon attestation, a signed artifact anyone can independently verify. ChatGPT provides no verification mechanism. (3) Your documents in Meridian are stored in an isolated, per-user database with an append-only custody chain. ChatGPT has no personal archive or custody guarantee.

Meridian also routes sensitive content to local models by default, whereas ChatGPT sends everything to OpenAI’s servers. For work that has to survive adversarial review — legal discovery, journalism, compliance — the provenance and verification gap between the two is the entire product.

Question 11

What is Meridian?

Accepted Answer

Meridian is the reference application built on the Canon standard. It provides a personal data archive, AI-assisted research workspace, and attestation pipeline — all in one interface. Documents you ingest are hash-stamped, custody-tracked, and available for verifiable reasoning. Learn more at /meridian.

Question 12

What is the Canon standard?

Accepted Answer

Canon is an open specification (CC0-licensed) for verifiable reasoning artifacts. It defines how an AI system’s observations, inferences, and conclusions can be independently audited by any third party without trusting the issuer. The full spec is published at /canon.

Question 13

Who is behind NORA Foundation?

Accepted Answer

NORA Foundation is a public-interest organization focused on verifiable AI reasoning. We maintain the Canon standard, build the Meridian reference implementation, and operate the open verifier registry. We are pursuing 501(c)(3) fiscal sponsorship for tax-deductible giving.

Question 14

What data sources can I ingest into Meridian?

Accepted Answer

Meridian supports email archives (MBOX, EML), documents (PDF, DOCX, TXT), images, audio recordings, and structured exports from common platforms. Each ingested item is SHA-256 hashed at intake and enters the custody chain immediately. Additional connectors are shipping with each beta wave.

Question 15

How much does Meridian cost?

Accepted Answer

Meridian is free during the private beta. Post-launch pricing will follow a freemium model: a generous free tier for personal use, and paid plans for professional and institutional users who need higher storage, more AI queries, and team features. We will publish pricing well before any charges begin.

Question 16

Can I self-host Meridian?

Accepted Answer

A self-hosted option is on the roadmap. The architecture is designed for it — per-user Postgres databases, stateless API layer, and portable Canon artifacts. Enterprise and institutional users with strict data-residency requirements should contact partners@norafoundation.io to discuss early access to self-hosted deployments.

Question 17

Is NORA Foundation a nonprofit?

Accepted Answer

We are pursuing fiscal sponsorship with a 501(c)(3) host so that institutional donors can make tax-deductible contributions. Until that status is confirmed in writing, we do not represent donations as tax-deductible. Grantmakers should reach out at grants@norafoundation.io for routing details.

Question 18

How are donations used?

Accepted Answer

Funds support specification drafting, reference implementations, verifier tooling, adversarial review, documentation, and ecosystem development. Once fiscal sponsorship is in place, Open Collective will provide a public ledger of all disbursements. Major funders can request line-item reporting at any time.

Question 19

Which AI models does Meridian use?

Accepted Answer

Meridian is model-agnostic by design. The current beta uses Claude (Anthropic) for reasoning tasks, but the architecture supports swapping or combining providers. Canon attestations are model-independent — verification does not depend on which model produced the reasoning.

Question 20

Are Canon attestations legally admissible?

Accepted Answer

Canon attestations provide cryptographic proof of integrity and provenance, which strengthens evidentiary foundations. Legal admissibility depends on jurisdiction and context. We are designing Canon to meet the technical requirements courts and regulators look for, and we publish guidance on evidentiary use cases.

Question 21

What are the limits on the free tier?

Accepted Answer

The free tier will include a personal archive with reasonable storage limits, a monthly AI query quota, and full access to the Canon verification pipeline. Exact limits will be published before launch. The goal is for individual users to get genuine utility without paying.

Question 22

Is there enterprise or institutional pricing?

Accepted Answer

Yes. We will offer enterprise plans with dedicated support, higher limits, custom data-residency options, and SLAs. Institutions interested in early adoption should contact partners@norafoundation.io. Academic and public-interest organizations may qualify for subsidized access.

Question 23

How does Meridian handle data security?

Accepted Answer

All data is encrypted at rest and in transit. Each user gets an isolated database. The custody chain provides a tamper-evident audit log of every action taken on your data. We follow SOC 2-aligned practices and will publish a security whitepaper before general availability.

Question 24

How can I get involved beyond using the product?

Accepted Answer

There are several paths: contribute to the Canon specification review, build a third-party verifier, join the adversarial review program, or fund the work through the foundation. Visit /contact for the right channel, or reach out at hello@norafoundation.io.

Questions about the foundation, the standard, and the work.

The hard questions

Still have a question?

Ready to engage?