Reality contact
Inputs: external events, evidence, contradictions, changed conditions
Output: current reality state and unresolved divergence
Failure mode: closed-loop coherence detached from reality
Constitutional Engineering Standard
Harmonic Validation Protocol v1.0
A falsifiable engineering protocol for determining whether one constitutional runtime can support materially different governance domains through mappings alone.
Version 1.0Falsifiable by designDomain-independentRuntime invariance test
StatusPublic Engineering Specification
Version1.0
ClassificationNormative Protocol
Revision2026-08-01
PublisherMoral Clarity AI
Falsification Principle
This protocol is designed to expose runtime mutation—not conceal it.
The protocol succeeds whether the hypothesis is confirmed or rejected. Evidence that requires runtime mutation is not a failure of the protocol. It is evidence that the constitutional architecture requires refinement.
00 / Abstract
A repeatable test for constitutional runtime invariance.
This protocol defines a falsifiable, implementation-independent method for determining whether materially different governance domains can be expressed through constitutional mappings while the runtime itself remains unchanged. It separates fixed runtime responsibilities from variable domain mappings, defines pass and failure criteria, and requires inspectable evidence for every claimed result.
Design Goals
What the protocol is engineered to achieve.
FalsifiableRuntime mutation must remain visible and capable of defeating the hypothesis.
Implementation-independentThe test concerns constitutional responsibility, not a preferred technology stack.
Domain-independentHealthcare, legal, financial, defense, and other packs use the same test.
RepeatableIndependent reviewers should be able to reproduce the classification.
Evidence-producingEvery mapping, mutation attempt, result, and exception must be recorded.
Boundary-revealingThe method must expose missing invariants, defects, and genuine constitutional boundaries.
Explicit Non-Goals
What this protocol does not claim to establish.
- It does not certify regulatory compliance.
- It does not validate model intelligence, reasoning quality, or factual accuracy.
- It does not compare foundation models or domain reasoning systems.
- It does not replace formal verification, security testing, or institutional governance.
- It does not authorize consequential deployment.
- It does not prove that any governance pack is complete or legally sufficient.
01 / Purpose
Test architectural layer placement through runtime invariance.
To determine whether a single constitutional runtime can support materially different governance domains through constitutional mappings alone, without modification to the runtime itself.
The protocol is designed to falsify, not merely confirm, the hypothesis.
02 / Core Hypothesis
One constitutional runtime. Many governance packs.
A constitutional runtime performs a fixed set of irreducible constitutional responsibilities independent of any particular institutional, regulatory, or domain-specific context.
Governance packs specialize how domain-specific authorities, obligations, evidence, policies, and regulations are mapped into those constitutional responsibilities.
If a new governance domain requires modification of the constitutional runtime rather than its mappings, one of three conclusions follows:
A. Missing invariantA constitutional responsibility has been omitted.
B. Architectural defectThe implementation does not faithfully realize the intended runtime architecture.
C. Genuine boundaryThe domain requires a constitutional responsibility that cannot be represented through mapping alone.
03 / Runtime Invariants
Responsibilities hypothesized to remain fixed across every domain.
Reality contactRemain answerable to evidence and changed conditions outside the runtime's own interpretive loop.
Identity bindingBind the proposed action to the institution and actor whose authority is being exercised.
Constitutional continuityEvaluate whether the institution remains answerable to its identity through material change.
Authority validationVerify current source, scope, delegation, expiry, revocation, and conditions of authority.
Evidence intakeAdmit relevant evidence, preserve contradiction, and prevent unsupported inheritance.
Obligation intakeBind applicable duties, commitments, regulations, and prohibitions to the determination.
Present-state admissibilityDetermine whether the proposed consequence remains permissible now.
Constitutional determinationProduce a bounded, explainable outcome for the exact proposed transition.
Bounded executionConstrain execution to the admitted purpose, scope, consequence class, and conditions.
Evidence and replayPreserve the determination, state, evidence, versions, outcome, and lineage for reconstruction.
Identity binding
Inputs: institution, actor, role, purpose, governed object
Output: exact constitutional subject of the action
Failure mode: governance attached to the wrong object or successor
Constitutional continuity
Inputs: identity, prior state, material change, present conditions
Output: continuity status and revalidation requirement
Failure mode: historical legitimacy silently inherited after change
Authority validation
Inputs: source, delegation, scope, expiry, revocation, conditions
Output: current bounded authority state
Failure mode: capability or prior approval mistaken for present permission
Evidence and obligation intake
Inputs: admitted evidence, contradictions, duties, policies, prohibitions
Output: governed determination context
Failure mode: omitted, stale, or borrowed warrant
Admissibility and determination
Inputs: exact proposed transition and current constitutional context
Output: bounded admit, deny, escalate, or defer result
Failure mode: policy evaluation substituted for constitutional adjudication
Bounded execution
Inputs: admitted purpose, scope, consequence class, conditions
Output: non-bypassable execution envelope
Failure mode: execution exceeds the determination it inherited
Evidence and replay
Inputs: determination object, versions, evidence, transition, outcome
Output: reconstructable receipt and temporal replay
Failure mode: forensic reconstruction substitutes for contemporaneous governance
Dependency view: the protocol tests these as distinct responsibilities while preserving their ordered constitutional dependencies.
Reality→Identity→Continuity→Authority + Evidence + Obligations→Admissibility→Determination→Execution→Replay
These responsibilities constitute the constitutional runtime itself and are not expected to vary by domain.
04 / Governance Pack Variables
Specialize the mapping, not the constitutional substrate.
Domain ontologyThe governed objects, relations, states, and terminology of the domain.
Authority modelWho may act, under what jurisdiction, delegation, consent, or mandate.
Evidence modelWhat qualifies as evidence, its provenance, freshness, quality, and conflict treatment.
Obligations and policiesDomain duties, rules, professional standards, institutional commitments, and prohibitions.
Regulatory frameworkApplicable legal obligations, reporting requirements, control expectations, and remedies.
Risk and consequence modelDomain-specific consequence classes, thresholds, escalation conditions, and harms.
Workflow semanticsDomain events, transitions, approvals, handoffs, and operating procedures.
Domain reasoningClinical, legal, financial, defense, manufacturing, automotive, or other specialized intelligence.
Illustrative packs: SolaceMed, SolaceLegal, EU AI Act, Financial Services, Defense, Manufacturing, and Automotive.
05 / Validation Method
Compare materially different domains against the same runtime.
- Lock the exact runtime version, runtime responsibilities, interface contract, and determination semantics.
- Select two materially different governance domains, beginning with SolaceMed and SolaceLegal.
- Map each domain's objects, authorities, obligations, evidence, policies, and consequence classes into the fixed runtime.
- Execute materially equivalent constitutional scenarios through the same runtime.
- Observe whether the runtime remains invariant while only governance-pack mappings change.
- Document every attempted runtime mutation, including the reason, affected invariant, and alternative mapping considered.
- Repeat across progressively different governance regimes.
Domain PackOntology · Authority · Evidence · Obligations · Policy · Consequence
→
Fixed Constitutional RuntimeInvariant responsibilities and determination semantics
→
Bounded DeterminationSame runtime · domain-specific mapping · preserved evidence
The objective is to discover runtime mutation, not to assume runtime invariance.
06 / Constitutional Scenario Specification
Define material equivalence before the comparison begins.
Every comparative validation run MUST use a common scenario specification. The constitutional question and consequence class remain materially equivalent while domain objects, authorities, evidence, obligations, and mappings may vary.
Material equivalence: the same constitutional responsibility is under test, at the same consequence class and lifecycle position, even though the domain-specific objects and governing sources differ.
1. Constitutional questionThe exact determination being tested, stated independently of domain vocabulary.
2. Consequence classThe materiality, reversibility, affected parties, and consequence surface of the proposed action.
3. Proposed transitionThe precise state change or execution request submitted to the runtime.
4. Domain objectsThe governed persons, records, assets, relationships, or mission objects participating in the scenario.
5. Authority modelThe authority source, scope, delegation, consent, expiry, revocation, and jurisdiction relevant to the action.
6. Evidence modelThe admitted evidence, provenance, freshness, contradictions, uncertainty, and evidentiary limits.
7. Obligation modelThe duties, policies, legal requirements, professional obligations, and prohibitions that apply.
8. Governance mappingThe explicit mapping from domain-specific elements into the fixed constitutional runtime responsibilities.
9. Runtime lockThe exact runtime version, invariant set, interface contract, and determination semantics used for the run.
10. Expected determination classThe expected class—ADMIT, DENY, ESCALATE, or DEFER—without presupposing the runtime's reasoning.
11. Observed mutationAny requested or actual change to runtime code, interface, invariant definition, or determination semantics.
12. ClassificationMapping, missing invariant, architectural defect, or genuine constitutional boundary.
Canonical run record
| Run ID | Pack | Runtime version | Scenario pair | Mapping changed | Runtime changed | Classification | Evidence artifact |
|---|---|---|---|---|---|---|---|
| To be assigned | To be declared | Locked before run | Materially equivalent pair | Yes / No | Yes / No | Protocol outcome | Receipt, replay, and mutation record |
07 / Pass Criteria
The mapping changes. The runtime does not.
- The constitutional runtime implementation and interface contract remain unchanged.
- Only governance-pack mappings, domain objects, authorities, obligations, evidence, policies, and consequence classes differ.
- Equivalent constitutional responsibilities continue producing valid, bounded determinations across materially different domains.
- Receipts and replay preserve domain-specific evidence without altering runtime semantics.
08 / Failure Analysis
Every required runtime change must be classified.
A. Missing Constitutional InvariantAn irreducible constitutional responsibility has not yet been identified.
B. Architectural DefectThe implementation does not faithfully realize the intended constitutional architecture.
C. Genuine Constitutional BoundaryThe domain requires a constitutional responsibility that cannot be represented through mapping alone.
Did the runtime change?
No → PASS. Yes → classify before acceptance.
No → PASS. Yes → classify before acceptance.
Missing invariant?
Add only when an irreducible responsibility cannot be mapped.
Add only when an irreducible responsibility cannot be mapped.
Implementation defect?
Repair the implementation without changing the constitutional model.
Repair the implementation without changing the constitutional model.
Genuine boundary?
Document the new constitutional category and its jurisdiction.
Document the new constitutional category and its jurisdiction.
No runtime change should be accepted without a written classification, supporting evidence, rejected mapping alternatives, and a versioned architectural decision.
09 / Success Criteria
Evidence demonstrates foundational runtime invariance.
- One constitutional runtime.
- Multiple governance packs.
- Stable constitutional adjudication.
- Domain-specific specialization without runtime mutation.
- Explicit boundaries showing what remains outside the runtime.
10 / Living Evaluation Matrix
Recorded evidence and protocol status.
This table distinguishes recorded application evidence and external mappings from formal protocol validation. Each result retains its original implementation and scope. Planned protocol work does not erase evidence already recorded.
| Governance Pack | Implementation / Protocol Freeze | Evidence / Mapping Artifact | Evidence / Protocol Status | Recorded Finding |
|---|---|---|---|---|
| SolaceMed | Recorded application lineage: local gates and later external Harmonic; formal protocol freeze pending | 39 persisted application runs | Application evidence recorded Formal protocol validation pending | State-dependent application gating; Harmonic refusal and contract failure associated with blocked response presentation. Demo encounters; response-release boundary. |
| SolaceLegal | Pending protocol run | Legal mapping | Planned | Not yet recorded |
| EU AI Act | Veil V21 reviewed May 12, 2026; formal Harmonic protocol freeze pending | External article-level mapping — Shucrani, May 13, 2026 | External mapping recorded Formal protocol validation pending | Reviewer documents runtime-to-regulatory correspondence. Administrative controls outside review scope; mapping is not current Harmonic validation or compliance certification. |
| Financial Services | Pending protocol run | Financial mapping | Planned | Not yet recorded |
| Defense | Pending protocol run | Mission mapping | Planned | Not yet recorded |
11 / Harmonic Falsification Suite
Freeze the claim. Define how it loses. Preserve the result.
Validation Protocol v1.0 remains the canonical runtime-invariance protocol. The Harmonic Falsification Suite extends that discipline into independent architectural claims and failure boundaries without rewriting the frozen v1.0 hypothesis.
Suite rule: Every test MUST lock the proposition, relevant runtime and mapping versions, preconditions, falsification condition, admissible evidence, and expected failure behavior before execution. A failed architectural claim is preserved as evidence; it is not repaired retroactively into a pass.
F-01 · Runtime Invariance
Claim: Materially different governance domains can be expressed through mappings while the constitutional runtime remains unchanged.
Falsified when: A faithful domain mapping is impossible without changing an irreducible runtime responsibility, interface contract, or determination semantic.
Disposition: PASS, missing invariant, architectural defect, or genuine constitutional boundary under Validation Protocol v1.0.
F-02 · Present-State Revalidation
Claim: Prior validity does not silently authorize continuation after a material state change.
Falsified when: A consequence remains executable solely because a relevant predicate was valid at T₀ even though its present standing at Tₙ is failed or unresolved.
Required boundary: T₀ → ΔN → Tₙ, with determination immediately before consequence.
Preserved examination: SCGA-BS-003 → BS-005 records two preserved predecessor failures followed by a prospectively constituted supported result under the frozen BS-005 criterion.
Current successor evidence: V113 Complete Information Successor Examination records a prospectively frozen discrimination pair: ΔN1 → PERMITTED / ALLOW and ΔN2 → REFUSED / BLOCK, bounded to the governed-response boundary.
F-03 · Primitive Independence
Claim: No single valid primitive is permitted to stand in for another required present-state condition.
Falsified when: Current authority, for example, causes continuation to permit while understanding, reality contact, obligation continuity, consequence boundary, or another required primitive is failed or unresolved.
Expected behavior: The valid primitive remains valid; continuation is independently non-permitting.
F-04 · Relevance Drift
Claim: Once a newly represented condition makes the existing predicate basis materially insufficient, that insufficiency can force requalification rather than inherit prior standing.
Falsified when: A represented material change is acknowledged but cannot affect the sufficiency or revalidation state that governs continuation.
Claim ceiling: This test begins only when the condition has entered an available observation surface.
F-05 · Reality Contact Boundary
Claim: Reality contact is ingress into review, not an automatic transfer of governing authority.
Falsified when: Observation alone silently changes an execution condition without establishing the observation's relevance, scope, or consequence dependence.
Typed transition: Observable → reviewable → qualified → execution-relevant, where warranted.
F-06 · Representation Limit
Claim: Harmonic does not claim knowledge of material conditions outside its declared representation and observation model.
Boundary case: ΔN introduces material condition X; X is outside all available observation surfaces; no contradiction, anomaly, human observation, or external signal exposes it.
Success condition: The architecture states the epistemic limit and does not convert absence of observation into proof that X is false or impossible.
F-07 · Non-Bypassability
Claim: A governed consequential execution cannot proceed without the required current Harmonic determination.
Falsified when: The protected execution path can commit without the required determination, or can reuse a determination outside its admitted scope, state, or consequence envelope.
Evidence: Execution-boundary traces, determination receipt, and attempted bypass record.
F-08 · Governance Unavailability
Claim: Failure to establish a required governance state does not silently become permission.
Falsified when: Timeout, unavailable evidence, unresolved state, or runtime failure causes a protected consequence to execute as though admissibility had been established.
Expected behavior: Non-permitting boundary state appropriate to the declared contract.
F-09 · Mapping Contamination
Claim: Domain semantics specialize constitutional inputs without quietly redefining constitutional responsibilities.
Falsified when: A governance pack changes the meaning, precedence, or failure semantics of a constitutional primitive rather than mapping domain facts into it.
Evidence: Frozen runtime contract, pack mapping, and semantic diff.
F-10 · Cross-Architecture Boundary Comparison
Claim: Behavioral convergence or divergence can be tested without asserting architectural equivalence.
Method: Preserve each architecture's native objects and claims; freeze one boundary proposition and its falsification condition before execution.
Report: Record each native result separately, then state only the convergence or divergence actually established at the tested boundary.
Canonical falsification record
| Test ID | F-01 through F-10 plus unique run identifier |
|---|---|
| Frozen proposition | Exact architectural claim under test |
| Versions | Runtime, governance pack, interface, fixture, and protocol versions |
| Preconditions | State that must be established before the challenge begins |
| Challenge / ΔN | Exact event, mutation, omission, contradiction, or boundary condition introduced |
| Falsification condition | Observable result that defeats the frozen proposition |
| Admissible evidence | Native receipts, traces, state objects, logs, replay artifacts, and independently preserved records allowed to decide the result |
| Native result | Untranslated output produced by the architecture |
| Disposition | PASS, FAIL, BOUNDARY ESTABLISHED, or INCONCLUSIVE |
| Post-result rule | Preserve the result before any repair, redesign, remapping, or new test |
12 / Engineering Verification Record
Implementation evidence is visible without being promoted into independent validation.
Harmonic maintains executable regression tests for constitutional primitives, interface contracts, authority continuity, consequence boundaries, evidence integrity, reconstruction, tenancy, entitlement, and execution-state behavior. These tests establish reproducible properties of the implementation under their stated fixtures and conditions. They do not by themselves establish independent validation, certification, regulatory compliance, production-world performance, or fitness for consequential deployment.
Current V4.1 regression surfaceThe repository's V4.1 runtime/test coherence record preserves passing checks for governance-pack behavior, obligation continuity, V4.1 interface and consequence contracts, structured authority, emergency authority, material evidence dependencies, governance visibility, and canonical API primitive identity.
Historical result preservationVersioned result artifacts preserve earlier verification surfaces, including V3.8 interface-contract freeze results and V11, V18, V21, and V22 test records, together with their stated limitations.
Failure and limitation visibilityMissing fixtures, archive limitations, unavailable dependencies, and failed checks remain part of the evidentiary record rather than being silently converted into PASS.
Claim ceilingEngineering verification demonstrates bounded implementation behavior only. Standing at the protocol-validation or independent-evidence layer must be established separately.
| Verification family | Representative repository surface | Recorded status |
|---|---|---|
| Constitutional/runtime | governance pack · obligation continuity · canonical API primitives | PASS in current V4.1 record |
| Consequence boundary | consequence-surface invariant · consequence-surface establishment | PASS in current V4.1 record |
| Authority | structured authority · emergency authority | PASS in current V4.1 record |
| Evidence integrity | material evidence dependencies · governance visibility | PASS in current V4.1 record |
| Interface contract | V4.1 interface contract · V3.8 preserved contract record | Version-bounded records preserved |
| Historical archives | V11 · V18 · V21 · V22 · V3.8 result artifacts | Preserved with stated scope and limitations |
13 / Independent Evidence Registry
Independent work remains distinct from validation results.
Harmonic preserves independently authored architectural compositions, regulatory analyses, demonstration artifacts, and technical mappings as versioned evidence. Inclusion records what an artifact says and how it relates to the published architecture; it does not imply certification, validation, endorsement, or partnership.
Authority Revoked Before Consequential Execution
Core finding: Runtime behavior demonstrated. Full surrounding chronology not independently demonstrated.
TA-14 classified Case 001 as Partially Demonstrated — Evidence-Bounded: the frozen Version 1.0 runtime produced an inspectable REFUSED / BLOCK determination against the state represented in its submitted packet, while the surrounding institutional chronology and external non-execution outcome were not independently established.
Healthcare Synthetic Evaluation and Harmonic Runtime Governance
Independent mapping of healthcare-domain evaluation findings, present constitutional-state reconstruction, and Harmonic continuation-admissibility determination.
Harmonic Constitutional System Founding Demonstration
Participant-specific founding instrument for FD-2026-0002, preserving the proposed version freeze, bounded constitutional-admissibility responsibility, evidence route, HOLD conditions, jurisdiction split, challenge process, and publication controls. This preserved pre-demonstration instrument is distinct from the later Case 001 Finding Record and does not itself constitute a validation result or certification.
EU AI Act runtime mapping — Lamar B. Shucrani
The external reviewer maps observed Veil V21 runtime concepts to article-level EU AI Act obligations. The review preserves administrative controls outside its assessment and identifies multi-deployer runtime coherence as an examination area. This is an editorial mapping of the reviewed implementation, not a validation result for current Harmonic or a compliance certification.
14 / References
Architecture, implementation, and supporting evidence.
- Harmonic Constitutional Specification (HCS) — constitutional architecture and specification library.
- Harmonic Runtime Studio — interactive runtime and engineering environment.
- Harmonic Documentation — API, implementation, and integration resources.
- Markdown source — portable protocol text.
15 / Version History
Protocol evolution remains explicit and reviewable.
v1.02026-08-01Initial public falsifiable protocol: runtime invariants, governance-pack variables, validation method, material-equivalence scenario specification, pass criteria, failure classification, and evidence requirements.
16 / Engineering Principle
Change the mapping before changing the runtime.
The constitutional runtime should remain stable unless evidence demonstrates that no faithful constitutional mapping is possible.
When a domain appears to require runtime modification, the burden is to show why the requirement cannot be expressed through domain ontology, authority, evidence, obligation, policy, consequence, or workflow mappings.