Clause Syntax and DSL Architecture

Constructing Verifiable, Simulatable, and Jurisdiction-Aware Governance Logic

Clause Syntax and DSL Architecture in the Nexus Sovereignty Framework: Smart Clause Language for Executable, Composable, Auditable, Simulation-Aware, and Jurisdiction-Aware Governance Rules

Designing a Domain-Specific Language for Executable Governance

The Nexus Sovereignty Framework requires a language capable of expressing governance logic with enough precision for machines, enough transparency for institutions, enough structure for audit, enough modularity for jurisdictional forking, enough semantic depth for cross-domain interoperability, enough determinism for proof generation, and enough restraint to preserve the boundary between computation and authority. General-purpose programming languages are not designed for this purpose. Smart contract languages are not sufficient. Policy-as-code frameworks solve part of the problem, but not the full institutional, legal, simulation, credential, sovereignty, and public-safe requirements of NSF.

The Clause Layer therefore requires a dedicated domain-specific language: Smart Clause Language (SCL).

SCL is the clause syntax and execution grammar of the Nexus Sovereignty Framework. It is designed to encode policy, standards, safeguards, eligibility rules, access rules, public-safe publication conditions, simulation requirements, credential issuance logic, data validation rules, AI agent constraints, jurisdictional overrides, and proof receipt obligations in a format that is human-readable, machine-executable, simulation-compatible, registry-indexed, audit-traceable, and governance-bound.

The purpose of SCL is not to turn law into code in a simplistic sense. It is to create a controlled representation layer through which selected governance rules can become computable without becoming self-legitimating. SCL does not replace statutes, regulations, treaties, standards, professional judgment, public authority, community governance, or institutional decision-making. It provides a formal syntax for representing the operational logic of those sources under defined authority, scope, version, simulation, and proof constraints.

In NSF, a clause is not merely text. It is a governed object. SCL is the language that makes that object executable, composable, and auditable.

Why a Dedicated Clause Language Is Necessary

Generic programming languages such as Rust, Go, TypeScript, Python, Java, C++, or Java can implement governance workflows, but they do not naturally express governance meaning. They are powerful compute languages, not institutional rule languages. They can execute logic, but they do not inherently capture source authority, jurisdictional scope, public-safe status, credential dependency, simulation profile, proof scope, data classification, human review gates, or correction pathways. A governance rule implemented only in a general-purpose language becomes difficult for policy analysts, lawyers, auditors, public authorities, community stewards, and institutional reviewers to inspect.

Smart contract languages such as Solidity or Move provide deterministic execution for ledger environments, but they are too narrow for NSF. They are optimized for transactions, token state, escrow logic, on-chain execution, and decentralized applications. NSF clauses must govern data, credentials, simulations, AI agents, public-safe reports, national registries, Sovereign Data Zones, cross-border evidence, critical infrastructure, public health, climate risk, finance-readiness, insurance-readiness, and community safeguards. These domains cannot be safely reduced to token logic or ledger state. Many clause executions must occur off-chain, inside TEEs, confidential compute, controlled rooms, HPC systems, edge devices, or zero-knowledge proof environments.

Policy-as-code tools such as Rego, Cedar, XACML-style policies, or access-control DSLs solve important access and authorization problems, but NSF requires broader semantics. It must represent not only whether access is allowed, but why a rule exists, what source informs it, which jurisdiction applies, which simulation supports activation, which credentials can invoke it, which public-safe outputs are permitted, which proof receipt is required, how forks are managed, how disputes are handled, and how downstream dependencies are corrected.

Natural-language policy is expressive but ambiguous. Programming languages are precise but institutionally opaque. Smart contracts are deterministic but domain-limited. SCL is designed to occupy the necessary middle ground: formal enough for machines, readable enough for humans, constrained enough for audit, rich enough for governance, and modular enough for sovereignty.

SCL exists because governance rules need a language that understands governance as governance.

Core Design Objective of SCL

The central design objective of SCL is to encode governance rules as deterministic, typed, metadata-rich, simulation-aware, composable, and proof-generating clause objects.

SCL must allow a rule to be read by a human reviewer and executed by a machine without losing institutional meaning. A policy analyst should understand what the clause is trying to do. A lawyer should understand its authority boundaries. A data steward should understand which data it requires. A simulation reviewer should understand how it must be tested. A credential issuer should understand whether it can issue or revoke a credential. A compute node should understand what execution environment is required. An auditor should understand what proof must be generated. A registry should understand how the clause is versioned and forked. An AI agent should understand whether it may invoke the clause. A public-safe reviewer should understand what outputs can be published.

This requires SCL to be more than syntax. It must include a full clause object model. SCL code is only one component. A clause also includes metadata, schemas, provenance, governance package, simulation package, proof profile, access policy, public-safe rules, and lifecycle state. The syntax must bind these components together.

The design objective can be expressed as follows:

SCL must make a governance rule executable without separating execution from source, scope, evidence, simulation, credentials, jurisdiction, proof, public-safe meaning, and correction.

Principles of Smart Clause Language

SCL should be built on several foundational principles.

The first principle is determinism where determinism is required. A clause evaluating the same valid inputs, under the same version, same interpreter, same execution profile, and same dependencies should produce the same result. This is essential for audit, dispute review, replay, credential verification, and proof generation. Where probabilistic models, AI systems, or simulations are involved, SCL must explicitly mark the probabilistic component and preserve uncertainty, parameters, model identity, seeds where applicable, and output confidence.

The second principle is declarative expression. SCL should describe what conditions must hold, what evidence is required, what outputs are permitted, and what actions are authorized under the clause. It should avoid unnecessary imperative logic. The more a clause becomes procedural software, the harder it becomes to audit, simulate, verify, and translate. SCL should favor constraints, predicates, rules, schemas, and state transitions over arbitrary computation.

The third principle is composability. Clauses must be able to reference other clauses, credential schemas, data schemas, simulation profiles, proof profiles, public-safe rules, and jurisdictional overrides. Complex governance requires clause graphs, not monolithic rules. Composability supports reuse, modular upgrades, jurisdictional forking, and dependency tracing.

