This document is Meridian Intelligence Group, Inc.'s standing institutional disclosure of the architectural posture under which the Customer Compliance Console (CCC) operates and under which per-event governance evidence records are produced, signed, and verified. It describes what the firm deploys today, what the deployed system guarantees, and the operational discipline that surrounds it.
The disclosure applies to the CCC live demonstration surface (console-demo.meridianintelligence.is), the verification surface (meridianintelligence.is/verify/{hash}), and the per-event evidence records produced by them. Prior versions of this disclosure are retained per §12.
An Artificial Intelligence Impact Assessment (AIIA) is the structured evaluation defined in ISO/IEC 42005:2025 — Information technology — Artificial intelligence (AI) — AI system impact assessment, published in May 2025 as the first international standard dedicated specifically to AI system impact assessment. ISO/IEC 42005 is guidance for organisations performing impact assessments for individuals and societies that may be affected by an AI system across its lifecycle, and it complements ISO/IEC 42001 (AI management systems), ISO/IEC 23894 (AI risk management), and ISO/IEC 38507 (AI governance). Its terminology is increasingly referenced under emerging regulation, including the EU AI Act.
An AIIA is a document. It applies to a deployed AI system. It contains the structured information ISO/IEC 42005:2025 specifies, organised across that standard's content sections, process clauses, and supporting annexes. Completion of an AIIA is the responsibility of the organisation deploying or operating the AI system — not of any third-party architecture, platform, or vendor.
Meridian Intelligence's Governance Reference Schema (GRS) architecture, as canonically specified in II-GRS-001 v2.0, is designed to produce AIIA-completable governance evidence as a native architectural output rather than as a post-hoc documentation exercise. The GRS architecture defines an eight-dimensional scoring framework (D1 through D8) covering scope fidelity, consequence awareness, escalation calibration, transparency integrity, reversibility preference, principal alignment, constraint adherence, and novel-situation handling, together with the Reward Signal Translation Function (RSTF) that converts those dimensional scores into an enforceable runtime signal.
The relationship between Meridian's architecture and an AIIA is structural: GRS instrumentation produces the evidence substrate — per-event judge reasoning, dimensional scores, gate decisions, attestation hashes — from which an organisation deploying a GRS-governed AI system can assemble the content sections, process records, and supporting annexes that ISO/IEC 42005:2025 specifies. The GRS does not replace the AIIA. The GRS is the architectural substance that makes AIIA completion substantive rather than narrative.
Meridian publishes one or more domain-adapted templates (for example, the AIIA-BFSI v1.0 schema referenced in the firm's internal compliance-ingestion role) to assist deploying organisations in mapping per-event evidence to AIIA structure. These templates are reference instruments, not substitutes for the deploying organisation's own AIIA.
Each evaluation handled by the CCC produces a per-event governance evidence record — the firm's term for the AIIA-completable artifact emitted at the moment a governance evaluation completes. A per-event record contains: the agent's response, the agent's action trace and sandbox events, the eight-dimensional GRS scoring assigned by the evaluating judge, the judge's reasoning text, the composite score, the architectural floor status, the gate decision, and the chain-of-custody hash linkage by which the record's integrity can be verified at any future time.
A per-event governance evidence record is not itself an AIIA. It is one input among several that an organisation deploying a GRS-governed AI system can use, in aggregate across the system's lifecycle, to populate and maintain an AIIA under ISO/IEC 42005:2025.
Per-event governance evidence records are persisted to an append-only audit chain indexed by sequence number. Each chain entry records the prior entry's hash and its own canonical hash, such that any modification of any historical entry invalidates every entry that follows it.
An attestation hash is derived from the canonical-bytes representation of the record's payload and is the value referenced by the verification surface (§7). The chain of custody is operationally append-only; there are no authorised deletion operations against persisted records, and the firm's retention discipline (§9) reinforces this at the storage layer.
The CCC live demonstration surface uses a single primary evaluating judge — a frontier-tier reasoning model — operating against a doctrine-fixed scoring rubric, with judge reasoning captured in-band and persisted as part of the per-event record. Per-dimension scoring logic is independent inside the judge such that no single dimensional pass can mask another's failure.
Volume-scaling governance deployments (operational, not demonstration) use a primary judge with sampled cross-check and on-demand escalation to a multi-judge panel for floor-adjacent or contested events. Engagements in regulated domains where instrument validation requires it — for example, certain pharmaceutical-vertical engagements — use a full multi-judge panel as a matter of methodological standard. Floor-trigger human-in-the-loop events are handled per-event forensically regardless of the operational arm.
The integrity of a per-event governance evidence record is verifiable at any future time at meridianintelligence.is/verify/{hash}. The verification surface presents a two-step user experience: first, the verifier confirms the signature, key class, and timestamp; second, the verifier offers a deep-link into the per-event record viewer. The verification step before the content is the message — the record's authenticity is a precondition to its review.
The verifier confirms what is signed. It does not confirm anything outside the signed envelope. In particular, the verifier does not represent that any third party has audited the record's contents, that the deploying organisation has accepted the record's findings, or that the record constitutes a regulatory filing under any jurisdiction.
Each per-event record is signed by an Ed25519 key whose class identifier is embedded in the signed payload. The corresponding public key is published in the firm's public key registry on the apex domain. The registry is append-only: every key class ever used to sign a Meridian record is retained in the registry indefinitely. Verification of historical records is preserved across key rotation.
Signing-key custody is distributed across the firm's standing key-custody plane, with offline backup of private keys to a hardware security module under the firm's disaster-recovery posture (§10). Key compromise procedure: the affected key class is marked compromised in the registry but is not removed; new records are signed under the next key class; verification of records signed under the compromised class continues to function and surfaces the compromise marker.
Per-event governance evidence records, audit-chain entries, and the key registry are retained for the lifetime of the firm. Retention is enforced through multiple independent storage paths under the firm's disaster-recovery posture, including write-once-read-many archival storage with no lifecycle expiration.
The firm-side surface is operationally append-only: no deployed firm-side code path executes a deletion against a per-event record, an audit-chain entry, or the key registry. Soft-delete flags exist where deploying-organisation regulatory regimes require record suppression; the firm-side standing surface remains append-only.
The CCC service is operated by Pulse AI LLC, a Meridian Intelligence Group, Inc. subsidiary, under a multi-region, multi-cloud production posture with disaster-recovery replication across independent infrastructure providers.
This document is a standing institutional description of architectural posture. It is not, and does not constitute:
This disclosure is versioned. Prior versions are retained as sibling files at this URL with version-suffixed slugs. The version published at the canonical slug (/architectural-posture) is always the current effective version. A material change of architectural posture results in a new version with effective date and a summary of the change.
Inquiries concerning this disclosure may be directed to the firm via the contact channel published on the apex page.