{
 "cert_id": "ae1-498e-cfdc-1a62-4bfb",
 "url": "https://aetherneum.com/cert/ae1-498e-cfdc-1a62-4bfb",
 "payload": {
  "council_session": {
   "agreement": 0.5,
   "dissent": [
    {
     "confidence": 0.8,
     "headline": "Sound cryptographic design but needs key rotation plan and clearer provenance limitations.",
     "seat": "Anthropic Claude",
     "verdict": "revise"
    },
    {
     "confidence": 0.78,
     "headline": "Design is largely sound but needs key‑management and transparency improvements before public release",
     "seat": "Cerebras GPT-OSS",
     "verdict": "revise"
    }
   ],
   "errors": [],
   "generatedAt": "2026-06-10T04:26:39.167Z",
   "opinions": [
    {
     "confidence": 0.8,
     "headline": "Sound cryptographic design but needs key rotation plan and clearer provenance limitations.",
     "id": "anthropic",
     "model": "claude-sonnet-4-20250514",
     "ms": 6101,
     "rationale": "The cryptographic bindings are well-designed with proper hash chaining, Ed25519 signatures, and CT-style transparency. The honest threat model appropriately scopes what can and cannot be proven. However, the key handling section reveals a critical gap: no key rotation mechanism is specified, creating a long-term operational risk. Additionally, the provenance limitation (inability to prove AI model authenticity) needs more prominent disclosure since it's a fundamental trust assumption.",
     "risks": [
      "No key rotation mechanism specified for long-term operational security",
      "Provenance limitation may not be sufficiently prominent to users",
      "Single point of failure in issuer's admin plane for certificate integrity"
     ],
     "seat": "Anthropic Claude",
     "verdict": "revise"
    },
    {
     "confidence": 0.9,
     "headline": "Council Certificates v1 design is sound",
     "id": "groq",
     "model": "llama-3.3-70b-versatile",
     "ms": 567,
     "rationale": "The design provides a robust cryptographic binding, a transparent ledger semantics, and a well-scoped threat model. The use of Ed25519 signatures, SHA-256 hashes, and a Certificate Transparency style Merkle tree ensures the integrity and authenticity of the certificates. The honestly-scoped threat model acknowledges the limitations of the design and provides a clear understanding of the security guarantees. The key handling and migration plan are also well-thought-out.",
     "risks": [
      "Key management errors",
      "Issuer infrastructure compromise"
     ],
     "seat": "Groq Llama",
     "verdict": "approve"
    },
    {
     "confidence": 0.78,
     "headline": "Design is largely sound but needs key‑management and transparency improvements before public release",
     "id": "cerebras",
     "model": "gpt-oss-120b",
     "ms": 566,
     "rationale": "The cryptographic bindings (canonical JSON, Ed25519 signatures) and Merkle‑tree transparency ledger follow established best practices, and the verification flow is clear. However, the threat model relies heavily on issuer honesty and does not provide cryptographic proof of individual model provenance, which may be a concern for users expecting stronger guarantees. Key handling should move to a non‑exportable vault and include rotation procedures, and the anchoring mechanism would benefit from signed timestamps or SCTs to prevent replay or git‑history tampering.",
     "risks": [
      "Issuer key compromise or insider falsification of model votes",
      "Git repository anchoring may be mutable without additional signed attestations",
      "Lack of cryptographic proof of model provenance could undermine trust",
      "Key rotation and backup recovery procedures are not formally defined"
     ],
     "seat": "Cerebras GPT-OSS",
     "verdict": "revise"
    },
    {
     "confidence": 0.95,
     "headline": "Council Certificates v1 is sound for shipping as a public certification primitive",
     "id": "moonshot",
     "model": "moonshot-v1-32k",
     "ms": 2997,
     "rationale": "The cryptographic bindings, transparency ledger semantics, and honestly-scoped threat model are coherent and defensible. The design ensures integrity and issuance history, provides a clear verification story, and openly states its limitations regarding model provenance.",
     "risks": [
      "Key management and migration to Vault Transit",
      "Potential for future changes in cryptographic standards"
     ],
     "seat": "Moonshot Kimi",
     "verdict": "approve"
    }
   ],
   "panel": "approve",
   "question": "Aetherneum is shipping Council Certificates v1 exactly as specified in the attached design. Are the cryptographic bindings, the transparency ledger semantics, and the honestly-scoped threat model sound to ship as a public certification primitive?",
   "risks": [
    {
     "risk": "No key rotation mechanism specified for long-term operational security",
     "seat": "Anthropic Claude"
    },
    {
     "risk": "Provenance limitation may not be sufficiently prominent to users",
     "seat": "Anthropic Claude"
    },
    {
     "risk": "Single point of failure in issuer's admin plane for certificate integrity",
     "seat": "Anthropic Claude"
    },
    {
     "risk": "Key management errors",
     "seat": "Groq Llama"
    },
    {
     "risk": "Issuer infrastructure compromise",
     "seat": "Groq Llama"
    },
    {
     "risk": "Issuer key compromise or insider falsification of model votes",
     "seat": "Cerebras GPT-OSS"
    },
    {
     "risk": "Git repository anchoring may be mutable without additional signed attestations",
     "seat": "Cerebras GPT-OSS"
    },
    {
     "risk": "Lack of cryptographic proof of model provenance could undermine trust",
     "seat": "Cerebras GPT-OSS"
    },
    {
     "risk": "Key rotation and backup recovery procedures are not formally defined",
     "seat": "Cerebras GPT-OSS"
    },
    {
     "risk": "Key management and migration to Vault Transit",
     "seat": "Moonshot Kimi"
    },
    {
     "risk": "Potential for future changes in cryptographic standards",
     "seat": "Moonshot Kimi"
    }
   ],
   "seats": {
    "answered": 4,
    "attempted": 4,
    "failed": 0
   },
   "split": true,
   "tally": {
    "abstain": 0,
    "approve": 2,
    "revise": 2,
    "veto": 0
   },
   "unanimous": false,
   "vetoed": false
  },
  "council_version": "0.1.0",
  "issued_at": "2026-06-10T04:27:02+00:00",
  "issuer": "Aetherneum Certification Authority",
  "issuer_url": "https://aetherneum.com",
  "item": {
   "sha256": "1cb3e64a42a1c6365d4879e1b777a2b74451ff7f8943aa33b45e3cb7f8e2fd02",
   "title": "Council Certificate v1 — signing & transparency design",
   "type": "design-doc"
  },
  "schema": "aetherneum.council-cert.v1",
  "verify_url": "https://aetherneum.com/cert/verify"
 },
 "payload_canonical": "{\"council_session\":{\"agreement\":0.5,\"dissent\":[{\"confidence\":0.8,\"headline\":\"Sound cryptographic design but needs key rotation plan and clearer provenance limitations.\",\"seat\":\"Anthropic Claude\",\"verdict\":\"revise\"},{\"confidence\":0.78,\"headline\":\"Design is largely sound but needs key‑management and transparency improvements before public release\",\"seat\":\"Cerebras GPT-OSS\",\"verdict\":\"revise\"}],\"errors\":[],\"generatedAt\":\"2026-06-10T04:26:39.167Z\",\"opinions\":[{\"confidence\":0.8,\"headline\":\"Sound cryptographic design but needs key rotation plan and clearer provenance limitations.\",\"id\":\"anthropic\",\"model\":\"claude-sonnet-4-20250514\",\"ms\":6101,\"rationale\":\"The cryptographic bindings are well-designed with proper hash chaining, Ed25519 signatures, and CT-style transparency. The honest threat model appropriately scopes what can and cannot be proven. However, the key handling section reveals a critical gap: no key rotation mechanism is specified, creating a long-term operational risk. Additionally, the provenance limitation (inability to prove AI model authenticity) needs more prominent disclosure since it's a fundamental trust assumption.\",\"risks\":[\"No key rotation mechanism specified for long-term operational security\",\"Provenance limitation may not be sufficiently prominent to users\",\"Single point of failure in issuer's admin plane for certificate integrity\"],\"seat\":\"Anthropic Claude\",\"verdict\":\"revise\"},{\"confidence\":0.9,\"headline\":\"Council Certificates v1 design is sound\",\"id\":\"groq\",\"model\":\"llama-3.3-70b-versatile\",\"ms\":567,\"rationale\":\"The design provides a robust cryptographic binding, a transparent ledger semantics, and a well-scoped threat model. The use of Ed25519 signatures, SHA-256 hashes, and a Certificate Transparency style Merkle tree ensures the integrity and authenticity of the certificates. The honestly-scoped threat model acknowledges the limitations of the design and provides a clear understanding of the security guarantees. The key handling and migration plan are also well-thought-out.\",\"risks\":[\"Key management errors\",\"Issuer infrastructure compromise\"],\"seat\":\"Groq Llama\",\"verdict\":\"approve\"},{\"confidence\":0.78,\"headline\":\"Design is largely sound but needs key‑management and transparency improvements before public release\",\"id\":\"cerebras\",\"model\":\"gpt-oss-120b\",\"ms\":566,\"rationale\":\"The cryptographic bindings (canonical JSON, Ed25519 signatures) and Merkle‑tree transparency ledger follow established best practices, and the verification flow is clear. However, the threat model relies heavily on issuer honesty and does not provide cryptographic proof of individual model provenance, which may be a concern for users expecting stronger guarantees. Key handling should move to a non‑exportable vault and include rotation procedures, and the anchoring mechanism would benefit from signed timestamps or SCTs to prevent replay or git‑history tampering.\",\"risks\":[\"Issuer key compromise or insider falsification of model votes\",\"Git repository anchoring may be mutable without additional signed attestations\",\"Lack of cryptographic proof of model provenance could undermine trust\",\"Key rotation and backup recovery procedures are not formally defined\"],\"seat\":\"Cerebras GPT-OSS\",\"verdict\":\"revise\"},{\"confidence\":0.95,\"headline\":\"Council Certificates v1 is sound for shipping as a public certification primitive\",\"id\":\"moonshot\",\"model\":\"moonshot-v1-32k\",\"ms\":2997,\"rationale\":\"The cryptographic bindings, transparency ledger semantics, and honestly-scoped threat model are coherent and defensible. The design ensures integrity and issuance history, provides a clear verification story, and openly states its limitations regarding model provenance.\",\"risks\":[\"Key management and migration to Vault Transit\",\"Potential for future changes in cryptographic standards\"],\"seat\":\"Moonshot Kimi\",\"verdict\":\"approve\"}],\"panel\":\"approve\",\"question\":\"Aetherneum is shipping Council Certificates v1 exactly as specified in the attached design. Are the cryptographic bindings, the transparency ledger semantics, and the honestly-scoped threat model sound to ship as a public certification primitive?\",\"risks\":[{\"risk\":\"No key rotation mechanism specified for long-term operational security\",\"seat\":\"Anthropic Claude\"},{\"risk\":\"Provenance limitation may not be sufficiently prominent to users\",\"seat\":\"Anthropic Claude\"},{\"risk\":\"Single point of failure in issuer's admin plane for certificate integrity\",\"seat\":\"Anthropic Claude\"},{\"risk\":\"Key management errors\",\"seat\":\"Groq Llama\"},{\"risk\":\"Issuer infrastructure compromise\",\"seat\":\"Groq Llama\"},{\"risk\":\"Issuer key compromise or insider falsification of model votes\",\"seat\":\"Cerebras GPT-OSS\"},{\"risk\":\"Git repository anchoring may be mutable without additional signed attestations\",\"seat\":\"Cerebras GPT-OSS\"},{\"risk\":\"Lack of cryptographic proof of model provenance could undermine trust\",\"seat\":\"Cerebras GPT-OSS\"},{\"risk\":\"Key rotation and backup recovery procedures are not formally defined\",\"seat\":\"Cerebras GPT-OSS\"},{\"risk\":\"Key management and migration to Vault Transit\",\"seat\":\"Moonshot Kimi\"},{\"risk\":\"Potential for future changes in cryptographic standards\",\"seat\":\"Moonshot Kimi\"}],\"seats\":{\"answered\":4,\"attempted\":4,\"failed\":0},\"split\":true,\"tally\":{\"abstain\":0,\"approve\":2,\"revise\":2,\"veto\":0},\"unanimous\":false,\"vetoed\":false},\"council_version\":\"0.1.0\",\"issued_at\":\"2026-06-10T04:27:02+00:00\",\"issuer\":\"Aetherneum Certification Authority\",\"issuer_url\":\"https://aetherneum.com\",\"item\":{\"sha256\":\"1cb3e64a42a1c6365d4879e1b777a2b74451ff7f8943aa33b45e3cb7f8e2fd02\",\"title\":\"Council Certificate v1 — signing & transparency design\",\"type\":\"design-doc\"},\"schema\":\"aetherneum.council-cert.v1\",\"verify_url\":\"https://aetherneum.com/cert/verify\"}",
 "payload_sha256": "498ecfdc1a624bfbfdf5b543bea7f312e5a5b1058d2f3d9d91d5f20eac3858e6",
 "signature": {
  "alg": "Ed25519",
  "public_key": "d267b4307118c259b6bec3cd98b233033a901d7b52fd3bb05d89134a534d4023",
  "public_key_url": "https://aetherneum.com/.well-known/council.pub",
  "sig": "47b1885c080ed8aeea7580c3df9e97fd8e34666730bf618d5c5c756765b37956a5d733a59a3dcff75a737242124733d5bda5d72f299a52e3deca2885087cea0e",
  "canonicalization": "UTF-8 of json.dumps(payload, sort_keys=True, separators=(',',':'), ensure_ascii=False)",
  "signed_message": "payload_canonical (exact bytes, UTF-8)"
 },
 "ledger": {
  "day": "2026-06-10",
  "leaf_index": 0,
  "leaf_hash": "718d3c4854de83092d51f9d208e2d34728397056405b91f88c3e15364f1fa046",
  "leaf_rule": "RFC6962-SHA256 leaf over the canonical JSON of {cert_id, payload_sha256, public_key, signature}",
  "tree_size": 2,
  "root_hash": "4606febff14d5a566e77ada0049bda74cce2e9fb1aee36a666a6ec5856bc217a",
  "inclusion_proof": [
   "98086c06e992704b2170d7c1b599a6953e2e9747971789c372f91413a39e771a"
  ],
  "root_published_url": "https://github.com/aetherneum-network/council/blob/main/ledger/roots/2026-06-10.json"
 }
}