The fourth principle is type and schema binding. Inputs and outputs should be strongly typed and linked to JSON Schema, JSON-LD contexts, RDF vocabularies, domain ontologies, or other recognized schema systems. A clause cannot be reliable if its inputs are loosely defined. Type safety supports validation, simulation, zero-knowledge compilation, interoperability, and audit.

The fifth principle is governance awareness. Every clause must carry governance metadata: proposer, source, authority class, jurisdiction, domain, review status, quorum class, simulation requirements, activation status, credential dependencies, public-safe restrictions, and correction path. This prevents clause logic from becoming detached from institutional legitimacy.

The sixth principle is auditability. Every line or block of logic should be traceable to metadata, source references, governance decisions, version history, and execution records. If a threshold exists, the system should know where it came from. If a credential action occurs, the system should know which clause authorized it. If a public output is generated, the system should know which public-safe clause governed it.

The seventh principle is simulation awareness. Clauses should not be activated for high-consequence use without simulation packages. SCL should include syntax to define simulation requirements, model compatibility, scenario sets, stress tests, and activation conditions. Simulation is not external commentary. It is part of the clause lifecycle.

The eighth principle is privacy and sovereignty awareness. Clauses must specify data classes, SDZ constraints, compute-to-data requirements, cross-border transfer rules, public-safe transformations, and zero-knowledge pathways where relevant. A clause that ignores data sovereignty cannot be NSF-native.

The ninth principle is proof compatibility. SCL should compile into forms suitable for CAC generation, proof receipts, zero-knowledge circuits where feasible, TEE runners, audit DAGs, and registry indexing. The clause should define not only what result is produced, but what proof must accompany it.

The tenth principle is side-effect restraint. SCL should not behave like a general-purpose program with arbitrary side effects. It should evaluate conditions and produce bounded actions such as credential issuance requests, revocation requests, access decisions, public-safe output status, review triggers, audit events, or lawful handoff signals. This makes SCL safer and more formally reviewable.

SCL Is Not a General-Purpose Programming Language

SCL should be explicitly non-general-purpose. This is a strength, not a limitation.

A general-purpose language can do almost anything. That flexibility is dangerous for governance rules. It creates hidden side effects, arbitrary network calls, opaque state changes, complex control flow, unclear dependencies, and difficult audit trails. Governance logic should be constrained so that it can be inspected, tested, simulated, and verified.

SCL should therefore restrict file system access, arbitrary network calls, unbounded loops, nondeterministic randomness, hidden external state, dynamic code loading, unauthorized model calls, and unregistered side effects. External data must enter through declared inputs or approved oracle bindings. External computation must be represented through declared model calls, simulation hooks, or compute profiles. Credential actions must be declared, not hidden inside procedural code. Public outputs must be classified. State changes must generate audit events.

This makes SCL more like a governance rule language than an application language. It is designed to answer bounded governance questions:

Is this data eligible?

Is this credential active?

Is this threshold met?

Is this actor authorized?

Is this output public-safe?

Is this simulation sufficient?

Is this jurisdictional fork applicable?

Is this credential issuable?

Is this access request allowed?

Is this AI agent permitted to call this tool?

Is this Project SPV evidence package complete for review?

Is this clause execution valid under current registry state?

These are the types of questions SCL should answer. It should not become an unrestricted automation engine.

Core SCL Syntax Concepts

SCL syntax should be human-readable, structured, typed, and deterministic. A clause begins with a clause declaration that identifies namespace, domain, clause name, and version. It includes metadata blocks, input schemas, output schemas, trigger conditions, requirements, evaluation logic, credential actions, simulation hooks, public-safe rules, proof profiles, and correction paths.

A high-level SCL structure may include:

clause <Namespace>::<Domain>::<ClauseName>@<Version> {
  meta { ... }
  source { ... }
  jurisdiction { ... }
  authority { ... }
  input { ... }
  output { ... }
  credentials { ... }
  dataPolicy { ... }
  compute { ... }
  trigger { ... }
  require { ... }
  evaluate { ... }
  actions { ... }
  simulate { ... }
  proof { ... }
  publicSafe { ... }
  exceptions { ... }
  correction { ... }
}

The meta block contains identity and governance metadata. The source block identifies source references and authority boundaries. The jurisdiction block defines where the clause applies. The authority block states whether the clause is advisory, validation-supporting, credential-supporting, access-control, public-safe, simulation-only, authority-dependent, or operational under a separate instrument. The input block defines required evidence. The output block defines possible results. The credentials block defines who can invoke or act under the clause. The dataPolicy block defines data classification and sovereignty constraints. The compute block defines execution requirements. The trigger block defines invocation events. The require or evaluate blocks define logic. The actions block defines bounded outputs or effects. The simulate block links simulation requirements. The proof block defines CAC and proof receipt obligations. The publicSafe block defines publication rules. The exceptions block defines failure behavior. The correction block defines dispute and update pathways.

SCL should support comments, but comments should not carry normative meaning unless explicitly marked as explanatory metadata. The executable and governance meaning must be in structured fields.

SCL code should be canonicalizable. Formatting differences should not change the clause hash. The compiler should produce a canonical representation for hashing, registry indexing, signing, and proof generation.

Example: Food Safety Threshold Clause

A food safety threshold clause can show the basic concept, but it must be boundary-safe. The original sample uses “CodexCompliant,” which could imply certification or formal compliance. A safer NSF framing is “CodexReferencedFoodSafetyEvidenceVC” or “FoodSafetyEvidenceVC,” with an explicit boundary that the credential is evidence support, not official certification unless issued by competent authority.

A safer SCL example might be:

