Metadata-Version: 2.4
Name: mars-protocol
Version: 0.3.0
Summary: Mars® — AI post-invocation governance protocol specification (Capitoline Triad)
Project-URL: Homepage, https://gitlab.com/causum/mars-protocol
Author: Causum
License: Proprietary — Copyright © 2026 Causum. All rights reserved.
License-File: LICENSE.md
Keywords: AI governance,conformance,mars,protocol,specification
Classifier: Development Status :: 3 - Alpha
Classifier: Intended Audience :: Developers
Classifier: Programming Language :: Python :: 3
Classifier: Topic :: Scientific/Engineering :: Artificial Intelligence
Requires-Python: >=3.8
Description-Content-Type: text/markdown

# Mars® Protocol

**Proprietary and Confidential**
Copyright © 2026 Causum. All rights reserved. See [LICENSE.md](LICENSE.md).

---

## The Capitoline Triad

Mars® governance is structured around three foundational protocol components — the **Capitoline Triad** — each governing a distinct layer of the architecture. Together they compose a closed, independently-evaluable governance loop over any AI invocation.

| Triad Member | Protocol Layer | Governs |
|---|---|---|
| [**Juno**](spec/01-juno/) | §01 — Domain Modeling | Authority: the formal domain model, order decomposition, perspective constitution, variant declaration, and higher-order synthesis. Every downstream section consumes Juno's outputs as given. |
| [**Jupiter**](spec/02-jupiter/) | §02 — Analysis | Law and conformance: the analysis battery, base certification, delta-attestation lifecycle, integrated boundary enforcement (inbound and outbound), and elevated pre-invocation governance. |
| [**Minerva**](spec/03-minerva/) | §03 — Artifacts | Knowledge and evidence: semantic binding, knowledge-base construction, evidence-gathering verification, and governed artifact production. |

---

## Architecture overview

The [overview document](spec/00-overview/overview.md) defines all canonical terms, introduces the governed round-trip, and establishes the dependency order that the Triad enforces. Read it first.

---

## Reading order

The specification is organized in strict dependency order. Each layer consumes outputs produced by all prior layers. Read in the sequence below; skipping sections will produce undefined terms.

| File | Layer | Produces |
|---|---|---|
| [spec/00-overview/overview.md](spec/00-overview/overview.md) | Overview | Canonical definitions; architecture introduction |
| [spec/01-juno/modeling.md](spec/01-juno/modeling.md) | §01 Juno — Domain Modeling | Formal domain model; order decomposition; perspective constitution; variant declaration; higher-order synthesis |
| [spec/02-jupiter/02a-base.md](spec/02-jupiter/02a-base.md) | §02a Jupiter — Base Analysis | Analysis battery; symbolic lift; divergence signal; conformance certificate (nine structural invariants) |
| [spec/02-jupiter/02b-i-delta-attestation.md](spec/02-jupiter/02b-i-delta-attestation.md) | §02b-i Jupiter — Delta-Attestation | Amendment-governance primitive; delta-attestation object; delta-classification decision table; versioned re-discharge |
| [spec/02-jupiter/02b-ii-integrated-boundary.md](spec/02-jupiter/02b-ii-integrated-boundary.md) | §02b-ii Jupiter — Integrated Boundary | Inbound boundary; non-language-provenance anchor; composition gate (V1–V7); procedural-confidence derivation; R1/R2 |
| [spec/02-jupiter/02b-iii-actuation.md](spec/02-jupiter/02b-iii-actuation.md) | §02b-iii Jupiter — Actuation | Outbound boundary; actuation anchor; downstream actuation gate; R3/R4/R5; named-authority standing |
| [spec/02-jupiter/02c-elevated.md](spec/02-jupiter/02c-elevated.md) | §02c Jupiter — Elevated Analysis (AIGP) | Pre-invocation admissibility; forensic record; model governance; sycophancy gate |
| [spec/03-minerva/03-i-semantic-binding.md](spec/03-minerva/03-i-semantic-binding.md) | §03-i Minerva — Semantic Binding | Data source characterization; Pymnemon and Impera client classes; aspect-keyed query library; multi-locus gap report |
| [spec/03-minerva/03-ii-knowledge-base.md](spec/03-minerva/03-ii-knowledge-base.md) | §03-ii Minerva — Knowledge Base | Aspect-typed primitive extraction; co-indexed bidirectional store; controlled embedding-space transformations; map-governed chunking |
| [spec/03-minerva/03-iii-evidence-gathering.md](spec/03-minerva/03-iii-evidence-gathering.md) | §03-iii Minerva — Evidence-Gathering | Evidence-gathering verification; grounded conformance verdict; recomputation witness; symmetric reinforcement |
| [spec/03-minerva/03-iv-governed-production.md](spec/03-minerva/03-iv-governed-production.md) | §03-iv Minerva — Governed Production | Governed data and benchmark generation; model evaluation scenarios; benchmark consumer interface |
| [spec/appendix/A-use-cases.md](spec/appendix/A-use-cases.md) | Appendix A | Representative deployment use cases (non-normative) |
| [spec/appendix/B-conformance-checklist.md](spec/appendix/B-conformance-checklist.md) | Appendix B | Normative conformance checklist — all numbered properties in one table |
| [spec/appendix/C-glossary.md](spec/appendix/C-glossary.md) | Appendix C | Canonical term definitions |

---

## Machine-readable schemas

Formal JSON Schema definitions for the named objects in this specification live in [`schemas/`](schemas/). Each schema is the machine-readable complement to the corresponding prose definition. An implementation is conformant if and only if every instance it produces validates against the schema for that object type.

| Schema | Object | Defined in |
|---|---|---|
| [schemas/conformance-certificate.json](schemas/conformance-certificate.json) | Conformance certificate | §02a |
| [schemas/delta-attestation.json](schemas/delta-attestation.json) | Delta-attestation record | §02b-i |
| [schemas/actuation-anchor.json](schemas/actuation-anchor.json) | Actuation anchor | §02b-iii |
| [schemas/named-authority.json](schemas/named-authority.json) | Named-authority record | §02b-iii |

---

## Specification registry

The [registry/](registry/) directory holds entries for specifications registered under the Mars® architecture. The [registry-template.md](registry/registry-template.md) defines the required fields for a compliant registration.

---

## IP ownership and licensing

See [LICENSE.md](LICENSE.md).

The Mars® architecture spans two IP estates:

**Causum** owns the Mars® name, mark, and the following specification layers: domain modeling (§01 Juno), base analysis (§02a Jupiter), integrated analysis (§02b-i through §02b-iii Jupiter), elevated analysis (§02c Jupiter), and artifacts (§03-i through §03-iv Minerva).

**Licensing.** The Mars® Specification is made available solely for the purpose of evaluating and implementing a license from Causum. No right to practice, sublicense, modify, distribute, or create derivative works is granted by possession of or access to this document. Implementation of the mechanisms described herein requires a valid license agreement with Causum. Inquiries: contact Causum directly.

Multiple patent applications pending. Publication of this specification does not constitute a waiver of any patent, trade secret, or other intellectual property right.

---

## Version

`v0.2.0` — §02b split into §02b-i, §02b-ii, §02b-iii; §03 split into §03-i, §03-ii, §03-iii, §03-iv; specification reorganized under Capitoline Triad structure; machine-readable schemas and conformance checklist added.

See [CHANGELOG.md](CHANGELOG.md) for full version history.

---

*Mars® is a registered trademark of Causum.*
