Regulated Industry Infrastructure

A Standard in Active Development

Aregis delivery is not governed by proprietary logic you have to take on faith. It follows a structural standard being developed specification-first at an international open-standards working group. Aregis is a contributor to that work, and will implement the standard in full once it is published.

Who Owns the Standard, and Who Implements It

The standard governing your project record is not owned by the company delivering your project. That separation is the point, so it is worth being precise about who does what.

PraSaga Foundation

Stewards the standard

Hosts the DAO SagaStandards Working Group, the open-standards body where the specification is reviewed, amended, and ratified. Acceptance is the working group's decision, not a contributor's.

SagaHalla

Contributor

Contributes the specification and its reference implementation, and licenses the Saga Agent Architecture and GAME Plan Engine that Aregis delivers on.

Aregis

Contributor and implementer

Contributes from the delivery side, where real regulated engagements are what surface the requirements, and will implement the standard once published.

Why a Standard Rather Than a Product

A regulated program outlives the vendor that supported it. If the rules governing scope, evidence, and attribution live only inside one company's codebase, then the record those rules produced is only as durable as that company's commercial interest in maintaining it. Writing the standard first — as a specification, rather than as whatever the code happens to do — is what makes the record portable. Submitting it to a standards body that no contributor controls is what keeps any single vendor from quietly redefining it later.

Rules the Standard Applies to Itself

The parts worth showing you are not the capability claims. They are the constraints the specification places on its own authors, which are the reason its status labels can be believed at all.

A capability is unsupported until a test cites it

Any property asserted only because documentation describes it is formally marked unsupported. Every claim carries either a passing test or a caveat, and the caveat currently qualifies more of the corpus than the tests do.

A gap may not be closed by redefining the term

When a component cannot meet a capability, the permitted responses are to narrow the scope or record the shortfall as a deployment risk. Relaxing the definition until the gap disappears is explicitly forbidden.

Two working cases before anything is adopted

A specification does not enter the core on the strength of its own design. It requires at least two worked end-to-end cases, validated automatically. The current count for the settlement interface is zero, and the plan says so.

Contributors do not ratify their own work

Nothing a contributor drafts becomes part of the standard on its own authority. It stays in a contributed tree until the working group minutes a decision, and a decline is a valid outcome.

Questions We Have Not Answered

The standard keeps a register of unresolved problems, dated and revised rather than quietly narrowed. A representative sample:

  • How much each party discloses so contribution can be scored across sponsor, CRO, and CMO boundaries — a negotiation between counterparties, not an engineering task.
  • How the right to erasure is honored under GDPR and HIPAA when a record is designed to be durable. A permanent history is an anti-erasure affordance, and the architecture has to refuse it rather than inherit it.
  • Which substrate the settlement layer anchors to, pending a capability certification campaign that has not yet run against any candidate.
  • How identity and authentication work for regulated deployments, which gates a production node regardless of substrate choice.

None of these block the delivery work described elsewhere on this site, and none is load-bearing for a current engagement. We keep them in the open because a program that discovers them later has been handled badly.

Support the Work

Publication is the goal, not a step already taken. Joining the Aregis Network supports that directly: delivery engagements are what surface real regulated requirements and fund the specification's path through the working group, and contributors help decide which unresolved problems get solved first rather than reading about the decision afterward.

Join the Aregis Network →

Assessing Aregis for a regulated program and need to review the current draft first? Write to admin@aregis.io — no membership required.

Assess the Architecture Before You Commit

Read what is specified, what is built, and what is still open — then decide whether Aregis belongs in your program. See What Is Live →