clause CodexRef::Food::ContaminantEvidenceCheck@1.0.0 {
  meta {
    title: "Contaminant Evidence Check for Food Batch Review"
    status: "active-limited"
    authorityClass: "evidence-support"
    domain: "food-safety"
    riskClass: "high"
  }

  source {
    reference: "Codex contaminant threshold mapping"
    sourceType: "standards-reference"
    endorsementStatus: "not-endorsed-by-source-body"
    interpretationStatus: "nsf-operational-representation"
  }

  jurisdiction {
    scope: ["CodexRef", "EU"]
    localForkAllowed: true
    applicableOnlyIf: registry.hasActiveMapping("Food::ContaminantThreshold")
  }

  input {
    contaminantLevel: float unit "mg/kg"
    batchId: string
    countryOfOrigin: string
    sampleMethod: string
    labCredential: Credential<FoodLabTestingAuthorityVC>
    dataProvenance: ProvenanceBundle
  }

  output {
    status: enum["PASS", "FAIL", "REVIEW_REQUIRED", "INSUFFICIENT_EVIDENCE"]
    reason: string
    evidenceClass: enum["evidence-support", "not-certification"]
  }

  trigger {
    on: InspectionEvidenceSubmitted(batchId)
  }

  credentials {
    invoke: requires RoleCredential<FoodInspectionReviewerVC>
    issue: requires IssuerCredential<FoodEvidenceCredentialIssuerVC>
  }

  dataPolicy {
    classification: "restricted-commercial"
    publicOutput: "aggregate-or-redacted-only"
    crossBorderTransfer: "by-jurisdiction-rule"
  }

  compute {
    profile: "governed-runtime"
    deterministic: true
    interpreter: "SCL-Core@1.x"
  }

  require {
    dataProvenance.valid == true
    labCredential.status == "ACTIVE"
    contaminantLevel.isPresent == true
  }

  evaluate {
    if contaminantLevel < threshold("Food::ContaminantThreshold", jurisdiction.scope) {
      return {
        status: "PASS",
        reason: "Measured level is below mapped threshold",
        evidenceClass: "evidence-support"
      }
    }

    if contaminantLevel >= threshold("Food::ContaminantThreshold", jurisdiction.scope) {
      return {
        status: "FAIL",
        reason: "Measured level is at or above mapped threshold",
        evidenceClass: "evidence-support"
      }
    }

    return {
      status: "INSUFFICIENT_EVIDENCE",
      reason: "Required contaminant evidence is missing or invalid",
      evidenceClass: "evidence-support"
    }
  }

  actions {
    on PASS {
      requestCredentialIssue FoodSafetyEvidenceVC(batchId) {
        claim: "contaminant-evidence-below-threshold"
        boundary: "not-official-certification-unless-adopted-by-competent-authority"
      }
    }

    on FAIL {
      requestCredentialStatusReview ExistingFoodSafetyEvidenceVC(batchId) {
        reason: "contaminant-evidence-failed-threshold"
      }
    }

    on REVIEW_REQUIRED {
      routeTo HumanReview<FoodSafetyReviewerVC>
    }
  }

  simulate {
    required: true
    model: CodexFoodSafetyScenarioModel@2.1
    scenarios: ["normal-batch", "borderline-threshold", "lab-error", "missing-provenance", "jurisdictional-threshold-difference"]
    activationCondition: "simulation-reviewed"
  }

  proof {
    generate: CAC
    include: ["clauseHash", "inputCommitment", "labCredentialStatus", "thresholdReference", "outputStatus"]
    rawDataDisclosure: "restricted"
  }

  publicSafe {
    publish: "no-batch-level-publication-without-review"
    requiredLabel: "evidence-support-not-certification"
  }

  correction {
    allowDispute: true
    disputeRoute: FoodSafetyEvidenceReviewPanel
    downstreamNotification: ["credential-registry", "audit-layer", "public-safe-output-if-published"]
  }
}

This example shows how SCL should work in NSF. The clause is human-readable, typed, jurisdiction-scoped, credential-linked, simulation-aware, proof-generating, public-safe, and boundary-aware. It does not claim to certify compliance. It supports evidence review under governed conditions.

Clause Structure and Metadata Requirements

Every SCL clause must include structured metadata. Metadata is not optional because it provides the institutional meaning of the clause. Without metadata, a clause is just code. With metadata, it becomes a governance object.

Required metadata should include clause identifier, namespace, domain, version, title, description, status, authority class, risk class, source reference, source type, endorsement status, interpretation status, proposer, governance package, simulation requirement, activation state, jurisdictional scope, public-safe status, data classification, compute profile, proof profile, credential dependencies, registry location, audit hooks, correction route, and deprecation path.

The clause identifier must be deterministic and registry-resolvable. Namespace must distinguish source reference, NSF reference, national fork, regional profile, community safeguard, enterprise implementation, or Project SPV clause. Domain must use controlled vocabulary. Version must follow semantic governance versioning. Status must be machine-readable.

Source metadata must identify the origin of the rule. If the clause maps to a standard, it must identify whether it is a reference mapping, implementation interpretation, or formally adopted representation. If the source is legal or regulatory, the clause must not imply legal determination unless competent authority adoption exists. If source text is copyrighted or restricted, the metadata must avoid unlawful reproduction.

Authority class is critical. A clause may be advisory, evidence-supporting, validation-supporting, credential-supporting, access-control, public-safe, review-triggering, simulation-only, restricted, authority-dependent, or operational under a separate lawful instrument. This class must travel with outputs.

Risk class determines required review and simulation. Low-risk clauses may require testing only. High-risk clauses may require multi-role review, simulation, public-safe assessment, and controlled deployment.

Jurisdictional metadata defines where the clause applies and whether forks exist. Public-safe metadata defines whether outputs can be published. Data classification metadata defines which inputs can be used. Compute metadata defines whether a TEE, controlled room, confidential compute, ZK proof, edge runtime, or HPC environment is required.

Credential metadata defines who may invoke the clause, issue outputs, review results, override decisions, or correct records. Proof metadata defines what CAC or proof receipt must be generated. Correction metadata defines how disputes and errors are handled.

All metadata should be signed, version-controlled, and auditable via the Registry and Audit Layers.

SCL Type System

The SCL type system must be strong enough to support interoperability, validation, simulation, proof generation, and zero-knowledge compilation. Types should not be loose strings unless unavoidable.

SCL should support primitive types such as string, integer, float, decimal, boolean, date, datetime, duration, URI, DID, hash, signature, enum, and bytes. It should support structured types such as object, array, map, record, tuple, evidence bundle, credential, proof receipt, CAC, provenance bundle, geospatial object, time series, model reference, simulation package, public-safe output, and registry reference.

Domain-specific types should include coordinate, polygon, raster, grid cell, H3 index, S2 cell, GeoTIFF reference, NetCDF variable, sensor observation, health observation, supply-chain event, emissions factor, asset identifier, legal entity identifier, public authority reference, credential status, node status, model status, risk score, uncertainty interval, and threshold profile.

