aion-context 1.0.0

Cryptographically-signed, versioned business-context file format
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161

# `show` / `report` / `export`

Read-only subcommands for human-readable inspection,
compliance-framework reporting, and downstream-tooling export.
None of them mutate the file.

## `aion show`

Pretty-print one of four views into a file.

```bash
aion show <FILE> --registry <REGISTRY_FILE> <SUBCOMMAND>

Subcommands:
  rules        Show the current rules content (decrypted if needed)
  history      Show every version's metadata
  signatures   Show every signature with its verified status
  info         Show file ID + version count + signature summary
```

`--registry` is required by `signatures` and `info` (both run
the verify path internally). `rules` and `history` ignore it.

Format flag is `--format text|json|yaml`, default `text`.

### `show signatures`

```text
Signatures (3 total)
==================

Version 1: ✅ VALID
  Author: 50001
  Public Key: a5cfc10031a2e52b...

Version 2: ✅ VALID
  Author: 50001
  Public Key: a5cfc10031a2e52b...

Version 3: ❌ INVALID
  Author: 50001
  Public Key: 4bb5bdcc8b5fac7e...
  Error: Signature verification failed for version 3 by author 50001
```

A row's `verified` field reflects the registry-aware verdict:
`Author Y signed v3 with key K, but the registry says epoch
active at v3 is a different key`.

### `show history`

```text
Version History (3 versions)
================================

Version 1:
  Author:    50001
  Timestamp: 2026-01-15T09:00:00Z
  Message:   Genesis policy
  Rules Hash: 39f695ee668a4479...

Version 2:
  Author:    50001
  Timestamp: 2026-02-01T09:00:00Z
  Message:   Tighten threshold
  Rules Hash: 4f23abd0d4d77ff3...
  Parent Hash: 3ac2f4f7011beb62...
```

## `aion report`

Generate a compliance report for a single file.

```bash
aion report <FILE> \
    --framework <generic|sox|hipaa|gdpr> \
    --format <text|markdown|json> \
    --registry <REGISTRY_FILE> \
    [--output <PATH>]
```

`--framework` selects the templated narrative (Sarbanes-Oxley
Section 404, HIPAA 45 CFR §164.312, etc.). Implementation lives
in `src/compliance.rs`.

Sample (HIPAA / markdown, abbreviated):

```markdown
# HIPAA Compliance Report

**Generated**: 2026-04-25T18:39:57Z
**File**: `mercy-ai-gov-clean.aion`
**File ID**: `0x537dbed49eb8dbbf`

## Verification Summary

| Check | Status |
|-------|--------|
| Overall | ✅ VALID |
| Structure | ✅ |
| Integrity | ✅ |
| Hash Chain | ✅ |
| Signatures | ✅ |

## Version History

| Version | Author | Timestamp | Message |
|---------|--------|-----------|---------|
| 1 | 250001 | 2026-04-24T18:39:57Z | Genesis |
| 2 | 250002 | 2026-06-15T... | GDPR amendment |
| 3 | 250003 | 2026-09-01T... | FDA Part 11 amendment |
```

## `aion export`

Export the file's full contents (versions + signatures + audit
metadata) as JSON / YAML / CSV.

```bash
aion export <FILE> \
    --format <json|yaml|csv> \
    --registry <REGISTRY_FILE> \
    [--output <PATH>]
```

JSON shape:

```json
{
  "export_version": "1.0",
  "source_file": "policy.aion",
  "file_info": {
    "file_id": "0x537dbed49eb8dbbf",
    "current_version": 3,
    "version_count": 3
  },
  "versions": [ ... ],
  "signatures": [
    {
      "version": 1,
      "author_id": 250001,
      "public_key": [ ... ],
      "verified": true
    },
    ...
  ]
}
```

CSV format produces one row per audit-trail entry — useful for
spreadsheet-driven compliance reviews.

## Why these are separate from `verify`

`verify` is the trust gate: a binary verdict + structured
errors. `show` / `report` / `export` are reading verbs on top
of an already-verified file (or a file you want to inspect
even if it doesn't verify, for forensic purposes). Treating
them as separate verbs keeps the type-level exit-code contract
(verify exits non-zero on INVALID; the others exit 0 on
successful read regardless of verdict).