The type system should support units. Many governance failures arise from unit confusion. A contaminant level in mg/kg is not equivalent to ppm without conversion rules. Emissions may be in CO2e with different global warming potential time horizons. Temperature may be Celsius or Kelvin. Distance may be meters or nautical miles. Time zones and date formats can alter results. SCL should require explicit units for quantitative values where relevant.

The type system should support constraints. Inputs may have allowed ranges, required freshness, minimum resolution, required provenance, required source credential, required jurisdiction, and required data quality. Outputs may have allowed states and public-safe classifications.

The type system should support nullable and missing values explicitly. Missing data is not the same as zero. Unknown is not the same as false. SCL must prevent silent conversion of uncertainty into failure or pass. Output states such as insufficient evidence or review required should be available.

The type system should support schema binding to JSON Schema, RDF/OWL vocabularies, JSON-LD contexts, HL7 FHIR profiles, OGC schemas, GS1 event schemas, ISO XML structures, SBOM schemas, and other domain formats. This allows SCL to function across the Interoperability Layer.

Clause Inputs and Evidence Binding

Inputs are the evidence surface of a clause. SCL should make input requirements explicit. A clause cannot be trusted if it accepts arbitrary inputs.

An input definition should specify field name, type, unit, source requirements, provenance requirements, data classification, jurisdiction, freshness, quality threshold, permissible formats, transformation rules, access policy, and whether the input may be disclosed in outputs or proofs.

For example, a disaster trigger clause may require rainfall data from certified sensors, satellite precipitation estimates, hydrological model outputs, exposure layers, vulnerability data, public authority status, and logistics readiness. Each input has a different type, source, quality requirement, and public-safe constraint.

An AI governance clause may require model identity, model version, data source list, tool-use plan, human review status, red-team record, output classification, and incident history.

A finance-readiness clause may require asset registry evidence, climate scenario outputs, maintenance records, safeguard evidence, contract references, monitoring data, and public-safe summary. These inputs must be restricted and boundary-labeled.

Input binding should occur through the Data Layer. SCL should not allow hidden external input. Every input should be retrieved, verified, hashed or committed, and linked to provenance. If an input comes from an oracle, the oracle must be registered and credentialed. If input comes from an AI model, model identity and evaluation status must be recorded. If input comes from a spreadsheet, provenance and validation must be applied before it becomes clause-ready.

Input binding is what makes clause execution evidentiary rather than arbitrary.

Clause Outputs and Output Semantics

Outputs must be structured and authority-bounded. SCL should not allow vague outputs where governance consequences are unclear.

An output schema should define allowed states, required fields, public-safe classification, credential effect, proof effect, downstream routing, uncertainty, and boundary language.

Typical output states may include PASS, FAIL, TRIGGER, REVIEW_REQUIRED, INSUFFICIENT_EVIDENCE, INVALID_INPUT, BLOCKED, RESTRICTED, PROVISIONAL, DISPUTED, SUPERSEDED, PUBLIC_SAFE, NOT_PUBLIC_SAFE, and ERROR. Domain-specific outputs may include risk category, readiness status, credential action, access decision, model status, node status, simulation status, or public-safe release status.

Output semantics must be defined. PASS means the clause condition was satisfied under specified evidence and proof scope. It does not mean universal compliance. FAIL means the condition was not satisfied under specified evidence, not necessarily legal violation. TRIGGER means another workflow should be routed, not necessarily automatic action. REVIEW_REQUIRED means human or institutional review is needed. INSUFFICIENT_EVIDENCE means the system cannot evaluate because required evidence is missing. BLOCKED means execution is not permitted under current policy.

Outputs should include meaning and nonMeaning fields or equivalent metadata. For high-risk domains, the output should explicitly state what it does not imply. This prevents overclaim.

For example:

output {
  status: enum["PASS", "FAIL", "REVIEW_REQUIRED", "INSUFFICIENT_EVIDENCE"]
  meaning: string
  nonMeaning: string
  publicSafeClass: enum["restricted", "public-safe-summary", "not-public"]
}

A finance-readiness output might state: “Evidence package completeness satisfied for review under this profile.” Its non-meaning: “This output is not investment advice, finance approval, creditworthiness, rating, guarantee, or solicitation.”

This is essential for public-good and legal safety.

Triggers and Invocation Logic

SCL should define triggers, but triggers must be bounded. A trigger identifies when a clause may be invoked. It does not necessarily create legal or operational action.

Triggers may include data submitted, credential presented, credential expiring, simulation completed, threshold approached, public-safe output requested, governance proposal filed, node status changed, model incident detected, public authority notice received, Project SPV evidence updated, edge device event, or scheduled review date.

Trigger definitions should include event type, caller eligibility, required credentials, data conditions, jurisdictional scope, debounce or cooldown periods, rate limits, and fallback behavior.

For example:

trigger {
  on: RiskSignalReceived
  where: riskDomain == "flood" and jurisdiction == "CA-ON"
  requireCredential: NationalRiskNodeVC
  cooldown: "PT30M"
  routeOnTrigger: "public-authority-support-review"
}

This trigger does not issue a public warning. It routes a flood risk signal to a support review pathway.

Triggers must be audit-logged. Trigger storms, repeated false signals, or unauthorized trigger attempts should create audit events and may require correction.

Requirements, Predicates, and Constraints

The require block defines conditions that must hold before evaluation or action. Requirements should be declarative. They may check data presence, provenance, credential status, jurisdiction, source authority, schema compatibility, model status, public-safe status, time validity, or dependency status.

For example:

require {
  actor.hasCredential(PublicSafeReviewerVC)
  dataset.provenance.status == "VERIFIED"
  registry.clauseStatus(self.id) == "ACTIVE"
  model.status != "QUARANTINED"
  data.classification.allowsPurpose("public-safe-summary")
}

Requirements should distinguish hard requirements and soft warnings. A hard requirement blocks execution if not met. A soft requirement may produce review required.

SCL should support logical operators, comparison operators, set membership, temporal operators, geospatial predicates, credential predicates, registry lookups, and proof predicates. It should avoid arbitrary procedural code.

Geospatial predicates may include intersects, contains, within, distanceLessThan, overlaps, buffer, centroid, and maskRequired. Temporal predicates may include before, after, during, withinWindow, expired, stale, forecastHorizon, and effectiveAt. Credential predicates may include active, revoked, suspended, recognizedIn, issuedBy, hasScope, and expiresAfter. Registry predicates may include activeVersion, parentOf, forkOf, supersededBy, recognizedBy, and dependencyStatus.

Predicates must be deterministic or explicitly model-dependent.

Clause Actions and Side-Effect Discipline

SCL should allow bounded actions. Actions are structured requests or state transitions that occur after evaluation. They should not be arbitrary side effects.

Permitted action classes may include request credential issuance, request credential revocation, request credential suspension, update credential status, allow access, deny access, route to review, generate CAC, generate proof receipt, trigger simulation, publish public-safe output, withhold output, notify subscriber, create dispute record, update registry status, suspend node, quarantine model, create audit event, or route lawful handoff.

Actions should include authority class. A clause may request credential issuance, but the issuer still must have issuing authority. A clause may route a disaster signal, but it does not issue public warning unless authorized. A clause may generate finance-readiness evidence, but it does not approve finance.

Actions should be idempotent where possible. Repeated executions should not duplicate credentials, repeated notifications, or repeated state transitions unless intended. Actions should be linked to CAC records.

For example:

actions {
  on PASS {
    requestCredentialIssue TrainingCompletedVC(subject) {
      issuer: currentIssuer
      proof: currentCAC
      expires: now + duration("P2Y")
    }
  }

  on FAIL {
    routeTo HumanReview<TrainingReviewerVC> {
      reason: "failed-evidence-check"
    }
  }

  on INSUFFICIENT_EVIDENCE {
    returnOnly "review-required-no-credential-action"
  }
}

This action model keeps SCL safe and auditable.

Clause Modularization and Referencing

SCL must support modularization. Clauses should be able to include, import, reference, or depend on other clauses under explicit version rules.

The basic reference syntax may be:

include ICAORef::Aviation::PilotFatigueClause@3.2.1 as fatigue
require {
  fatigue.evaluate(pilotId, dutyWindow).status == "PASS"
}

However, references must be registry-resolved. A clause should not import arbitrary code from unknown sources. The registry must verify clause status, version, jurisdiction, dependencies, and compatibility.

SCL should support version pinning and version ranges. High-consequence clauses should usually pin exact versions. Lower-risk clauses may allow compatible minor versions. Automatic major-version upgrades should require governance review.

Examples:

include Health::Credential::IssuerStandingClause@2.1.0 as issuerStanding
include PublicSafe::Geo::CriticalInfrastructureMaskingClause@1.x as maskRule
include Climate::Scenario::FloodExposureClause@4.0.2 pinned

Clause inheritance should be limited and explicit. Inheritance can create hidden behavior. Prefer composition over inheritance. If inheritance is used, overridden fields must be visible and semantic diffs must be generated.

Reusable clauses are powerful. Identity proof clauses can be reused across domains. Public-safe masking clauses can be reused across hazard maps. Credential revocation clauses can be reused across credential types. Data provenance clauses can be reused across simulations. But reuse must preserve context.

Clause Graphs and Dependency DAGs

SCL clauses compose into graphs. The compiler should produce a dependency DAG showing which clauses, schemas, credentials, models, data sources, and proof profiles are required.

A clause graph should show parent clause, child clauses, imported clauses, credential dependencies, data dependencies, simulation dependencies, public-safe dependencies, model dependencies, compute dependencies, and registry dependencies.

DAGs support audit and simulation. Before a clause activates, the system can test its full graph. If a child clause changes, the system can identify affected parent clauses. If a data schema is deprecated, dependent clauses are flagged. If a credential schema changes, access clauses may need review. If a model is quarantined, simulation clauses depending on it may be blocked.

The DAG also supports proof generation. A CAC can include a Merkle-style commitment to the clause graph. This allows verifiers to know not only which top-level clause ran, but which dependency versions were active.

Clause graphs should be replayable. A historical CAC should resolve to the dependency graph at execution time, not the current graph.

Jurisdictional Overrides and Forks in SCL

SCL must natively support jurisdictional forking and overrides. Governance differs across countries, regions, sectors, communities, institutions, and Project SPVs. The language must make these differences explicit.

A jurisdictional override may be expressed as:

override jurisdiction "CA" {
  threshold Food::ContaminantThreshold = registry.value("CA::Food::ContaminantThreshold@1.4.0")
  publicSafe.publish = "aggregate-only"
}

A national fork may be expressed as a distinct clause:

clause CA::Food::ContaminantEvidenceCheck@1.0.0
  forkOf CodexRef::Food::ContaminantEvidenceCheck@1.0.0 {
  ...
}

Fork metadata should include rationale, simulation diff, governance signatories, authority class, recognition status, and compatibility. Overrides should be limited, visible, and audit-linked. Hidden overrides are dangerous.

SCL should also support jurisdiction resolution:

jurisdiction {
  resolveBy: ["subject.location", "data.origin", "issuer.jurisdiction", "execution.nodeJurisdiction"]
  conflictPolicy: "review-required"
}

This is crucial because jurisdiction can be complex. Data origin, actor location, issuer jurisdiction, compute location, affected population, treaty context, and public authority scope may differ. SCL should not silently choose one without policy.

Multilingual and Legal-Text Binding

SCL must support multilingual and legal-text binding. Many governance systems operate across languages, and legal meaning can be language-specific.

A clause should preserve source language, translation status, authoritative text, unofficial translation, machine translation, legal interpretation notes, and ambiguity flags.

For example:

source {
  authoritativeLanguage: "fr"
  translations: [
    { language: "en", status: "official" },
    { language: "ar", status: "machine-assisted-review-required" }
  ]
  legalInterpretation: "competent-authority-required"
}

SCL should not allow machine translation to become legal authority. A translated clause may support operational use, but if legal meaning is disputed, competent interpretation is required.

This is essential for treaty alignment, public-sector integration, community communication, and multilingual public-safe reporting.

Simulation Hooks in SCL

Simulation hooks are a defining feature of SCL. A high-consequence clause should specify what simulation is required before activation and how simulations relate to execution.

A simulation block may include model, scenario set, required reviewers, validation requirements, uncertainty treatment, jurisdictional comparison, stress conditions, and activation rules.

For example:

simulate {
  required: true
  beforeActivation: true
  models: [
    FloodRiskModel@3.0,
    InfrastructureExposureModel@2.2
  ]
  scenarios: [
    "historical-100-year-event",
    "compound-rainfall-power-outage",
    "forecast-delay",
    "sensor-failure",
    "vulnerable-population-exposure"
  ]
  uncertainty: {
    requireConfidenceInterval: true
    publishUncertaintyLabel: true
  }
  reviewers: [
    DomainReviewerVC("hydrology"),
    PublicSafeReviewerVC,
    CommunityStewardVC where data.includesCommunityTerritory == true
  ]
  activationCondition: "simulation-package-accepted"
}

The clause compiler should enforce simulation requirements. If a clause is marked high-risk and simulation is required, the registry should not mark it active until simulation package acceptance exists.

Simulation hooks make foresight part of syntax, not afterthought.

Proof and CAC Binding in SCL

SCL must define proof generation. A clause should state which proof object is generated and what it includes.

For example:

proof {
  generate: CAC
  include: [
    "clauseHash",
    "inputCommitments",
    "credentialStatus",
    "computeAttestation",
    "outputStatus",
    "dependencyGraphHash"
  ]
  zkp: optional where input.classification == "sensitive"
  auditStream: "credential-gated"
}

Proof profiles should specify whether raw inputs are disclosed, whether input hashes are used, whether zero-knowledge proofs are required, whether TEE attestation is included, and which audit stream receives the record.

SCL should also support proof scopes:

proofScope {
  proves: "clause-evaluated-under-declared-input-commitments"
  doesNotProve: [
    "legal-compliance",
    "regulatory-approval",
    "financeability",
    "insurability",
    "public-authority-decision"
  ]
}

This is crucial for claims discipline. Proof receipts must not be overinterpreted.

Public-Safe Syntax

SCL should include public-safe syntax for outputs that may be published or communicated. Public-safe rules must not be handled informally.

A public-safe block may define publication class, masking, aggregation, uncertainty labels, official-source distinction, prohibited claims, correction rules, and audience.

For example:

publicSafe {
  publicationClass: "public-safe-summary"
  requireReview: PublicSafeReviewerVC
  mask: ["criticalInfrastructure", "protectedSpecies", "communitySensitiveLocations"]
  aggregateMinimum: 10
  uncertaintyLabel: required
  officialSourceLabel: "not-official-public-warning"
  prohibitedClaims: [
    "certified-safe",
    "finance-approved",
    "insured",
    "regulatory-approved"
  ]
  correction {
    notify: ["registry", "subscribers", "public-dashboard"]
    displayCorrectionNotice: true
  }
}

Public-safe syntax is essential for risk communication, public trust, and legal safety. It ensures outputs do not escape their context.

Data Sovereignty and Privacy Syntax

SCL must include data sovereignty and privacy constraints. A clause should be able to declare where data may be processed, whether compute-to-data is required, whether cross-border transfer is prohibited, whether zero-knowledge proofs are required, and whether data may be used for AI training.

For example:

dataPolicy {
  classification: "sovereign-sensitive"
  sdZone: required
  computeToData: true
  crossBorderTransfer: "prohibited-without-recorded-authority"
  aiTrainingUse: "prohibited"
  embeddingsExport: "prohibited"
  retention: "P90D"
  deletionAttestation: required
  publicOutput: "redacted-summary-only"
}

This allows the clause to enforce data governance before computation. It prevents hidden data movement, unauthorized model training, and public-safe failures.

AI Agent and Tool-Use Syntax

SCL should support AI agent governance. Clauses may define which agents can invoke tools, access data, produce outputs, and route decisions.

For example:

agentPolicy {
  allowedAgentClass: "PolicyDraftingAgent"
  modelCredential: requires ModelEvaluatedForAdvisoryUseVC
  toolsAllowed: ["registry.query", "simulation.run", "draft.generate"]
  toolsProhibited: ["credential.issue", "public.publish", "payment.trigger"]
  memory: "session-only"
  humanReview: required before "governance-proposal-submit"
}

Agent policies should be bound to credentials and audit records. If an agent exceeds scope, the clause should block the action and generate an incident event.

Exceptions, Fallbacks, and Safe Failure

SCL must explicitly define failure behavior. A clause should not fail silently or default to approval.

Exception blocks may handle missing data, stale data, conflicting evidence, revoked credentials, registry unavailability, compute failure, simulation mismatch, model quarantine, public-safe review failure, jurisdiction conflict, and emergency conditions.

For example:

exceptions {
  on MissingRequiredInput {
    return INSUFFICIENT_EVIDENCE
  }

  on CredentialRevoked {
    return BLOCKED
  }

  on RegistryUnavailable {
    if cachedState.age < duration("PT1H") and riskClass != "high" {
      return REVIEW_REQUIRED
    }
    return BLOCKED
  }

  on JurisdictionConflict {
    routeTo HumanReview<JurisdictionReviewerVC>
  }

  on ModelQuarantined {
    suspendExecution
    notify ModelGovernanceRegistry
  }
}

Safe failure is a governance requirement. High-consequence clauses should not proceed when the system lacks authority, evidence, or current status.

Correction and Dispute Syntax

SCL should include correction and dispute pathways. A clause should define who can dispute outputs, who reviews disputes, how corrections propagate, and what downstream records are affected.

For example:

correction {
  disputeAllowed: true
  eligibleDisputants: ["subject", "issuer", "publicAuthority", "communitySteward", "auditReviewer"]
  reviewBody: registry.resolve("FoodSafetyEvidenceReviewPanel")
  correctionActions: ["annotate", "supersede", "revokeCredential", "rerunClause", "publishCorrection"]
  downstreamNotification: ["credentialRegistry", "auditLayer", "publicSafeReports"]
  retention: "permanent-metadata-restricted-payload"
}

Correction syntax implements the Correctionability Doctrine. It ensures rules remain accountable after execution.

Clause Signing and Hashing

Every SCL clause should be signed and hashed. Signing establishes accountable publication. Hashing establishes tamper evidence. The system should hash both human-readable SCL and canonical intermediate representation where appropriate.

A clause package may include canonical text hash, metadata hash, AST hash, dependency graph hash, simulation package hash, proof profile hash, and final clause package hash. The canonical hash should use approved algorithms such as SHA-256, SHA-3, or BLAKE3 depending on profile. Long-term records should support cryptographic agility and post-quantum migration planning.

A clause signature should come from authorized governance keys. These may be issuer keys, registry maintainer keys, national node keys, validator quorum keys, public authority keys where applicable, community steward keys, or enterprise implementation keys depending on clause scope. Signature does not imply universal authority. It identifies who signed under what role.

The clause package should include:

signature {
  signer: DID
  signerCredential: ClausePublisherVC
  signatureMethod: "Ed25519Signature2020"
  signedAt: "2028-04-15T10:30:00Z"
  keyStatus: "active"
  auditHook: AuditRecordID
}

Clause signing supports identity, integrity, discoverability, registry state, and audit traceability.

Clause Compiler Architecture

The SCL compiler is a critical component of the NSF architecture. It must be deterministic, reproducible, auditable, and governed. It should not behave like an opaque software build tool.

The compiler pipeline begins with parsing. SCL source is parsed into an abstract syntax tree. The parser checks syntax, clause declaration, block structure, required metadata, and allowed constructs.

The second step is schema validation. Inputs, outputs, credentials, data policies, compute profiles, simulation hooks, public-safe blocks, and proof profiles are checked against the SCL schema and domain-specific extensions.

The third step is semantic validation. The compiler checks that referenced clauses exist, versions are valid, dependencies are resolvable, authority class is present, jurisdiction is valid, credentials are defined, public-safe restrictions are consistent, and data policies are not contradictory.

The fourth step is type checking. The compiler verifies types, units, nullable values, enum states, thresholds, geospatial types, temporal operations, and schema bindings.

The fifth step is governance validation. The compiler checks whether the clause has required governance metadata, review status, simulation package, activation conditions, and issuer credentials. Governance validation may not activate the clause, but it can identify missing requirements.

The sixth step is graph generation. The compiler creates a dependency DAG containing clauses, schemas, credentials, models, data policies, compute profiles, proof profiles, and public-safe rules.

The seventh step is intermediate representation generation. The IR is a canonical, machine-readable representation of the clause. Different IR targets may exist: evaluation IR, audit IR, simulation IR, TEE runner IR, ZK circuit IR, registry IR, and public documentation IR.

The eighth step is target compilation. Depending on compute profile, the compiler may produce bytecode for governed runtimes, WebAssembly, policy engine rules, TEE-executable bundles, ZK circuit definitions such as R1CS-compatible forms, DAG manifests, simulation runner manifests, or audit templates.

The ninth step is test generation. The compiler can generate unit tests, schema tests, edge-case tests, simulation test hooks, public-safe tests, and proof receipt tests.

The tenth step is canonical packaging. The clause package is canonicalized, hashed, signed, and submitted to registry workflow.

All compiler steps should be deterministic and reproducible. Compiler version must be recorded in the registry and CAC records. If compiler behavior changes, affected clauses may require review. The compiler itself should have SBOMs, signed builds, vulnerability monitoring, and audit records.

The SCL compiler is part of the trust infrastructure. It must be governed accordingly.

Intermediate Representations and Execution Targets

SCL should compile to multiple intermediate representations because different execution contexts require different formats.

The evaluation IR represents the executable logic for standard governed runtimes. It should be deterministic and easy to inspect.

The policy IR may target policy engines for access control or decision logic.

The TEE IR may package logic and dependencies for secure enclave execution. It should include workload hash, dependency hash, key release requirements, and attestation profile.

The ZK IR may represent the subset of clause logic that can be compiled into zero-knowledge circuits. Not all clauses are ZK-compatible. The compiler should identify which parts can be proven and which require conventional audit.

The simulation IR defines how the clause interacts with simulation engines. It includes scenario requirements, model references, parameter schemas, and expected output states.

The audit IR defines what events must be recorded, what proof receipt fields are required, and how dependency graphs are hashed.

The registry IR defines public metadata, private metadata, status, version, namespace, and discovery fields.

The documentation IR generates human-readable documentation, public-safe summaries, and reviewer materials.

The dependency graph IR supports audit and impact analysis.

Separating IRs allows SCL to remain one governance language while supporting many execution environments.

ZK Compatibility and Limits

SCL should be designed to support zero-knowledge proof compilation where feasible. ZK-compatible clauses must use supported operations, bounded inputs, deterministic logic, and circuit-friendly data structures. Threshold checks, credential membership proofs, range proofs, hash commitments, status checks, and certain validation functions may be suitable.

However, not all governance logic is ZK-compatible. Legal interpretation, human review, AI model evaluation, public-safe judgment, complex simulations, and many geospatial operations may not translate neatly into circuits. SCL should identify ZK-compatible subsets and proof boundaries.

A ZK block may specify:

zk {
  enabled: true
  prove: ["credentialActive", "thresholdSatisfied", "inputCommitted"]
  disclose: ["proofStatus", "clauseHash"]
  hide: ["subjectIdentity", "rawInput"]
  circuit: "auto-generate-if-supported"
}

If unsupported operations exist, the compiler should return partial ZK compatibility or require alternative proof methods such as confidential compute, controlled-room review, or selective disclosure.

ZK compatibility is powerful, but it must remain proof-scoped. A ZK proof proves the formal statement encoded. It does not prove full legal or institutional truth.

Formal Verification and Static Analysis

SCL should support formal verification and static analysis for high-consequence clauses. The compiler should detect errors before deployment.

Static analysis should detect unreachable branches, conflicting conditions, missing output states, unhandled exceptions, circular dependencies, unsafe public outputs, missing authority class, missing correction path, missing simulation requirement, inconsistent data policy, unauthorized credential action, and unsafe external oracle binding.

Formal verification may prove properties such as no credential issuance occurs without active issuer credential, no public output is produced without public-safe review, no restricted data is exported, no revoked credential can invoke a clause, no high-risk clause activates without simulation package, no infinite loop exists, and no unsupported side effects are present.

Model checking may evaluate state transitions. Fuzz testing may test unexpected inputs. Differential testing may compare versions. Regression testing may ensure patch releases do not change governance meaning.

Verification artifacts should be included in the clause governance package. A clause activation record should show which tests passed, which warnings remain, and what review was performed.

This raises the standard of governance logic before it enters critical systems.

SCL Registries and Developer Tooling

SCL requires tooling for authors, reviewers, validators, and implementers. Tools should include syntax editors, schema validators, semantic checkers, clause graph visualizers, simulation test harnesses, proof receipt preview, public-safe output preview, jurisdictional mapping tools, diff viewers, review workflows, and registry submission clients.

Policy analysts should be able to write or review clauses without deep programming knowledge. Governance engineers should be able to validate execution logic. Lawyers and institutional reviewers should be able to inspect authority class, source, jurisdiction, and boundary. Data stewards should inspect input requirements. Simulation reviewers should inspect simulation hooks. Auditors should inspect proof profiles. Public-safe reviewers should inspect publication logic.

SCL documentation should include human-readable explanations generated from clause metadata. Public versions should be SEO-ready and claims-safe. Restricted versions may include more detail. Documentation should distinguish official source, NSF interpretation, active clause, draft clause, fork, and implementation profile.

Developer tooling should not bypass governance. A tool can submit a clause proposal, but activation requires registry and governance workflow.

SCL and Risk Communication

SCL should support risk communication logic because many clauses produce messages, alerts, dashboards, reports, or notifications. Risk communication cannot be left to downstream systems without constraints.

A risk communication clause may define message class, audience, severity, confidence, uncertainty, geography, time window, source, official-source distinction, public-safe label, required languages, accessibility format, update interval, expiration, correction path, and prohibited claims.

For example:

riskCommunication {
  messageClass: "public-safe-advisory"
  audience: ["community", "public-authority-support", "operator"]
  severityScale: "NSF-RiskSignal-5"
  uncertaintyRequired: true
  officialSourceLabel: "decision-support-not-official-warning"
  languages: ["en", "fr"]
  accessibility: ["plain-language", "screen-reader-compatible"]
  expiresAfter: "PT6H"
  correctionRoute: PublicSafeCorrectionWorkflow
}

This allows SCL to govern not only internal logic but the communication of risk. It prevents technical outputs from being misread as public authority warnings, financial approvals, or definitive predictions.

SCL Security Model

SCL clauses are high-value assets. A malicious clause can cause unauthorized access, false credentials, unsafe public outputs, misleading readiness records, or harmful AI behavior. SCL must have a security model.

Clause authors must be credentialed. Clause publishing must be signed. High-risk clauses require multi-role review. Clause packages must be immutable once activated, with changes creating new versions. Dependencies must be registry-resolved. External calls must be declared. Public-safe outputs must be constrained. Credential actions must require issuer standing. Restricted data must remain protected. AI agent actions must be scoped.

The compiler should reject unsafe constructs. Registries should reject unsigned or unauthorized clauses. Execution engines should reject clauses not active in registry. Audit systems should record every invocation. Public dashboards should display status and boundary.

Supply-chain security also applies. SCL compilers, interpreters, runtimes, SDKs, and clause libraries must be signed, versioned, audited, and vulnerability-monitored.

SCL security is not only code security. It is governance integrity.

SCL Profiles

SCL should support profiles for different assurance levels.

SCL-Core defines minimal deterministic clause syntax, types, inputs, outputs, requirements, actions, proof, and metadata.

SCL-Gov adds governance metadata, quorum hooks, review states, disputes, and correction.

SCL-Sim adds simulation hooks, model references, scenario requirements, and validation records.

SCL-ZK adds zero-knowledge compatible constructs and circuit constraints.

SCL-Geo adds geospatial types, spatial predicates, raster and vector data references, masking, and public-safe map rules.

SCL-Health adds health data types, privacy controls, HL7/FHIR references, public health authority boundaries, and sensitive credential rules.

SCL-AI adds model identity, agent policy, tool-use constraints, prompt and output handling, evaluation records, and incident states.

SCL-FinRisk adds finance-readiness and insurance-readiness evidence profiles, with strict non-advice and non-underwriting boundaries.

SCL-Cyber adds SBOM, vulnerability, incident, access control, and software supply-chain constructs.

SCL-Edge adds offline execution, cached state, synchronization, tamper evidence, and degraded-mode rules.

Profiles make the language extensible without making every clause carry every domain feature.

SCL Boundary Statement

SCL supports the representation, testing, execution, and audit of governance logic. It does not by itself create law, certify compliance, grant public authority, approve procurement, approve finance, provide investment advice, underwrite insurance, issue official public warnings, determine legal liability, or replace competent decision-makers.

An SCL clause is a governed computational representation of a rule. Its effect depends on source authority, jurisdiction, adoption, institutional process, lawful instrument, credentialed actors, and applicable governance. SCL can make a rule executable and auditable. It cannot make an unauthorized rule legitimate.

This boundary should be included in SCL documentation, registry metadata, public pages, and proof receipt outputs.

The Clause DSL as the Language of Executable Governance

Smart Clause Language is the core encoding language of NSF. It allows policies, standards, safeguards, credentials, data rules, AI constraints, public-safe communication rules, and simulation requirements to become verifiable governance objects.

SCL makes policies structured.

It makes rules composable.

It makes clauses executable.

It makes simulations required.

It makes credentials evidence-bound.

It makes public outputs safer.

It makes AI agents constrained.

It makes jurisdictional forks traceable.

It makes audit trails meaningful.

It makes proof receipts interpretable.

It makes correction possible.

Just as smart contract languages enabled programmable transactions, SCL enables programmable governance, but under a different constitutional logic. SCL is not built for token speculation, financialized governance, or autonomous authority. It is built for public-good, role-bound, jurisdiction-aware, simulation-tested, credential-linked, privacy-preserving, audit-ready governance infrastructure.

It encodes rights only under authority.

It encodes permissions only under scope.

It encodes policy only with source and context.

It encodes execution only with proof.

It encodes automation only with human and institutional boundaries.

It encodes trust as something that can be inspected, simulated, challenged, corrected, and upgraded.

That is why SCL is necessary. It is the language through which the Nexus Sovereignty Framework turns governance from static text into verifiable, computable, public-good infrastructure, without surrendering human authority to machines.