Verified Living Asset Standard (VLAS) v1.0

Governing Standard for Recognition, Issuance, and Lifecycle of Verified Living Assets

Status: Candidate Release for Review
Version: 1.0
Date: May 2026

© 2019–2026 Regenerative Development Corporation and the Planetary Regenerative Trust (PRT).
All rights reserved under the Regenerative Commons Collaboration Framework.

Abstract

Around the world, the things that actually keep places alive—healthy ecosystems, resilient infrastructure, trusted communities, and skilled people—remain largely invisible to mainstream finance. Capital flowing into nature and social outcomes is still materially below need, with authoritative reports flagging a multi-trillion-dollar shortfall for nature-based solutions toward 2030 and beyond. At the same time, single-metric markets (notably parts of the voluntary carbon market) have cycled through credibility shocks that erode trust. Yet credible precedents show measured benefits can be purchased at scale (e.g., Costa Rica’s payment for environmental services), and policy now “makes credits count” in planning and compliance (e.g., England’s mandatory Biodiversity Net Gain) and cap-and-trade (EU ETS). The Verified Living Asset Standard (VLAS) closes the core gap by treating verified improvements across five forms of value—Natural, Human, Social, Built, and Financial Capitals—as finance-grade assets that can be recognized, circulated, retired, and reinvested locally.

Preface

The Verified Living Asset Standard (VLAS) is a deterministic standard for measuring, verifying, and accounting for improvements in whole-place vitality as finance-grade value.

VLAS is designed to make regeneration auditable: it defines how to baseline the Five Capitals, verify uplift over time, translate that uplift into recognized assets, and produce repeatable valuation outputs (including Impact Net Asset Value / INAV) under clear governance constraints.

This Standard is written for stewards, implementers, policymakers, auditors, technical partners, and institutional capital allocators who require more than aspirational impact claims. It specifies the artifacts, roles, gates, and control flow needed to run conformant VLAS implementations across jurisdictions.

This document is a standards release for review. It is not an investment solicitation, prospectus, legal instrument, tax opinion, securities opinion, or accounting determination. Recognition under VLAS does not by itself determine treatment under any specific accounting standard, securities law, tax rule, banking regulation, public reporting regime, or jurisdictional requirement. Such treatment must be determined by qualified professionals under applicable law.

Relationship Between VLAS, RCCS, VLA, and PRT

Canonical distinction: The Standard governs. The System executes. VLAS is the law. RCCS is the courthouse.

Figure 1 — Standard governs, System executes, Assets are recognized, Trust holds the fiduciary container.

Use & Collaboration Notice

This Standard is provided for educational, academic, policy, and non-commercial standards collaboration. It may be shared within aligned organizations, research programs, stewardship initiatives, and public institutions that advance regenerative outcomes.

Derivative or modified versions may be created for non-commercial research, policy analysis, pilot implementation, or standards collaboration provided that they:

• are clearly labeled as derivative and non-authoritative;
• preserve full provenance, original title, version, and change log;
• do not claim conformance unless accepted through the VLAS governance and release process;
• provide attribution to Regenerative Development Corporation (RDC), the Planetary Regenerative Trust (PRT), and the VLAS standards steward, as applicable; and
• remain consistent with the canonical frameworks referenced by this Standard.

Commercial, promotional, fundraising, product-marketing, or proprietary derivative use requires written permission from the rights holders or appointed fiduciaries.

Reader Notice

This document is the governing standard. It is not the RCCS system specification.

• Part 1 defines the VLAS architecture and recognition control flow that every conformant implementation must satisfy.
• Part 2 defines the binding glossary, symbols, equations, gates, events, artifacts, and audit evidence requirements that make the standard deterministic and auditable.
• Appendices and registries define supporting derivations, exemplars, schemas, tests, publication artifacts, and external alignment surfaces.

Implementation-specific engineering details belong in the separate Regenerative Capital Credit System (RCCS) System Specification.

Figure 2 — Which sections each audience needs: Engineers, Stewards, and Auditors.

Part 1: The Verified Living Asset Standard — Architecture and Control Flow

Section 1: VLAS Architecture Introduction

Document ID: VLAS v1.0 — S1 Version: 1.0 Scope: VLAS system architecture, artifacts, actor lattice, sensor-to-NAV control flow. Precedence: Where this section conflicts with an external framework, VLAS governs issuance and lifecycle; adapters and third-party disclosures may translate but not modify VLAS requirements.

Overview of the VLAS Stack:

Figure 3 — Vertical stack from field data to published INAV, with three governance gates. ### S1.0 Purpose, Scope, Audience, and Precedence (Normative)

S1.0.1 Purpose

This section defines the Layer 0 architecture of the Verified Living Asset Standard (VLAS) :

Layer 0 is the authoritative contract for how VLAS:

• establishes the governance framework for a place, including community consent, policy vector, lot formation rules, and baselines (Data.PLOP),
• receives measurements from the real world,
• converts those measurements into integrity and then into credits,
• forms those credits into governed, quality-attributed lots per the project’s allowed-uses policy,
• records, tracks, and transfers those lots,
• prices those lots on admissible venues and benchmark curves, and
• aggregates them into portfolio-level and system-level Impact Net Asset Value (INAV).

Layer 0 does not describe one particular software stack, organization, or deployment. Instead, it defines the required artifacts, roles, processes, layers, gates, and equations that every conformant VLAS implementation shall embody, regardless of programming language, infrastructure, or jurisdiction.

Implementations may add additional layers, logs, analytics, or reporting surfaces, but they shall not bypass or contradict the requirements of Layer 0.

S1.0.2 Scope

Layer 0 — Section 1 covers the architecture and control plane of VLAS. Specifically, it defines:

• the end-to-end sensor to NAV pipeline, from raw measurements to a signed INAV position;
• the eight-layer VLAS stack, including the purpose and boundaries of each layer;
• the canonical data artifacts and ledgers (for example: IndicatorPackage, CalcProof, CUTMetadata, CorporateAction logs, NAVSnapshot, MonthlyAuditPack);
• the actor lattice (human roles and system components) and the three canonical human-in-the-loop gates;
• the core invariants and failure modes that must be enforced at the architecture level; and
• the minimum transparency and publication requirements that allow independent re-performance and audit.

Detailed definitions of variables, equations, schemas, and symbol tables are provided in Layer 0 — Section 2. Section 1 refers to those details where necessary but does not repeat every formula or field description.

S1.0.3 Audience

This section is written for three primary audiences:

• System designers and engineers who turn VLAS into running systems: services, workflows, schemas, and APIs.
• Stewards, verifiers, and governance actors who submit data, approve packages, approve issuance proofs, and sign off on INAV.
• Auditors, regulators, and fiduciaries who must understand how a published INAV figure can be reconstructed from first principles, and how the system prevents double counting, hidden inflation, and arbitrary overrides.

A reasonably competent reader in any of these roles should be able to follow a single credit from field measurement to reported INAV using only:

• Layer 0 — Section 1 (architecture and control flow),
• Layer 0 — Section 2 (glossary, equations, and canonical artifacts), and
• the artifacts produced by a conformant implementation (logs, registry exports, and audit packs).

S1.0.4 Precedence and Relationship to External Frameworks

VLAS is designed to be compatible with a wide range of external frameworks and standards, including financial reporting regimes, climate and nature disclosure standards, and jurisdictional rules for credits and offsets. External frameworks may impose additional requirements on:

• what must be disclosed,
• how results must be formatted, or
• how credits and INAV must be reported in regulatory filings.

However, the following precedence rules apply:

• VLAS Layer 0 governs issuance and lifecycle.
  The way a credit is created, allocated, adjusted, transferred, and retired is governed by VLAS equations, corporate action definitions, and registry behavior. External frameworks shall not redefine these.

• External frameworks are implemented through adapters and crosswalks.
  When VLAS outputs are reported into another framework, any required transformation shall be implemented as:

  • an adapter,
  • a crosswalk, or
  • a reporting view

that sits on top of the VLAS core. It shall not modify or bypass the canonical issuance logic or lifecycle.

• Conflicts shall be explicit.
  If a conflict arises between an external framework and this standard, VLAS Layer 0 shall be treated as the reference for credit integrity and lifecycle. Any required variance or override shall be:

  • explicitly documented, and
  • clearly visible in the relevant adapter or crosswalk definition.

S1.0.5 Project Level Operations Policy (PLOP) — Prerequisites for Pipeline Activation (Normative)

No VLAS pipeline activity — no measurement, no issuance, no lot formation, no pricing — SHALL occur for a place until a conformant Project Level Operations Policy (PLOP) has been established, approved, and registered. The Project Level Operations Policy (PLOP) is the governance foundation upon which the entire pipeline operates. Without it, the pipeline has no policy to execute.

Governing Principle: The pipeline is a machine. The Project Level Operations Policy (PLOP) is its operating instructions. Credits do not exist in a governance vacuum — their allowed uses, quality thresholds, lot formation rules, and distribution policies are set at project establishment, not at the point of issuance.

A conformant Project Level Operations Policy (PLOP) (Data.PLOP) SHALL include, at minimum:

(a) Place Registration and Geographic Scope

• A stable place_id (UUID) for the project, linked to a verified geographic boundary.
• Polygon vertices, coordinate reference system (CRS), and spatial extent.
• Jurisdictional context: country, sub-national region, and any special designations (indigenous territory, protected area, municipal boundary).
• Ecological context: watershed, biome, elevation band, and any relevant ecological classification.
• Relationship to other registered places: nested, adjacent, overlapping, or independent.

(b) Governance Framework and Stewardship Plan

• Identity and authority of the Local Regenerative Land Trust (LRLT) or equivalent governance body.
• FPIC documentation: evidence that Free, Prior, and Informed Consent has been obtained from all affected communities and rights-holders, with attestation date, scope, and renewal schedule.
• Stewardship commitments: what the place commits to doing (restoration activities, conservation covenants, community programs) and over what timeframe.
• Community Benefit Agreement: how benefits from credit issuance will be shared with local stakeholders.
• Governance structure: who has decision authority over credit policy, and what checks exist.

(c) Policy Vector and Eligibility Gates

• Published policy vector w* defining the target share across Five Capitals (N, H, S, M, F) for this place.
• Eligibility gate floors: minimum stewardship quality (S_min), minimum permanence (P_min), maximum uncertainty (U_max) — below which no credits SHALL be recognized from this place.
• Gate floors MUST be at least as conservative as any method-level defaults declared in the applicable AdapterSpecs, and MAY be stricter based on local governance decisions.

(d) Method Selection and AdapterSpec Binding

• Which measurement methods and corresponding AdapterSpecs will be used for this place.
• Baseline definitions: what is the reference condition against which ΔI will be measured, how was it established, and what evidence supports it.
• Benchmark selection: which external benchmarks (if any) will be used for pricing, regulatory alignment, or comparative analysis.
• Measurement schedule: planned frequency of data collection, verification cycles, and reporting windows.

(e) Lot Formation Policy (Allowed Uses)

The Project Level Operations Policy (PLOP) MUST declare the rules governing how recognized credits from this place will be formed into lots and routed to destinations. This is the primary anti-greenwashing control at the project level — it prevents credits from being restructured after issuance in ways that obscure quality, governance, or provenance.

The lot formation policy SHALL specify:

• Community-first allocation: What fraction (if any) of credits is reserved for community use, local offset obligations, or LRLT stewardship pools before any credits reach external markets. A minimum community allocation of zero is permitted but MUST be explicitly declared — silence is not consent.
• Market routing rules: Which credits are eligible for open market sale, which are restricted to contracted offtake, and which are held for internal use. For each routing path, the quality attributes required at lot formation (uncertainty tier, permanence band, capital class).
• Geographic pooling authorization: Whether credits from this place may be aggregated with credits from other places, and under what conditions (same watershed, same LRLT, same jurisdiction, same ecological zone).
• Buffer pool contribution: What fraction of issuance goes to reversal reserve, governed by what release or consumption rules.
• Holdback schedule: What fraction of issuance enters HELD_U state, and what verification events trigger RELEASE_U.
• Blending restrictions: Whether multi-capital lots are permitted, and if so, which capital combinations are allowed and what disclosure is required.
• Vintage and window rules: Whether cross-window aggregation is permitted, and any staleness thresholds.

The lot formation policy is immutable within a window. Changes to the policy require a governance-approved amendment to the Project Level Operations Policy (PLOP), recorded as a versioned update with the prior version retained for audit. Amendments SHALL NOT apply retroactively to lots already formed.

(f) Financial and Distribution Framework

• Cash routing rules: how proceeds from credit sales are distributed (community dividend, LRLT, Place Fund, PRT, investors) — the “covenantal waterfall.”
• Forgivable capital linkage: whether credit issuance triggers forgiveness of performance-linked loans or grants.
• Revenue recognition policy: when credit revenue is recognized for financial reporting.

(g) Implementation Benchmarks and Baselines

• Ecological baseline data: soil carbon measurements, biodiversity surveys, water quality assessments, or other method-specific reference data at project inception.
• Social baseline data: community health metrics, governance quality assessments, FPIC status at establishment.
• Built environment baseline: infrastructure condition assessments, energy performance, or other relevant metrics.
• Baseline methodology: how baselines were established (field measurement, remote sensing, modeled), what uncertainty applies to the baseline itself, and what evidence supports it.
• Benchmark Method Standard references: which published benchmark methods (if any) the project uses for baseline and ongoing measurement.

Artifact Definition

The Project Level Operations Policy (PLOP) is formalized as Data.PLOP, a canonical artifact with the following properties:

• Versioned and hash-anchored: every version carries a SHA-256 hash and a governance approval signature.
• Immutable per window: the PLOP in effect for a given measurement window cannot be altered retroactively.
• Referenced by all downstream artifacts: every Data.IndicatorPackage, Data.CalcProof, and Data.CUTMetadata MUST reference the plop_id and plop_version under which it was produced.
• Auditable: a reasonably competent auditor MUST be able to reconstruct the governance context of any credit by following the PLOP reference in its metadata.

Audit test: For any VLA lot, an auditor MUST be able to answer: “What governance framework authorized this credit, what lot formation rules applied, what community consented, and what baselines were used?” — using only the lot metadata and the referenced Project Level Operations Policy (PLOP). ### S1.1 Problem Statement and Design Intent (Informative)

S1.1.1 The Structural Gap VLAS Is Designed to Close

The starting point for VLAS is simple and uncomfortable:

• The things that actually keep places alive—healthy ecosystems, resilient infrastructure, trusted communities, and skilled people—do not show up as stable, finance-grade assets in most portfolios.
• At the same time, large volumes of “impact” or “green” capital are chasing signals that are partial at best, and in some cases actively misleading.

Several patterns show up repeatedly:

Single-metric traps.
Markets built around a single indicator (for example, tonnes of CO₂e) tend to overfit to that metric. They may underestimate or outright ignore damage or improvements in other capitals, or they may misrepresent where integrity actually resides in a place.

Fragmented methods and registries.
Dozens or hundreds of overlapping methods, registries, and platforms each define their own terms, baselines, and quality thresholds. The same underlying change on the ground can be double counted, undercounted, or counted in incompatible ways, depending on which registry or methodology is used.

Opacity and non-reproducibility.
Many systems do not provide enough information for a third party to reconstruct how a credit quantity was derived. Inputs, equations, and assumptions are hidden in proprietary engines, unversioned spreadsheets, or narrative reports.

Governance drift.
Human decision-makers are often placed “above” the math in ways that are hard to see. Well-intentioned overrides (for example, to recognize socially important results or to “correct” for model gaps) can introduce untracked bias and undermine trust, especially when economic stakes are high.

Temporal and ethical blind spots.
Credits are often treated as static, point-in-time artifacts. Questions such as “how durable is this change?”, “who holds the risk if it reverses?”, “what is the quality of local participation and consent?”, and “how uncertain is this measurement?” are either ignored or handled in ways that do not propagate into issuance and valuation.

The result is a structural gap:

• Capital cannot reliably distinguish between high-integrity, regenerative improvements and short-lived, extractive, or low-integrity claims.
• Communities and stewards cannot rely on these markets as a predictable, long-term partner in regenerating their places.
• Fiduciaries (such as pension funds and insurers) cannot treat these credits as part of a coherent, risk-adjusted balance sheet for the conditions of life.

VLAS is designed as an answer to that gap.

S1.1.2 Core Design Intent of VLAS

Figure 4 — Integrity Delta (ΔI) as the common primitive across all five capital domains.

VLAS is built to make the following statement true:

When a place improves in ways that genuinely strengthen its living systems and communities, that improvement can be measured, verified, encoded into credits, and reflected in portfolios and INAV in a way that is transparent, reproducible, and resistant to gaming.

To get there, Layer 0 encodes several core intentions:

Five-Capitals completeness.
VLAS treats integrity across Natural, Human, Social, Built, and Financial Capitals as part of one system. A method may focus on one domain (for example, a forest carbon protocol), but the VLAS adapter for that method must recognize and route co-benefits and trade-offs across capitals using explicit weights and dampeners. This prevents a single metric from dominating the system.

Primitive: Integrity Delta, not “project type”.
The primitive object in VLAS is Integrity Delta (ΔI): a change in the state of a real asset or place, relative to a baseline and within a defined window. Project types, labels, or program names are not primitives; they are labels that sit on top of Integrity Delta and the resulting credits.

Governance in the math, not around it.
Governance choices (for example, about permanence, FPIC quality, uncertainty, and eligibility) are expressed as coefficients and rules that feed into the issuance kernel and downstream filters. People approve:

• the use of a given ruleset and adapter,
• the evidence that feeds those rules, and
• the resulting proofs and positions.
• They do not quietly change numbers after the fact.

Single grammar, many renderings.
VLAS defines a single grammar (VLAS-DSL) that Sys.HAIL uses to generate calculation engines, workflows, schemas, and APIs. This ensures:

• that every conformant implementation can be traced back to the same canonical equations, and
• that changes to the standard are made once, in a governed ruleset, then propagated consistently.

Non-inflation and no double counting by design.
Allocation weights and spillover dampeners are constrained so that, taken together, they cannot create “more integrity” than the underlying change actually represents. Double counting is not merely discouraged; it is rendered mathematically and procedurally impossible when the system is correctly implemented.

Re-performability as a hard requirement.
VLAS is explicitly designed so an independent third party—using only:

• indicator packages and their provenance,
• calculation proofs,
• registry state and corporate action logs,
• admissible prices, and
• the public standard—
  can replicate the credit quantities and INAV reported for a given period.

Local reinvestment and place-level coherence.
By treating credits as expressions of underlying place integrity, VLAS is intended to support structures (such as land regenerative land trusts and place-based vehicles) where returns can be partly or wholly reinvested locally, not just extracted.

S1.1.3 What Layer 0 Achieves and What It Does Not

Layer 0 is intentionally narrow and deep:

• It does define the mandatory pipeline, artifacts, roles, equations, and invariants for turning real-world integrity into credits and INAV.
• It does define how human governance and ethics are wired into that pipeline in a way that is explicit and auditable.
• It does not prescribe:
• which specific methods, sectors, or geographies must be used,
• which capital classes a particular investor must hold, or
• how jurisdictions should treat credits in law or regulation.

Those choices live in:

• the selection and governance of methods and Adapter/Specs,
• the design of portfolios and investment mandates, and
• the regulatory regimes that choose to recognize or embed VLAS outputs.

Layer 0’s job is to make sure that once those choices are made, the system behaves in a way that is:

• deterministic,
• non-inflationary,
• transparent, and
• re-performable.

S1.2 Normative Language, Notation, and Naming (Normative)

This section outlines the semantics and grammar for making sure we speak of this using the same language and terminology.

S1.2.1 Conformance Terms

This standard uses a small set of conformance terms with precise meanings. Unless explicitly marked as “informative” or “explanatory,” text in this document is normative.

• MUST / SHALL – Required. Implementations that do not meet a “must” or “shall” requirement are not conformant.
• MUST NOT / SHALL NOT – Prohibited. Implementations that do this are not conformant.
• SHOULD / RECOMMENDED – Strongly advised. There may be valid reasons to deviate in particular circumstances, but the implications of deviation must be understood and documented.
• SHOULD NOT / NOT RECOMMENDED – Strongly discouraged.
• MAY / OPTIONAL – Truly optional. An implementation may do this or not, without affecting conformance.

When this standard uses “is designed to” or “is intended to”, it is describing design rationale, not creating a conformance requirement. When it uses “for example”, the example is illustrative, not exhaustive.

S1.2.2 Mathematical Notation and Display Equations

Normative equations in this standard are written in LaTeX-style display form, on their own line, enclosed with:

$$\ldots \text{ equation } \ldots$$

Inline references to variables and functions use plain text (for example: ΔI, α_c, β_{s→k}, v, a, P, S, U, INAV(t)).

Every display equation is followed by a “where” clause that defines all symbols used in that equation.

Equations and flows are referenced consistently as:

• L.Eq. – for equations (for example: L3.Eq.PrimaryAllocation, L4.Eq.Kernel, L8.Eq.NAV).
• L.Flow. – for formal processes (for example: L2.Flow.VerifierApproval, L8.Flow.NAVCommitteeSignoff).

Units, dimensions, and allowed ranges for all variables are defined in Section 2.

S1.2.3 Canonical Naming Scheme

This section specifies the canonical naming scheme required for interoperable VLAS implementations. Internal names MAY be used for private implementation details; however, any interface, artifact, or log that participates in VLAS governance, issuance, pricing, registry, or audit MUST expose the canonical names defined in this section.

S1.2.3.1 Canonical prefixes and formats

This subsection defines the required canonical prefixes and naming formats used to identify VLAS roles, systems/services, and data artifacts. All such identifiers MUST conform to the applicable canonical format below.

S1.2.3.2 Roles (human or organizational actors)

This subsection specifies canonical identifiers for VLAS roles, including individuals, organizations, and committees. All role identifiers MUST use the Role.Name format.

S1.2.3.3 Systems and services

This subsection specifies canonical identifiers for VLAS systems and services. All system and service identifiers MUST use the Sys.Name format.

S1.2.3.4 Data artifacts and ledgers

This subsection specifies canonical identifiers for VLAS data artifacts and ledgers. All data artifact identifiers MUST use the Data.Name format.

S1.2.3.5 Cross-reference to schema requirements

This subsection identifies where the normative schema requirements for Data.\* artifacts are defined. Schema-level definitions and minimum required fields for each Data.\* artifact are defined in Section 2.

S1.2.4 Rulesets, Versioning, and Sys.HAIL

This section specifies how VLAS logic is authored, compiled, versioned, and executed. VLAS is expressed in a Domain Specific Language (VLAS-DSL) that is consumed by Sys.HAIL. Sys.HAIL compiles VLAS-DSL into governed artifacts used for deterministic calculations, decisioning, workflow execution, schema validation, and API interoperability.

S1.2.4.1 Sys.HAIL compilation outputs

This subsection specifies the artifact types produced by Sys.HAIL and the minimum traceability metadata required for each compiled output. Each compiled bundle MUST enumerate its outputs as typed artifacts and bind them to the ruleset identifier, semantic version, and cryptographic hashes described in S1.2.4.2.

Sys.HAIL generates the following output artifact types:

Each compiled output artifact MUST carry, at minimum, artifact-level traceability metadata sufficient to support audit and historical reproducibility, including:

• a unique artifact identifier within the compiled bundle,
• an artifact type indicator (from the set above),
• association to ruleset\_id and semantic version,
• association to one or more cryptographic hashes over the source DSL and intermediate representations (S1.2.4.2).

S1.2.4.2 Ruleset definition and required metadata

This subsection defines a ruleset and the required metadata that MUST be carried with each compiled ruleset bundle.

Each compiled bundle is a ruleset and MUST carry:

• a ruleset identifier (ruleset\_id),
• a semantic version (major.minor.patch), and
• one or more cryptographic hashes over the source DSL and its intermediate representations.

S1.2.4.3 Normative execution and traceability requirements

This subsection specifies normative requirements for production execution, versioning, and historical traceability.

The following requirements apply:

• Production execution constraint. All production calculations that affect issuance, registry balances, admissible prices used for INAV, or reported NAV/INAV MUST be executed by Sys.CalcService instances generated by Sys.HAIL from approved rulesets.
• Versioning on core logic changes. Any change to a core equation, coefficient form, or decision table used in issuance or INAV requires a new ruleset version.
• Historical traceability and non-recomputation. Historical calculations MUST remain traceable to the specific ruleset version used at the time; historical results MUST NOT be silently recomputed under a new version.

S1.2.4.4 Governance pointer

This subsection identifies where governance rules for proposing, approving, and deprecating rulesets are defined.

Governance of rulesets (who can propose, approve, and deprecate them) is defined in the actor and governance sections.

S1.2.5 Capitals, Capital Classes, and Listings

This section provides pointer-level conventions for how VLAS refers to capital domains, capital classes, and listings. VLAS recognizes five capital domains and defines capital classes and listings within them. This section uses these terms without re-defining them.

S1.2.5.1 Conventions used in Section 1

This subsection specifies the notation conventions used in Section 1 when referring to (a) capital domains, (b) capital classes, and (c) listings.

(a) Capital domains and single-letter domain aliases

References to capital domains (Natural, Human, Social, Manufactured, Financial) use single-letter codes N, H, S, M, F when needed in equations or diagrams. These single-letter codes are domain aliases and are not capital class identifiers.

(b) Capital classes and class-family codes

Capital classes are written as a class-family code plus class name (for example: NCU.Coastal, HCU.Health). Class-family codes (e.g., NCU, HCU) are distinct from the single-letter domain aliases (N, H, S, M, F). The single-letter domain aliases MUST NOT be used as class-family codes.

(c) Listings and listing windows

Listings are identified by a pair (``capital.class``, window). In prose, they may appear as <``capital.class``>.<window> (for example: NCU.Coastal.2026Q2).

S1.2.5.2 Cross-reference to formal definitions

This subsection identifies where the formal definitions are specified.

The formal definitions of:

• capital domains,
• capital classes, and
• listing windows and identifiers

are given in Section 2; Section 1 uses these terms without re-defining them.

S1.3 Sensor-to-NAV Overview (Normative)

This subsection gives the high-level narrative for how VLAS takes changes in real-world integrity and turns them into a signed, finance-grade Integrity Net Asset Value (INAV). The details of each step are expanded in S1.4 and in later sections; here we establish the core storyline that must be preserved in any conformant implementation.

Figure 5 — End-to-end control flow from field measurement to published INAV, with canonical artifacts.

At a high level, the VLAS Sensor-to-NAV pipeline works as follows:

• Real-world change is measured.
  Stewards and measurement systems observe changes in the real world: in ecosystems, in human health and education, in social cohesion and governance, in built infrastructure, and in financial buffers. These are method-specific measurements in native units (for example, tonnes of CO₂e per hectare, mg NO₃/L, attendance rates, or physical condition indices).

• Measurements are normalized into Integrity and vetted at Gate 1.
  Method-specific outputs are mapped into a canonical Integrity construct via an VLAS AdapterSpec and then bundled, with full provenance and evidence, into a Data.IndicatorPackage. A Role.Steward submits this package; a Role.Verifier checks it at Gate 1 for method conformance, QA/QC, and governance (including FPIC where applicable).

• Integrity Delta is routed across the Five Capitals.
  The verified Integrity Delta (ΔI) for an asset and window is allocated across Natural, Human, Social, Manufactured, and Financial Capitals using explicit allocation weights and dampeners defined in the AdapterSpec, producing a capital-tagged vector of potential credits.

• Time, stewardship, and uncertainty are encoded into coefficients.
  VLAS does not assume that every unit of potential credit is equal. The Temporal Engine computes coefficients that encode:

  • how fast things are changing (velocity and acceleration),
  • how durable improvements are (permanence),
  • how well they are stewarded (including FPIC quality), and
  • how uncertain the measurements are.

• The issuance kernel converts Integrity into credits and proof, at Gate 2.
  The Issuance Engine applies the core issuance kernel to ΔI and the coefficient set, producing a set of credit quantities Q by capital, class, asset, and window. This computation, along with its inputs, hashes, and equation references, is captured in Data.CalcProof and approved or rejected at Gate 2.

• Credits are recognized, held, transferred, and retired in a registry.
  Approved credit quantities are recognized as Capital Unit Tokens in Sys.Registry, with all lifecycle changes (ISSUE, RELEASE_U, TRANSFER, RETIRE, BURN) recorded as Data.CorporateAction entries. The registry defines what is circulating at any given time.

• Prices are drawn from admissible venues and benchmarks.
  Sys.PricingEngine computes admissible prices for each lot using L7.Eq.Mark, based on trading venues and benchmark curves defined in the standard and in configuration. Only these prices are allowed to enter INAV calculations.

• INAV and portfolio views are calculated and signed at Gate 3.
  Sys.NAVService combines circulating quantities and admissible prices to compute INAV and related breakdowns. These are assembled in Data.NAVSnapshot and Data.MonthlyAuditPack and reviewed at Gate 3 by Role.NAVCommittee, which signs or rejects them.

Core Pipeline Invariants:

• Determinism: Given the same data and rules, the same results must be produced.
• Non-inflation: No combination of allocations and spillovers may create more integrity than is actually present.
• Governance in the math: Ethical and governance decisions are expressed as coefficients and rules, not as ad hoc overrides.
• Human-in-the-loop where it matters: Data, proofs, and INAV are approved by humans at defined gates; numbers are not edited by hand.

S1.4 Sensor-to-NAV Control Flow (Normative, Expanded)

This section defines the full, end-to-end control flow from raw field measurements to a signed, finance-grade Integrity Net Asset Value (INAV) position. It binds the eight technical layers, the three Human-in-the-Loop (HITL) gates, and the canonical artifacts into a single, deterministic pipeline.

At a high level, every VLAS implementation MUST follow this chain.

S1.4.1 Field Measurement (Layer 1 – Sensors and Stewards)

Raw metrics are gathered in place: sensor streams, field plots, lab results, community surveys, and governance artifacts (for example, FPIC documents and local agreements). These measurements are method-specific and may be in any native units, such as:

• tonnes of CO₂e per hectare,
• concentrations like mg NO₃/L,
• biodiversity or species richness scores,
• human health or education scores,
• infrastructure condition indices.

At this stage, integrity has not yet been computed in VLAS terms. This is the “pre-standard” world. Methods and AdapterSpecs govern how these measurements will eventually be interpreted, but the raw data remain in their native form.

S1.4.2 Gate 1 — Package Verification (Layer 2, L2.Flow.VerifierApproval)

All raw data and evidence are assembled into a Data.IndicatorPackage. At a minimum, this package includes:

• indicators.json – measured values, units, timestamps, and QA flags,
• provenance.json – devices, labs, stewards, methods, locations, and baselines,
• attachments/ – supporting evidence (for example, lab certificates, shapefiles, photos, community meeting notes),
• bundle_hash – a cryptographic hash over the package contents,
• adapter_id and adapter_version – identifying the AdapterSpec used to interpret the data.

A Role.Steward prepares and submits the package into the workflow engine (Sys.Camunda). Sys.Camunda assigns it to an independent Role.Verifier for Gate 1.

At Gate 1, Role.Verifier MUST:

• confirm that the data conform to the declared AdapterSpec (correct indicators, units, cadences, sampling frame, and baselines);
• perform QA/QC checks, including range checks, completeness, and consistency;
• verify that all required evidence is present and matches the claims made;
• verify FPIC (Free, Prior, and Informed Consent) status where applicable, or document why it is not required.

If any check fails, the package is quarantined or rejected and MUST NOT proceed. On success, the Verifier signs the bundle_hash and FPIC status. The signed IndicatorPackage becomes the only admissible ingress to the calculation layers.

S1.4.3 Calculation Layers (Layers 3–5) — From Integrity to Credit Quantity

The signed IndicatorPackage flows through the core calculation stack. This stack is deterministic and is generated from rulesets by Sys.HAIL.

Figure 6 — Each term is a fiduciary control. The formula itself manufactures quality.

Layer 3 — Capital Router (The “Allocator”)

Layer 3 takes the verified Integrity Delta (ΔI) for an asset and window and allocates it across the Five Capitals using:

• allocation weights α (alpha) for primary allocations, and
• spillover dampeners β (beta) for co-benefit routes between capitals.

Both α and β are defined for each method in the corresponding Data.AdapterSpec.

Layer 3 MUST obey non-inflation constraints on α and β and MUST output a vector of capital-tagged quantities, such as {Q_NCU, Q_HCU, Q_SCU, Q_MCU, Q_FCU}, where each Q_* represents a quantity of potential credits in a specific capital domain and class.

Layer 4 — Temporal Engine (The “Durability & Stewardship Calculator”)

Layer 4 receives the capital-tagged quantities from Layer 3 and computes five coefficients for each capital, class, and window:

• v – velocity of change,
• a – acceleration or deceleration of change,
• P – permanence or durability,
• S – stewardship and governance quality (including FPIC quality),
• U – uncertainty.

This layer “qualifies the quantitative” by encoding:

• how quickly integrity is changing,
• whether the trend is improving, stalling, or reversing,
• how durable the improvement is expected to be,
• how well it is being stewarded and by whom, and
• how certain or uncertain the measurement and modeling are.

These coefficients are later consumed by the issuance kernel.

Layer 5 — Issuance Engine (The “Kernel”) and Gate 2

Layer 5 applies the core issuance kernel over:

• the Integrity Delta ΔI, and
• the coefficient vector (v, a, P, S, U) for each capital, class, and window,

to produce final credit quantities Q for each asset·capital·window.

The Issuance Engine packages the inputs, parameter values, and outputs into a Data.CalcProof, which contains:

• ruleset_id and ruleset_version,
• adapter_id and adapter_version,
• hashes of the input IndicatorPackage and any intermediate artifacts,
• values for ΔI, v, a, P, S, U used in the calculation,
• references to the specific equations used (for example, L4.Eq.Kernel),
• outputs (credit quantities Q by capital, class, asset, window),
• test and guard results,
• signatures from Sys.HAIL or Sys.CalcService components involved.

Data.CalcProof is then routed to a Role.Verifier (or a designated Gate 2 approver) for Gate 2 — Calc Proof Approval.

At Gate 2, the approver MUST attest that:

• the correct ruleset and adapter versions were used,
• the correct data bundle (by hash) was used,
• all golden tests and guards passed, and
• there is no evidence of tampering or misconfiguration.

The approver does not recompute the math by hand, but they MAY run automated re-performance tools. Only a signed Data.CalcProof may be forwarded to the Registry for recognition; an unsigned or rejected CalcProof MUST NOT produce credits.

S1.4.4 Recognition and Lifecycle (Layer 6 — Credit Router & Registry)

Layer 6 performs two functions: lot formation (routing recognized credits into market-ready lots per the project’s governance policy) and registry (recording lot state and processing lifecycle events). The formation function executes the lot formation policy from Data.PLOP; the registry function maintains the immutable ledger.

The Registry (Sys.Registry) recognizes credits strictly on the basis of an approved Data.CalcProof and the lot formation policy declared in the project’s Data.PLOP. For each approved proof, it creates one or more Data.CUTMetadata records representing Capital Unit Token lots. Each Data.CUTMetadata record includes, at minimum:

• a unique lot identifier,
• plop_id and plop_version referencing the governing Data.PLOP,
• lot_formation_strategy referencing the formation rules applied,
• capital.class (for example, NCU.Coastal),
• window (for example, 2026Q2),
• quantity Q,
• lot-level quality attributes (lot_level_U, lot_level_P, lot_level_S, uncertainty_tier),
• references or hashes linking back to Data.CalcProof and Data.IndicatorPackage,
• ruleset_id and adapter_id used for issuance,
• current status (for example, ISSUED, HELD_U, HELD_BUFFER, CIRCULATING, RETIRED, BURNED),
• holdback_fraction and buffer_lot_ref (if applicable),
• place_ids of all contributing places,
• additional attributes as required by the standard and governance.

All changes in a lot’s state are expressed as corporate actions, captured as Data.CorporateAction entries. The allowed actions include:

• ISSUE – creation of credits from an approved CalcProof,
• RELEASE_U – release of quantity previously held back due to uncertainty,
• TRANSFER – movement of credits between holders,
• RETIRE – permanent removal of credits from circulation to reflect use or obligation fulfillment,
• BURN – removal of credits for integrity reasons (for example, reversal or fraud).
• RELEASE_BUFFER – release of buffer pool credits into circulation when reversal risk is resolved, or consumption of buffer when a reversal occurs.

Circulation is defined purely by these actions; there is no “shadow state” outside the Registry. At any time t, circulating quantity for a class, window, and lot is the net result of all corporate actions up to t.

Layer 6 is the ledger of record for ownership and lifecycle.

S1.4.4a Lot Formation Framework (Normative)

The step between an approved Data.CalcProof and a recorded lot is not passive. Lot formation determines how recognized credits are grouped, tiered, and structured at registry entry. Because the lot is the unit that gets priced, traded, and reported in INAV, the rules governing lot formation are a primary exploit surface for greenwashing. Poorly structured lots can launder uncertainty, obscure governance failures, or defeat the quality signals that the issuance kernel was designed to produce.

Lot formation is governed by the lot formation policy declared in the project’s Data.PLOP (see S1.0.5(e)). The policy is set at project establishment — before any measurement or issuance occurs — and is immutable within a measurement window. The pipeline does not decide how lots are formed; it executes the formation rules that the place’s governance framework already defined.

Governing Principle: Lot formation MUST preserve the quality differentiation that the issuance kernel creates. No combination of grouping, pooling, or tiering rules may obscure material differences in uncertainty, governance, permanence, geography, or capital class among the credits within a single lot.

Lot Formation Axes

A conformant implementation MUST support lot formation along the following axes. A single lot MAY be defined by the intersection of multiple axes, but every credit within a lot MUST share the same values on all axes used to define it.

1. Capital class. Credits from different capital classes (e.g., NCU vs. HCU) SHALL NOT be combined in the same lot. This extends the fungibility firewall to the point of lot creation. Within a capital domain, credits from different class families (e.g., NCU.Coastal vs. NCU.Soil) MAY be combined only if the governing AdapterSpec explicitly permits it and the combined lot carries the quality attributes of its weakest constituent.

2. Uncertainty tier. Credits with materially different uncertainty levels SHALL NOT be pooled into a single lot without disclosure. A conformant implementation MUST define uncertainty tier boundaries (for example: Tier 1: U ≤ 0.10; Tier 2: 0.10 < U ≤ 0.25; Tier 3: U > 0.25) and MUST assign each credit to a tier at the point of lot formation. Tier boundaries are declared in the AdapterSpec and MUST be stable within a window. A lot that combines credits across uncertainty tiers MUST carry the highest (worst) U value of any constituent credit as its lot-level uncertainty attribute, and MUST disclose the tier distribution in its Data.CUTMetadata.

3. Geographic scope. Credits MUST carry a place_id (or set of place_ids) linking them to a verified geographic boundary. Lots MAY aggregate credits across places only when: (i) the aggregation is authorized by the governance of each contributing place, (ii) the lot metadata discloses all contributing place_ids, and (iii) the lot does not cross jurisdictional or ecological boundaries that would make the aggregation misleading (for example, combining a coastal mangrove project with an alpine reforestation project under a single “Natural Capital” lot without disclosing the geographic diversity).

4. Window (vintage). All credits within a lot MUST reference the same measurement window. Cross-window aggregation is permitted only for multi-window contracts (for example, a 5-year offtake agreement), and the lot metadata MUST disclose the window range and per-window quantities. Stale credits (from windows older than a governance-defined threshold) SHALL NOT be mixed with current-window credits without explicit disclosure.

5. Governance and stewardship provenance. Credits from places with different governance structures, FPIC status, or stewardship quality (S coefficient) MUST NOT be pooled into a single lot in a way that obscures these differences. A lot combining credits with S = 1.0 (full FPIC, strong governance) and S = 0.7 (partial governance) MUST carry the lower S value as its lot-level stewardship attribute and MUST disclose the distribution.

6. Permanence band. Credits with materially different permanence profiles (P coefficient) MUST NOT be pooled without disclosure. A lot that combines credits with P = 0.95 (30-year covenant, ecologically stable) and P = 0.60 (5-year covenant, high reversal risk) MUST carry the lower P as its lot-level permanence attribute.

Holdback and Staged Release

When credits are recognized, the lot formation step MUST determine the initial allocation between CIRCULATING and HELD_U states:

• The holdback fraction MUST be declared in the AdapterSpec or by place governance and MUST be at least as conservative as the lot-level uncertainty tier implies.
• A lot MAY be formed entirely in HELD_U state with a defined release schedule, where RELEASE_U corporate actions are triggered by subsequent verification events that reduce uncertainty.
• The release schedule (if any) MUST be recorded in the lot’s Data.CUTMetadata at the time of formation and MUST NOT be altered retroactively without a governance-approved corporate action.

Buffer Pool Contributions

Where a method or governance framework requires a buffer pool contribution (credits set aside against reversal risk), the contribution MUST be:

• deducted at the point of lot formation, not after,
• recorded as a separate lot in HELD_BUFFER state (or equivalent) with its own lot identifier,
• governed by explicit release or burn rules declared in the AdapterSpec,
• disclosed in the lot’s Data.CUTMetadata as a linked buffer reference.

Buffer pool deductions MUST NOT be applied invisibly. The relationship between the primary lot and its buffer lot MUST be auditable from the Data.CUTMetadata of either lot.

Anti-Greenwashing Constraints

The following practices are prohibited:

• Quality laundering: Pooling high-uncertainty and low-uncertainty credits into a single lot and marketing the blended lot at the low-uncertainty price.
• Governance washing: Combining FPIC-compliant and non-compliant credits into a single lot without disclosing the governance mix.
• Vintage laundering: Mixing stale-window and current-window credits to obscure the age of underlying measurements.
• Geographic obfuscation: Creating lots that aggregate across ecologically or jurisdictionally unrelated places without disclosure, making the lot appear more diversified or robust than its constituents warrant.
• Permanence inflation: Pooling short-covenant and long-covenant credits and marketing the blended lot at the long-covenant permanence level.

A conformant implementation MUST enforce these constraints at the registry level. The Registry SHALL reject lot formation requests that violate them.

Lot-Level Attributes

Every lot MUST carry, in its Data.CUTMetadata, the following lot-formation attributes in addition to those already specified in S1.4.4:

• lot_formation_strategy: identifier referencing the formation rules applied (from AdapterSpec or governance),
• uncertainty_tier: the tier assigned at formation,
• lot_level_U: the effective uncertainty of the lot (worst-case of constituents, or blended with disclosure),
• lot_level_P: the effective permanence of the lot,
• lot_level_S: the effective stewardship quality of the lot,
• place_ids: all contributing places,
• window_range: the window or window range,
• holdback_fraction: the fraction initially placed in HELD_U,
• buffer_lot_ref: reference to any linked buffer pool lot (if applicable),
• constituent_calcproof_refs: hashes of all contributing CalcProofs.

Audit test: A reasonably competent auditor MUST be able to reconstruct why a lot was formed the way it was — which CalcProofs contributed, what formation rules applied, and why the lot-level quality attributes are what they are — using only the lot’s Data.CUTMetadata and the referenced AdapterSpec.

S1.4.5 Pricing and Admissible Marks (Layer 7 — Pricing & Venue)

Layer 7 determines the admissible price P for each credit lot that may be used in INAV and other financial reporting.

Sys.PricingEngine:

• consumes on-venue market data, such as volume-weighted average prices from designated exchanges, and
• applies benchmark curves or anchor values where needed (for example, social cost curves),

using a canonical pricing equation L7.Eq.Mark.

A price is admissible for INAV only if:

• it is derived from venues and benchmarks that are explicitly configured and recognized by the standard and governance, and
• it is produced by Sys.PricingEngine in accordance with L7.Eq.Mark.

“Hand-set” prices, opaque internal model outputs that are not derived from the canonical inputs, or prices that cannot be traced back to approved venues and benchmarks are explicitly forbidden for INAV. They MAY be used for internal scenario analysis but MUST NOT be used in reported INAV.

S1.4.6 Reporting, INAV, and Gate 3 (Layer 8 — Portfolio & Reporting)

Layer 8 composes the portfolio view and computes INAV from:

• circulating quantities in Sys.Registry, and
• admissible prices from Sys.PricingEngine.

Sys.NAVService:

• aggregates positions by capital, class, listing window, and holder,
• reconciles all positions to registry actions,
• applies eliminations and cross-walks for external reporting frameworks,
• computes INAV and related portfolio metrics, and
• assembles Data.NAVSnapshot and Data.MonthlyAuditPack.

Data.MonthlyAuditPack typically includes:

• one or more NAV snapshots,
• a capital balance sheet,
• position reconciliations,
• price sources and marks,
• exceptions, overrides, and restatements (if any),
• signatures from Role.NAVCommittee and other required actors.

A Role.NAVCommittee performs Gate 3 — NAV Committee Signoff, which involves:

• reviewing the Monthly Audit Pack,
• checking that price sources are admissible and consistent with policy,
• confirming that positions reconcile to registry and corporate actions,
• assessing any exceptions or restatements, and
• signing the Monthly Audit Pack and capital balance sheet.

Only after Gate 3 is INAV recognized for external reporting for that period.

S1.4.7 Mathematical Definition of INAV

For a given reporting date t, the system-level Integrity Net Asset Value (INAV) is defined as:

$$INAV(t)=\sum_{\text{capital, class, window, lot}} {\text{circulating\_quantity}\left( \text{capital, class, window, lot},t \right) \times \text{admissible\_price}(\text{capital, class, window, lot},t)}$$ where:

• circulating_quantity(capital, class, window, lot, t) is the net quantity after all ISSUE, RELEASE_U, TRANSFER, RETIRE, and BURN actions recorded in the Registry up to time t;
• admissible_price(capital, class, window, lot, t) is the unique L7.Eq.Mark output for that lot, derived from canonical venues and/or benchmark curves for the relevant window;
• the summation is performed separately for each capital domain (N, H, S, M, F) and then aggregated to form the full INAV vector and any composite views.

This definition MUST be reproducible from:

• the Data.MonthlyAuditPack for the relevant reporting period, and
• the underlying registry and pricing logs.

Any restatement of previously reported INAV(t) MUST be implemented via:

• explicit corporate actions and/or pricing corrections, and
• an updated NAVSnapshot and MonthlyAuditPack,

not by silently overwriting historical numbers.

S1.4.8 Human-in-the-Loop Principle

Across the Sensor-to-NAV pipeline, VLAS enforces the following invariant:

Humans approve or deny decisions with evidence links; humans never directly edit numeric outputs from calculators.

Concretely:

• At Gate 1, Role.Verifier approves or rejects IndicatorPackages.
• At Gate 2, the designated approver approves or rejects CalcProofs.
• At Gate 3, Role.NAVCommittee approves or rejects the Monthly Audit Pack and INAV.

All such interventions MUST be recorded as signatures over artifacts (for example, hashes of packages, proofs, or packs), with timestamps and role identifiers. All numeric transformations (for example, application of equations, coefficients, and guards) MUST occur in HAIL-generated, test-hardened calculation services under versioned rulesets.

S1.5 Canonical Artifacts (Normative)

This subsection defines the canonical artifacts that tie the VLAS layers together. They are the “hard edges” of the system: if two independent teams implement the same artifacts and flows correctly, they will produce the same results from the same inputs.

Figure 7 — Six artifacts with hash-linked provenance from method configuration to audit assurance.

For each artifact, this section defines:

• purpose and scope,
• where it sits in the Sensor-to-NAV pipeline,
• minimum required contents at Section 1 level, and
• how it is linked to other artifacts.

Field-level schemas, data types, and allowed values are defined in Section 2.

S1.5.0 Data.PLOP (Project Level Operations Policy)

Purpose: The Project Level Operations Policy (PLOP) is the governance foundation for all pipeline activity at a place. It records the community-approved governance framework, policy vector, lot formation rules, baselines, and allowed uses that govern every downstream artifact. No VLAS pipeline activity SHALL occur without a registered, hash-anchored Project Level Operations Policy (PLOP).

Pipeline position: Pre-pipeline. The PLOP is established before any Data.AdapterSpec is bound to a place and before any Data.IndicatorPackage is submitted. It is the root of the provenance chain.

Minimum Contents (Section 1 Level):

• plop_id: unique identifier (UUID).
• plop_version: version number, incremented on governance-approved amendments.
• plop_hash: SHA-256 hash of the PLOP contents at this version.
• place_id: linked geographic place(s) with polygon boundaries and CRS.
• governance_body: identity and authority of the LRLT or equivalent.
• fpic_status: current FPIC state (valid, not_required, revoked, disputed) with attestation date and evidence references.
• policy_vector_w_star: target capital shares {α_N, α_H, α_S, α_M, α_F}.
• gate_floors: {S_min, P_min, U_max} — eligibility thresholds for this place.
• adapter_ids: list of approved AdapterSpecs bound to this place.
• baseline_refs: references to baseline data packages with methodology and uncertainty.
• lot_formation_policy: the complete allowed-uses framework (see S1.0.5(e) and S1.4.4a).
• cash_routing_rules: distribution waterfall for credit proceeds.
• measurement_schedule: planned data collection and verification frequency.
• amendment_log: history of all changes with prior version hashes, approval signatures, and effective dates.

Linkage: Every downstream artifact (Data.AdapterSpec binding, Data.IndicatorPackage, Data.CalcProof, Data.CUTMetadata) MUST reference the plop_id and plop_version under which it was produced. If the PLOP version changes mid-window, a conformant implementation MUST document which artifacts were produced under which version.

S1.5.1 Data.AdapterSpec (Method Adapter Specification)

Purpose

Data.AdapterSpec defines how a specific method maps its outputs into VLAS Integrity and capital allocations. It is the contract between “method world” and “VLAS world”.

Each method that participates in VLAS MUST have exactly one active AdapterSpec version in use at any given time.

Layer and Flow Context

• Defined at design time (Layer 1 / Layer 3 configuration).
• Used by:
  • Layer 1 to convert method outputs into Integrity and ΔI,
  • Layer 3 to allocate ΔI across capitals using α and β,
  • Layer 4 and Layer 5 to derive or interpret relevant coefficients.

Minimum Contents (Section 1 Level)

At a minimum, Data.AdapterSpec SHALL include:

• method identification: method name, URI, version, and lineage;
• indicator definitions: names, expected units, cadences, and baselines;
• mapping from method outputs to:
  • Integrity_before, Integrity_after, and Integrity Delta ΔI,
  • primary capital domain(s) and any allowed spillover routes;
• allocation parameters:
  • allocation weights α_c (per capital),
  • spillover dampeners β_{s→k} (per allowed route);
• temporal and governance hooks:
  • references or parameterization needed to compute v, a, P, S, U;
• versioning and governance:
  • adapter_id, semantic version, and approval signatures (for example, from Role.GovernanceCommittee or equivalent).

Linkages

• Bound to Data.IndicatorPackage via adapter_id and adapter_version.
• Referenced by Data.CalcProof to show which adapter was used.
• May be referenced in Data.NAVSnapshot and Data.MonthlyAuditPack for transparency.

Any change to the mapping logic, α/β values, or temporal/gov hooks MUST result in a new AdapterSpec version.

S1.5.2 Data.IndicatorPackage (Canonical Ingest Bundle)

Purpose

Data.IndicatorPackage is the canonical bundle of:

• measurement indicators,
• provenance,
• governance evidence (including FPIC where applicable), and
• method configuration

submitted for evaluation at Gate 1. It is the only admissible way for field data to enter the VLAS calculation layers.

Layer and Flow Context

• Produced by Role.Steward and Sys.Sensors at Layer 1.
• Validated by Role.Verifier at Layer 2 (Gate 1).
• Referenced by all downstream artifacts via bundle_hash or equivalent.

Minimum Contents (Section 1 Level)

At a minimum, Data.IndicatorPackage SHALL include:

• identifiers:
  • package_id,
  • adapter_id and adapter_version,
  • asset or site identifiers,
  • time window(s) or observation periods;
• indicators:
  • indicator names, values, units, timestamps, QA flags;
• provenance:
  • devices, labs, actors, and methods involved,
  • sampling frames and baselines used;
• governance evidence:
  • FPIC status and supporting evidence (where applicable),
  • any local agreements or governance artifacts required by the method;
• hashing and signatures:
  • bundle_hash over all contents,
  • one or more steward signatures attesting to the submission.

Gate 1 Outcome

At Gate 1, Role.Verifier:

• checks the package against the relevant AdapterSpec,
• verifies QA/QC and governance requirements, and
• either:
  • signs the bundle_hash (and records FPIC status) – “approved”, or
  • rejects or quarantines the package – “not approved”.

Only approved IndicatorPackages are allowed to proceed to the calculation layers. The Gate 1 decision and signature become part of the artifact’s record.

S1.5.3 Data.CalcProof (Issuance Calculation Proof)

Purpose

Data.CalcProof is the canonical record that a specific issuance calculation took place under a specific ruleset and adapter, using specific input data. It is the evidence that connects:

• the logic (ruleset),
• the data (IndicatorPackage and coefficients), and
• the outputs (credit quantities Q).

No credits may be recognized without a corresponding, approved CalcProof.

Layer and Flow Context

• Produced by Sys.CalcService at Layer 5 (Issuance Engine).
• Reviewed at Gate 2 by a designated approver (often Role.Verifier in an issuance-specific role, or a delegated governance role).
• Consumed by Sys.Registry at Layer 6 to recognize credits.

Minimum Contents (Section 1 Level)

At a minimum, Data.CalcProof SHALL include:

• identification:
  • calc_proof_id,
  • ruleset_id and ruleset_version,
  • adapter_id and adapter_version;
• input references:
  • bundle_hash of the Data.IndicatorPackage used,
  • any references to derived coefficients (v, a, P, S, U) and their source;
• parameterization:
  • the specific parameter values used in L3.Eq.*, L4.Eq.Kernel, and any relevant guards;
• outputs:
  • credit quantities Q by capital, class, asset, and window;
• verification data:
  • hashes of intermediate artifacts,
  • test results (for example, golden test IDs and pass/fail outcomes),
  • any warnings or advisory flags;
• signatures:
  • signatures from the Sys.CalcService or signing authority,
  • Gate 2 approver signature and decision (approved / rejected).

Gate 2 Outcome

At Gate 2, the approver SHALL:

• confirm that ruleset_id and adapter_id are correct and appropriate,
• confirm that bundle_hash matches an approved IndicatorPackage,
• confirm that all required tests and guards passed,
• sign or reject the CalcProof.

Only approved CalcProof artifacts may be sent to the Registry to recognize credits. A rejected CalcProof MUST NOT result in issuance.

S1.5.4 Data.CUTMetadata (Capital Unit Token Metadata)

Purpose

Data.CUTMetadata defines a lot of VLAS-recognized credits (Capital Unit Tokens). It is the primary object in the registry that describes what has been issued, under what conditions, and how it can move.

Layer and Flow Context

• Created by Sys.Registry at Layer 6 upon ISSUE (or equivalent) corporate actions, based on an approved CalcProof.
• Updated only via corporate actions (for example, RELEASE_U, TRANSFER, RETIRE, BURN).

Minimum Contents (Section 1 Level)

At a minimum, Data.CUTMetadata SHALL include:

• identifiers:
  • lot_id,
  • capital.class (for example, NCU.Coastal),
  • listing window (for example, 2026Q2),
  • asset or asset group references;
• issuance context:
  • quantity Q issued,
  • ruleset_id and adapter_id used,
  • references to calc_proof_id and bundle_hash;
• current state:
  • status (e.g., ISSUED, CIRCULATING, RETIRED, BURNED),
  • holder information (or “pool” if held in a common account),
  • any fractional partitions or tags required by downstream systems;
• governance attributes:
  • flags related to permanence, S (stewardship) bands, U (uncertainty) bands, or other quality tiers, if applicable.

The combination of Data.CUTMetadata and the corporate action log defines, at any time t, the circulating quantity and distribution of VLAS-recognized credits.

S1.5.5 Data.CorporateAction (Lifecycle Log Entry)

Purpose

Data.CorporateAction records every state change of a credit lot. It is the canonical ledger of:

• what happened,
• to which lot,
• in what quantity,
• at what time, and
• under whose authority.

Layer and Flow Context

• Created and maintained by Sys.Registry at Layer 6.
• Consumed by Sys.NAVService (Layer 8), Sys.Audit tooling, and external auditors.

Minimum Contents (Section 1 Level)

At a minimum, each Data.CorporateAction entry SHALL include:

• identifiers:
  • corporate_action_id,
  • lot_id or listing_id,
  • action_type (ISSUE, RELEASE_U, TRANSFER, RETIRE, BURN, and any other standardized actions);
• quantitative impact:
  • quantity_change (positive or negative),
  • resulting balance (if the registry maintains this on each entry);
• context:
  • timestamp,
  • initiator (role and identity),
  • authorization reference (for example, contractual basis, program rule, or governance decision);
• linkage:
  • references to CalcProof, IndicatorPackage, or other artifacts when relevant.

The complete, ordered set of Data.CorporateAction entries for all lots defines the system’s state at any given time, and is the basis for computing circulating quantities Q_{c,w}(t).

S1.5.6 Data.NAVSnapshot and Data.MonthlyAuditPack (INAV and Assurance Bundle)

Purpose

Data.NAVSnapshot and Data.MonthlyAuditPack are the top-level artifacts for:

• reporting INAV and related portfolio metrics, and
• providing sufficient information for independent re-performance.

Layer and Flow Context

• Produced by Sys.NAVService at Layer 8.
• Reviewed and signed at Gate 3 by Role.NAVCommittee.
• Consumed by Role.Auditor, Role.Regulator, and capital providers.

Data.NAVSnapshot – Minimum Contents (Section 1 Level)

A single NAVSnapshot SHALL include:

• timestamp and reporting period,
• INAV(t) and any required decompositions by:
  • capital domain,
  • capital.class,
  • listing window;
• portfolio views as required (for example, by vehicle, lane, or segment);
• references to:
  • registry positions and corporate action logs used,
  • pricing inputs and L7.Eq.Mark outputs used;
• summary of any exceptions, overrides, or restatements applied during the period.

Data.MonthlyAuditPack – Minimum Contents (Section 1 Level)

A MonthlyAuditPack (or equivalent period pack) SHALL include:

• at least one Data.NAVSnapshot for the period,
• a capital balance sheet and holdings breakdown,
• extracts or references sufficient to reconstruct:
  • quantities by class and window,
  • admissible prices by class and window,
  • the INAV(t) calculation (L8.Eq.NAV);
• logs and artifacts related to:
  • key calculations (for example, summary of relevant CalcProofs and their rulesets),
  • corporate actions during the period,
  • price sources and benchmarks used,
  • restatements or corrections, if any;
• signatures:
  • Role.NAVCommittee signoff,
  • any additional required governance signatures.

The audit pack MUST be sufficient for an independent third party, using the public standard and the pack’s contents, to re-perform:

• credit quantity calculations for the period,
• INAV(t) for the period, and
• consistency checks between registry, pricing, and reported figures.

S1.6 Actor Lattice and Responsibilities (Normative)

Layer 0 specifies not only the data and equations, but also the actor lattice: the minimum set of human roles and system components, and how they interact across the Sensor-to-NAV pipeline.

This section defines:

• the core human roles (Role.*),
• the core system components (Sys.*), and
• how responsibility, authority, and accountability are distributed across layers and gates.

Detailed role descriptions, access controls, and organizational mappings are specified in Section 2 and in governance annexes. Section 1 defines the architecture-level requirements.

S1.6.1 Overview: Roles, Systems, and Gates

At a high level, VLAS acts through:

Figure 8 — Human roles (left), system components (right), with three governance gates connecting them.

• Human roles (Role.*)
  who propose, submit, review, approve, or challenge data and results;

• System components (Sys.*)
  that execute deterministic logic, manage workflows, store state, and calculate outputs; and

• Gates (Gate 1, Gate 2, Gate 3)
  where approvals or rejections are made based on evidence and rules.

The core principle is:

Human actors are responsible for evidence, configuration, and approval; system components are responsible for deterministic computation and record-keeping.

Humans do not hand-edit calculated quantities; systems do not make governance decisions without explicit configuration and oversight.

S1.6.2 Core Human Roles (Role.*)

This subsection defines the core human roles that must exist in any conformant VLAS implementation. In practice, one legal entity may perform several roles (subject to separation-of-duty constraints), or a role may be fulfilled by multiple individuals or organizations.

Role.Steward

Role.Steward is responsible for a place, asset, or program that participates in VLAS-governed programs. Key responsibilities include:

• implementing or overseeing measurement activities in accordance with approved methods and AdapterSpecs;
• preparing and submitting Data.IndicatorPackage bundles, including indicators, provenance, and governance evidence;
• responding to Verifier questions and clarifications;
• implementing stewardship commitments associated with credits (for example, maintenance of restored ecosystems).

Role.Steward does not approve their own data for issuance; that is the responsibility of Role.Verifier.

Role.Verifier

Role.Verifier is an independent role responsible for checking data and calculations against the standard and approved configurations. Key responsibilities include:

• conducting Gate 1 reviews of Data.IndicatorPackage, including method conformance, QA/QC, and FPIC (where applicable);
• conducting Gate 2 reviews of Data.CalcProof, including ruleset, adapter, and data lineage checks;
• documenting acceptance or rejection, with reasons;
• escalating issues to Role.GovernanceCommittee when systemic or method-level problems are discovered.

Role.Verifier shall not be the same person or team that prepared the IndicatorPackage, except in tightly controlled pilot scenarios explicitly flagged as such.

Role.GovernanceCommittee

Role.GovernanceCommittee is responsible for the integrity and evolution of VLAS itself within a given deployment or trust. Key responsibilities include:

• approving or rejecting new or revised rulesets and AdapterSpecs;
• setting policies on acceptable methods, capital classes, and parameter ranges;
• defining and updating the criteria for Verifiers and NAV Committee members;
• overseeing systemic risk, including monitoring of restatements, reversals, and fraud;
• initiating suspension or deprecation of methods, rulesets, or credit classes when warranted.

Role.GovernanceCommittee does not approve individual IndicatorPackages (Gate 1) or individual CalcProofs (Gate 2), except where explicitly delegated and documented.

Role.NAVCommittee

Role.NAVCommittee is responsible for reviewing and signing off on portfolio-level and system-level results at Gate 3. Key responsibilities include:

• reviewing Data.NAVSnapshot and Data.MonthlyAuditPack for each reporting period;
• checking consistency between registry positions, pricing inputs, and reported INAV;
• reviewing any exceptions, overrides, or restatements before signoff;
• approving or rejecting the pack and INAV for the period;
• documenting decisions and rationales, including conditions for approval.

The NAV Committee’s signoff is the final human approval before INAV is treated as official for that period.

Role.Registrar

Role.Registrar is responsible for operating Sys.Registry and ensuring that all corporate actions are properly recorded and authorized. Key responsibilities include:

• implementing and enforcing processes for ISSUE, RELEASE_U, TRANSFER, RETIRE, and BURN;
• ensuring that all corporate actions are traceable to valid approvals (for example, approved CalcProofs, legal agreements, or program rules);
• maintaining registry integrity, including identity and access management for accounts;
• providing registry extracts and logs to Role.NAVCommittee, Role.Auditor, and Role.Regulator as needed.

Role.Registrar does not decide how many credits are issued; issuance quantities come from approved CalcProofs.

Role.Auditor

Role.Auditor is an independent role tasked with providing assurance over VLAS processes and outputs. Key responsibilities include:

• reviewing Data.IndicatorPackage, Data.CalcProof, registry state, pricing logs, and audit packs;
• re-performing calculations for selected samples or full periods using the public standard and available artifacts;
• issuing assurance opinions, findings, and recommendations;
• escalating systemic issues to Role.GovernanceCommittee and, where relevant, to Role.Regulator.

Auditors may rely on automated tools, but the responsibility for the opinion remains with the human or firm.

Role.Regulator

Role.Regulator is a public or delegated authority that sets and enforces rules governing how VLAS credits and INAV may be used, disclosed, or counted. Responsibilities vary by jurisdiction and regime but typically include:

• recognizing or approving VLAS outputs for specific uses;
• setting minimum quality and disclosure requirements;
• conducting oversight and enforcement activities where necessary.

Role.Regulator is outside the VLAS architecture proper but is an explicit consumer of VLAS artifacts and assurances.

S1.6.3 Core System Components (Sys.*)

This subsection defines the core system components required by VLAS Layer 0. These may be implemented as one or many software services, but their responsibilities must be preserved.

Sys.HAIL

Sys.HAIL is the VLAS rules engine and artifact generator. Key responsibilities:

• ingesting VLAS-DSL text (rulesets) and compiling it into:
  • Sys.CalcService logic,
  • decision tables,
  • workflows,
  • schemas, and
  • API contracts;
• generating and storing cryptographic hashes over rulesets and intermediate representations;
• producing governance-ready bundles for ruleset approval.

Sys.HAIL does not execute production calculations; it generates the components that do.

Sys.CalcService

Sys.CalcService denotes one or more stateless services generated from rulesets by Sys.HAIL to perform deterministic calculations. Key responsibilities:

• executing L1–L5 equations, guards, and transformations (for example, allocation, coefficient computation, issuance kernel) given approved inputs;
• producing Data.CalcProof artifacts as outputs, with appropriate hashes and logs;
• exposing interfaces that are version-pinned to specific ruleset versions.

Sys.CalcService must not mutate registry balances or pricing; it only computes.

Sys.Camunda (or equivalent workflow engine)

Sys.Camunda is the workflow and decision engine used to implement VLAS flows, including gates. Key responsibilities:

• orchestrating Gate 1, Gate 2, and Gate 3 workflows;
• assigning tasks to roles (for example, Verifier, NAV Committee);
• capturing human decisions and signatures;
• enforcing sequence and dependency rules for key processes.

Any conformant workflow engine may be used, but it must support the same functionality and auditability.

Sys.DigitalTwin

Sys.DigitalTwin maintains a graph or model of:

• places and assets,
• stewards and communities,
• methods and AdapterSpecs,
• credit lots and their provenance.

Key responsibilities include:

• linking IndicatorPackages, CalcProofs, CUTMetadata, and corporate actions to the physical and social reality they represent;
• serving as the reference for “what this credit is about” in terms a steward or regulator can understand;
• supporting queries and visualizations for governance and monitoring.

Sys.Registry

Sys.Registry is the ledger of Capital Unit Tokens and their lifecycle. Key responsibilities:

• creating Data.CUTMetadata on issuance based on approved CalcProofs;
• recording and enforcing Data.CorporateAction entries for ISSUE, RELEASE_U, TRANSFER, RETIRE, BURN, and any standardized action;
• maintaining balances and positions by lot, class, holder, and time;
• exposing read interfaces for Sys.NAVService, Sys.Audit, and external stakeholders.

Sys.Registry is the single source of truth for circulating quantities Q_{c,w}(t) in the INAV equation.

Sys.PricingEngine

Sys.PricingEngine calculates admissible prices P_{c,w}(t) for use in INAV and related reporting. Key responsibilities:

• ingesting trade and market data from approved venues;
• ingesting and maintaining benchmark curves and parameters;
• applying L7.Eq.Mark (or equivalent canonical forms) to compute prices for listings and lots;
• flagging and logging conditions where prices are non-admissible or degraded (for example, thin markets).

Sys.PricingEngine does not decide whether to accept a venue or benchmark; that is set by governance and configuration.

Sys.NAVService

Sys.NAVService computes INAV(t) and prepares NAV and audit artifacts. Key responsibilities:

• aggregating circulating quantities Q_{c,w}(t) from Sys.Registry;
• ingesting admissible prices P_{c,w}(t) from Sys.PricingEngine;
• applying L8.Eq.NAV and related equations to compute INAV and decompositions;
• producing Data.NAVSnapshot and Data.MonthlyAuditPack;
• providing supporting logs, reconciliation outputs, and diagnostic views.

Sys.NAVService does not change registry balances or prices; it reads and composes them.

S1.6.4 Responsibility Across Layers and Gates (Summary Mapping)

At a minimum, the following mapping of roles and systems to layers and gates SHALL be respected:

• Layer 1 (Ontology Adapter)
  • Primary systems: Sys.HAIL (for generating adapters), Sys.CalcService (for executing them), Sys.DigitalTwin (for linking to assets).
  • Primary roles: Role.Steward (data creation and context), Role.GovernanceCommittee (adapter approval).
• Layer 2 (Input Parser & Governance – Gate 1)
  • Primary systems: Sys.Camunda (workflow), Sys.DigitalTwin (context store).
  • Primary roles: Role.Steward (submitter), Role.Verifier (Gate 1 approver), Role.GovernanceCommittee (policy and escalation).
• Layer 3 (Capital Router)
  • Primary systems: Sys.CalcService.
  • Primary roles: Role.GovernanceCommittee (approval of α and β via AdapterSpecs).
• Layer 4 (Temporal Engine)
  • Primary systems: Sys.CalcService, Sys.DigitalTwin (for permanence, stewardship, and uncertainty inputs).
  • Primary roles: Role.GovernanceCommittee (policy for P, S, U), Role.Steward (providing evidence relevant to stewardship and permanence).
• Layer 5 (Issuance Engine – Gate 2)
  • Primary systems: Sys.CalcService, Sys.Camunda (for Gate 2 workflow).
  • Primary roles: Gate 2 approver (often a specialized Role.Verifier or delegated governance actor).
• Layer 6 (Registry & Tokenization)
  • Primary systems: Sys.Registry.
  • Primary roles: Role.Registrar (operational control), Role.Steward and Role.CapitalProvider (transaction counterparts, where applicable).
• Layer 7 (Pricing & Venue)
  • Primary systems: Sys.PricingEngine.
  • Primary roles: Role.GovernanceCommittee (venue and benchmark approvals), Role.NAVCommittee (acceptance of marks for reporting).
• Layer 8 (Portfolio & Reporting – Gate 3)
  • Primary systems: Sys.NAVService, Sys.Camunda (for Gate 3 workflow).
  • Primary roles: Role.NAVCommittee (Gate 3), Role.Auditor (assurance), Role.Regulator (external oversight).

S1.6.5 Separation of Duties and Conflicts of Interest

VLAS requires certain separation-of-duty constraints to maintain integrity:

• The same individual shall not act as both Role.Steward and Role.Verifier for the same IndicatorPackage, except in limited pilots explicitly disclosed as such.
• The same individual shall not unilaterally act as Role.Verifier at Gate 1 and as Gate 2 approver for the same CalcProof without additional governance controls.
• NAV Committee members shall not be solely drawn from teams whose performance is directly measured by the reported INAV, without mechanisms to mitigate conflicts.
• Role.Registrar shall operate under clear rules and auditability; they shall not alter CalcProofs or pricing inputs.

Implementations may add stricter separation rules but may not weaken these minimum constraints.

S1.6.6 Delegation, Automation, and Service Providers

Roles defined in this section may be:

• delegated (for example, to third-party verifiers or registry operators), or
• supported by automation (for example, automated pre-checks before a human Verifier sees a package),

but delegation and automation do not remove accountability.

Minimum requirements:

• Every decision that counts as a Gate 1, Gate 2, or Gate 3 approval or rejection MUST be attributable to a specific role instance (for example, a named organization or committee), with a timestamp and evidence link.
• Automated tools may prepare recommendations or flags, but the decision remains with the human role, unless the standard and governance explicitly classify a particular decision as machine-only and low-risk.
• Service providers performing Role.Verifier, Role.Registrar, or other critical roles MUST be explicitly identified, and their obligations and limits documented.

S1.7 System-Level Invariants and Failure Modes (Normative)

This section defines the cross-cutting properties that MUST always hold in any conformant VLAS implementation, and the classes of failures that MUST be detected and handled explicitly.

Where later sections define more detailed invariants at the level of specific equations or artifacts, those are in addition to (not instead of) the invariants defined here.

S1.7.1 Determinism and Re-performability

Determinism

For any given set of:

• approved rulesets and AdapterSpecs, and
• approved input artifacts (IndicatorPackages, coefficients, registry state, pricing inputs),

all Sys.CalcService instances and Sys.NAVService MUST produce the same outputs.

Formally, if two conformant implementations:

• use the same ruleset_id and ruleset_version,
• use the same adapter_id and adapter_version, and
• consume artifacts whose hashes match,

then the resulting:

• Data.CalcProof,
• Data.CUTMetadata and Data.CorporateAction, and
• Data.NAVSnapshot and Data.MonthlyAuditPack

MUST be identical up to representation (for example, ordering of non-semantic fields).

Re-performability

An independent third party (for example, Role.Auditor) MUST be able to:

• start from the artifacts provided (IndicatorPackages, CalcProofs, registry exports, pricing logs, audit packs), plus the public standard and rulesets; and
• reproduce, within documented tolerances, the quantities Q and INAV(t) reported for a given period.

If this is not possible, the implementation is non-conformant, regardless of internal controls.

S1.7.2 Non-inflation and No Double Counting

Primary allocation invariants

For any Integrity Delta ΔI for a given asset and window, and any associated set of primary allocation weights α_c across capitals $c \in {C}_{\text{primary}}$, the following constraint MUST hold:

$$\sum_{c \in {C}_{\text{primary}}} {{ \alpha }_{c}}\; \leq \;1$$ where:

• ${C}_{\text{primary}}$is the set of capitals that receive primary allocations from this ΔI;
• ${ \alpha }_{c}$is the fraction of ΔI allocated to capital c as a primary effect.

Spillover (co-benefit) invariants

For any source capital s and the set of target capitals $k \in {C}_{\text{targets}}$that receive spillover credits from s, spillover dampeners β_{s→k} MUST satisfy:

$$\sum_{k \in {C}_{\text{targets}}} {{ \beta }_{s \rightarrow k}}\; \leq \;1$$ where:

• ${ \beta }_{s \rightarrow k}$is the fraction of the primary quantity in capital s that is used to derive spillover quantity in capital k.

These constraints ensure that:

• the sum of primary allocations does not exceed ΔI, and
• the sum of spillovers from a given source capital does not exceed that source’s primary quantity.

No double counting across listings

No Integrity Delta or resulting quantity of credits may be counted:

• more than once in the same capital domain and window; or
• more than once across overlapping listings that purport to represent the same underlying effect.

Listings that represent the same underlying effect in different ways (for example, different jurisdictional categories) MUST be linked via explicit crosswalks and eliminated as required so that INAV(t) reflects a non-inflated view of underlying integrity.

S1.7.3 Governance and Human-in-the-Loop Integrity

The following invariants apply at all three gates:

• Gate 1 (IndicatorPackage validation),
• Gate 2 (CalcProof approval),
• Gate 3 (NAV/AuditPack signoff).

Human decision, machine calculation

• Humans MAY approve or reject artifacts (IndicatorPackages, CalcProofs, audit packs) and MAY adjust configuration (rulesets, AdapterSpecs, pricing policies) through governed processes.
• Humans MUST NOT directly edit computed values for:
  • Integrity_before, Integrity_after, ΔI,
  • allocation outputs Q_primary and Q_spillover,
  • coefficients v, a, P, S, U,
  • credit quantities Q, or
  • INAV(t).

Any change to these values MUST result from:

• a change in underlying data (for example, corrected IndicatorPackages), and/or
• a change in ruleset or parameters, approved through governance and recorded as a new ruleset version,
• followed by recalculation.

Attribution and evidence

Every Gate 1, Gate 2, and Gate 3 decision MUST be:

• attributable to a specific role instance (for example, a person, a committee, or an organization);
• timestamped; and
• linked to the artifacts being approved or rejected (via hashes or unique identifiers).

If a decision cannot be traced back to a responsible human role with evidence, it is not valid under this standard.

S1.7.4 Registry and Corporate Action Invariants

Sys.Registry and Data.CorporateAction MUST respect the following:

• Single source of truth.
  Registry state is the single authoritative record of circulating quantities Q at any time t. No shadow ledgers that affect INAV are permitted.

• Event-sourced lifecycle.
  The lifecycle of each lot is represented as a sequence of corporate actions. The current state is the result of folding those actions in order. Removing or editing historical actions (other than well-controlled, fully disclosed restatements) is prohibited.

• No hidden balances.
  All balances used in INAV and related reporting MUST be derivable from corporate actions and lot metadata. Internal caches or optimizations must not diverge from the canonical record.

If any divergence or corruption is detected (for example, mismatched balances vs. reconstructed balances from corporate actions), the problem MUST be treated as a critical incident and addressed before producing or relying on INAV for the affected period.

S1.7.5 Pricing and INAV Invariants

Sys.PricingEngine and Sys.NAVService MUST respect the following invariants:

• Admissible price only.
  INAV(t) MUST be computed using only admissible prices produced in accordance with L7.Eq.Mark and approved venue/benchmark configurations. Any non-admissible marks (for example, internal scenario prices) MUST NOT be mixed into reported INAV.

• Traceable sources.
  For each price P_{c,w}(t) used in INAV(t), there MUST be traceable sources (venue data, benchmarks, parameters) recorded in logs or artifacts sufficient for later re-performance and review.

• Equation conformance.
  INAV(t) MUST conform to the canonical equation:

$$INAV(t)=\sum_{\text{capital, class, window, lot}} {\text{circulating\_quantity}(\text{capital, class, window, lot},t) \times \text{admissible\_price}(\text{capital, class, window, lot},t)}$$

If a reported figure cannot be mapped to this equation and the underlying quantities and prices, it is not an VLAS-conformant INAV.

S1.7.6 Failure Modes and Required Responses

This subsection enumerates classes of failure that MUST be detectable and the minimum required responses.

S1.7.7 Restatements and Corrections

Restatements are allowed but MUST follow strict rules:

• Restatements of issuance quantities or INAV(t) MUST be implemented through:
  • corrected data and/or configuration (for example, corrected IndicatorPackages, corrected α/β within allowed governance processes), and
  • re-execution of relevant calculations, registry actions, and pricing steps;
• Restated results MUST be issued as new CalcProofs, corporate actions, and NAVSnapshots with clear labeling of:
  • original values,
  • restated values, and
  • reasons for the change.

Silently overwriting historical data, CalcProofs, registry balances, or NAVSnapshots without traceable restatement is prohibited.

S1.8 Security, Privacy, and Data Classification (Normative, Architecture Level)

VLAS is a system for turning real-world integrity into finance-grade credits and INAV. That makes it both high-impact and high-value as a target:

• Attacks on data could distort issuance or pricing.
• Attacks on governance could subvert approvals or restatements.
• Attacks on privacy could expose communities, stewards, or sensitive project information.

This section defines architecture-level security and privacy requirements that apply across all layers and implementations. Detailed implementation guidance, cryptographic profiles, and jurisdiction-specific privacy rules are defined in separate documents and annexes.

S1.8.1 Threat and Trust Model (High-Level)

VLAS assumes at least the following classes of risk:

• External attackers attempting to:
  • tamper with data or logs,
  • forge or replay approvals, or
  • exfiltrate sensitive information.
• Insiders with partial privileges attempting to:
  • bypass checks at Gate 1, Gate 2, or Gate 3,
  • manipulate registry state or pricing, or
  • insert backdated or forged artifacts.
• Misconfiguration and process drift:
  • incorrect or stale rulesets and AdapterSpecs being used,
  • misrouted workflows, or
  • logging gaps that make re-performance or forensic analysis impossible.

VLAS does not assume that any single actor (human or machine) is perfectly trustworthy. Instead, it relies on:

• clear separation of duties,
• cryptographic binding of artifacts, and
• end-to-end traceability,

to ensure that no single compromised component can silently corrupt the system.

S1.8.2 Data Classification

Each VLAS implementation SHALL define and maintain a data classification scheme. At a minimum, the following classes MUST be distinguished:

• Public
  • Content intended for broad disclosure (for example, high-level statistics, summary INAV figures, public method and AdapterSpec descriptions).
  • May be published without access control, subject to general information security practices.
• Confidential – Operational
  • Data required for VLAS operation and audit but not intended for public release (for example, detailed IndicatorPackages, full CalcProof contents, registry extracts with holder IDs).
  • Accessible only to authorized roles (for example, Stewards, Verifiers, NAV Committee, Auditors, Regulators).
• Confidential – Personal or Sensitive
  • Data that could identify individuals or reveal sensitive community information (for example, personally identifiable information, health-related indicators, exact geolocation for vulnerable communities).
  • Subject to stricter access controls, data minimization, and privacy compliance (see below).
• Key Material and Secrets
  • Cryptographic keys, signing credentials, and configuration secrets.
  • Only accessible to designated operators; MUST never be included in IndicatorPackages, CalcProofs, registry exports, or audit packs.

Each artifact defined in Section 1 and Section 2 (for example, Data.IndicatorPackage, Data.CalcProof, Data.CUTMetadata, Data.MonthlyAuditPack) SHALL be classified at creation, and handling rules SHALL be defined and enforced accordingly.

S1.8.3 Access Control and Authorization

Access control MUST be enforced at all relevant layers and interfaces. At a minimum:

• Every interaction with VLAS artifacts (read, write, approve, reject, price, or compute) MUST be associated with:
  • an authenticated identity (human or system), and
  • a role or set of roles (for example, Role.Steward, Role.Verifier, Role.Registrar).

Role-based access control (RBAC) or an equivalent mechanism SHALL be implemented so that:

• Role.Steward can create and view IndicatorPackages for their assets, but cannot approve them at Gate 1 or directly alter registry balances.
• Role.Verifier can view and approve IndicatorPackages and CalcProofs but cannot unilaterally edit rulesets or change registry balances.
• Role.GovernanceCommittee can approve rulesets and AdapterSpecs and access configuration, but cannot unilaterally bypass Gate 1, 2, or 3 without trace.
• Role.NAVCommittee can access NAV and audit artifacts, and sign or reject them at Gate 3, but cannot change the underlying registry or pricing logs.
• Role.Registrar can execute corporate actions under defined authorizations, but cannot change CalcProofs or pricing inputs.
• Role.Auditor can read all relevant artifacts and logs needed for assurance, but cannot perform Gate approvals or corporate actions.

Separation-of-duty constraints defined in S1.6 SHALL be enforced in the access control configuration. Attempts to assign conflicting roles to the same individual or service MUST be either blocked or explicitly documented and approved under exceptional governance rules.

S1.8.4 Logging, Audit Trails, and Forensics

All VLAS implementations SHALL produce and retain logs sufficient to:

• reconstruct the history of decisions, calculations, and state changes;
• detect and investigate anomalies;
• support independent audits and, where applicable, regulatory investigations.

At a minimum:

• Every Gate 1, Gate 2, and Gate 3 decision MUST be logged with:
  • artifact identifiers and hashes,
  • identity and role of the approver or rejector,
  • timestamp,
  • decision outcome,
  • reason or reference to supporting documentation.
• Sys.CalcService MUST log:
  • ruleset_id and version used,
  • input artifact identifiers and hashes,
  • summary of outputs (for example, CalcProof IDs),
  • any failed tests or guards.
• Sys.Registry MUST log:
  • every Data.CorporateAction applied,
  • the initiating identity or system,
  • authorization evidence (for example, reference to approved CalcProof or program rule).
• Sys.PricingEngine MUST log:
  • data sources used (venues, benchmarks),
  • parameters,
  • computed prices,
  • any fallbacks or failures.

Log integrity:

• Logs for security-relevant events SHALL be protected against tampering using appropriate mechanisms (for example, append-only stores, write-once media, or cryptographic anchoring).
• If logs are replicated across systems, mechanisms SHALL be in place to detect divergence.

Retention:

• Minimum retention periods for logs and artifacts SHALL be defined based on regulatory requirements, risk appetite, and audit needs. In the absence of stricter requirements, retention SHOULD be measured in years, not months.

S1.8.5 Cryptographic Binding and Key Management

VLAS relies on cryptographic binding to ensure that data and decisions cannot be silently altered.

At a minimum:

• Data.IndicatorPackage, Data.CalcProof, Data.CUTMetadata, Data.CorporateAction, Data.NAVSnapshot, and Data.MonthlyAuditPack SHALL each contain or reference:
  • one or more cryptographic hashes over their contents, and
  • digital signatures associated with the roles and systems that created or approved them.
• Keys used for signatures SHALL be:
  • generated and stored in accordance with best practices (for example, hardware-backed or equivalent secure storage where feasible),
  • rotated using documented procedures, and
  • revoked promptly if compromise is suspected.

Key management policies MUST define:

• who can request, approve, and manage keys for each role or system;
• how lost or compromised keys are handled;
• how historic signatures are treated when keys expire or are rotated (for example, preserved as valid evidence with appropriate metadata).

Cryptographic profiles (algorithms, key sizes, hash functions) SHALL meet contemporary industry standards and SHOULD be periodically reviewed as part of governance.

S1.8.6 Privacy, Minimization, and Community Protection

Because VLAS may handle sensitive community and steward-level information, implementations MUST:

• apply data minimization: collect and store only what is necessary for:
  • method compliance,
  • issuance and registry integrity,
  • audit and assurance,
  • regulatory compliance.
• separate personally identifiable information (PII) and highly sensitive fields from operational data where possible, linking them via pseudonymous identifiers rather than embedding PII directly in all artifacts.
• ensure that FPIC and other community governance artifacts are handled according to:
  • local legal requirements, and
  • community preferences where these go beyond legal minima.

When IndicatorPackages or other artifacts contain personal or sensitive community data, access SHOULD be restricted to those roles that strictly need it (for example, relevant Stewards, Verifiers, and, where required, Auditors or Regulators), and SHOULD NOT be broadly visible to all capital providers or external observers.

Implementations MUST comply with applicable data protection laws and regulations in each jurisdiction where VLAS is operated or where data subjects reside. Where those laws impose stricter requirements than this standard, the stricter requirements apply.

S1.8.7 Interfaces, Interoperability, and External Systems

VLAS will often be integrated with:

• external data providers (for example, remote sensing, sensor networks, lab systems),
• external registries and exchanges, and
• external reporting platforms.

At these boundaries:

• Interfaces MUST be authenticated and authorized;
• Data ingested from external systems MUST be validated and clearly marked as such;
• External systems SHALL NOT be treated as inherently trusted simply because they are upstream or downstream.

If external systems are used to store or relay VLAS artifacts:

• the security, privacy, and integrity requirements of this section STILL apply; and
• responsibility for compliance MUST be clearly assigned to a role (for example, Role.Registrar, Role.GovernanceCommittee, or a designated infrastructure operator).

S1.9 Worked End-to-End Example (Informative)

This section provides a concrete, end-to-end example of how VLAS operates from field measurements to INAV, using the concepts and artifacts defined in Section 1. It is illustrative, not exhaustive: actual deployments will involve many assets, methods, and credit classes in parallel.

S1.9.1 Scenario Setup

Place and assets

• A coastal watershed region with:
  • degraded mangrove forests and nearshore fisheries,
  • adjacent communities with health and income challenges,
  • basic but aging infrastructure (roads, drainage).
• A steward coalition:
  • a local land and sea trust,
  • a community health cooperative,
  • a municipal infrastructure agency.

Program and methods

The coalition participates in a regenerative program with three main strands:

• Mangrove restoration and coastal protection
  • Method: “Mangrove Blue Carbon and Protection v1.2”
  • Primary capital: Natural (N)
  • Known co-benefits: Human (H), Social (S), Manufactured (M) via risk reduction.
• Community health and nutrition improvements
  • Method: “Community Health and Nutrition v1.0”
  • Primary capital: Human (H)
  • Co-benefits: Social (S).
• Resilient drainage and access upgrades
  • Method: “Resilient Infrastructure v1.0”
  • Primary capital: Manufactured (M)
  • Co-benefits: Natural (N) and Human (H).

Each method has an approved Data.AdapterSpec, including indicators, mappings to Integrity, allocation weights α and spillover dampeners β, and any temporal/governance hooks required.

Capital classes and listings

For this example, assume the following capital classes are active:

• NCU.Coastal – Natural capital credits for coastal ecosystems and protection.
• HCU.Health – Human capital credits for health and wellbeing.
• SCU.Community – Social capital credits for local governance and cohesion.
• MCU.Infrastructure – Manufactured capital credits for resilient infrastructure.

Listings include, among others:

• NCU.Coastal.2026Q2
• HCU.Health.2026Q2
• SCU.Community.2026Q2
• MCU.Infrastructure.2026Q2

We focus on one reporting window: 2026Q2.

S1.9.2 Step-by-Step Through the Layers

Step 1 — Field Measurement (Layer 1)

Over the course of 2026Q2, Role.Steward and their measurement partners collect:

• Mangrove area and biomass measurements (field plots and remote sensing).
• Storm impact and flood depth measurements over the wet season.
• Health indicators (for example, incidence of waterborne disease, clinic visits).
• Community governance indicators (for example, attendance at community assemblies, reported trust measures).
• Infrastructure condition and performance indicators (for example, road passability, drainage performance metrics).

Each method records data in its own units and formats, as specified in its method documentation.

Step 2 — Build IndicatorPackages (Layer 2, pre-Gate 1)

Role.Steward prepares three Data.IndicatorPackage bundles, one per method:

• IndicatorPackage_Mangrove_2026Q2
• IndicatorPackage_Health_2026Q2
• IndicatorPackage_Infrastructure_2026Q2

Each package contains:

• indicators.json – measurements, units, timestamps, QA flags, references to baselines;
• provenance.json – who collected what, where, how, and with which devices or labs;
• governance evidence – including minutes from community meetings, FPIC declarations, and program agreements;
• adapter_id and adapter_version for the relevant method;
• a computed bundle_hash over all contents;
• Role.Steward signature attesting to the submission.

Step 3 — Gate 1: Verifier Approval (Layer 2)

Sys.Camunda routes each IndicatorPackage to a Role.Verifier:

• The Verifier checks method conformance (indicators present, units correct, cadences respected).
• QA/QC checks are run (range checks, missing data checks).
• FPIC evidence is reviewed against program requirements.
• Any anomalies (for example, a sudden spike in a health metric) are flagged and investigated.

For this example, assume all three packages pass Gate 1:

• The Verifier signs bundle_hash and FPIC status for each.
• Each IndicatorPackage is marked “approved” and becomes eligible input to the calculation layers.

Step 4 — Adapter and Integrity Delta (Layer 1 / Layer 3 preparation)

Sys.CalcService, using Sys.HAIL-generated logic and the relevant AdapterSpecs, converts each approved IndicatorPackage into:

• Integrity_before and Integrity_after for the relevant metrics and assets;
• Integrity Delta ΔI for each asset and method over 2026Q2;
• tags for primary capital and allowed spillover routes.

Examples:

• Mangrove method: ΔI_Natural_Mangrove_2026Q2 (a positive change in natural integrity).
• Health method: ΔI_Human_Health_2026Q2 (improved health outcomes).
• Infrastructure method: ΔI_Manufactured_Infra_2026Q2 (improved resilience and performance).

These ΔI values (still method-specific in interpretation) are now expressed in VLAS Integrity units, ready for Layer 3.

Step 5 — Capital Routing (Layer 3)

For each ΔI, Layer 3 applies allocation weights α and spillover dampeners β from the relevant AdapterSpec.

Example 1 – Mangrove method:

• Primary allocations:
  • α_N = 0.75
  • α_M = 0.25
  • α_H = 0, α_S = 0
• Spillovers:
  • β_{N→H} = 0.20 (health co-benefit from better protection and livelihoods)
  • β_{N→S} = 0.10 (social co-benefit from strengthened local governance around mangroves)

Layer 3 computes:

$$\begin{matrix} {Q}_{\text{primary}}(N) & ={ \alpha }_{N} \cdot \Delta {I}_{\text{Mangrove}} \\ {Q}_{\text{primary}}(M) & ={ \alpha }_{M} \cdot \Delta {I}_{\text{Mangrove}} \\ {Q}_{\text{spillover}}(N \rightarrow H) & ={ \beta }_{N \rightarrow H} \cdot {Q}_{\text{primary}}(N) \\ {Q}_{\text{spillover}}(N \rightarrow S) & ={ \beta }_{N \rightarrow S} \cdot {Q}_{\text{primary}}(N) \end{matrix}$$

subject to:

$${ \alpha }_{N}+{ \alpha }_{M} \leq 1{ \beta }_{N \rightarrow H}+{ \beta }_{N \rightarrow S} \leq 1$$

Similar allocations are performed for:

• ΔI_Human_Health_2026Q2 (primarily into HCU.Health, with spillovers to SCU.Community), and
• ΔI_Manufactured_Infra_2026Q2 (primarily into MCU.Infrastructure, with spillovers to NCU.Coastal and HCU.Health).

At the end of Layer 3, we have a set of capital-tagged quantities (still “potential credits”) for the 2026Q2 window.

Step 6 — Temporal and Governance Coefficients (Layer 4)

Layer 4 computes, for each capital-tagged quantity in 2026Q2:

• v – velocity of change (for example, how quickly mangrove coverage is increasing relative to program expectations);
• a – acceleration (for example, whether health improvements are speeding up or slowing down);
• P – permanence or durability (for example, legal and physical factors affecting the longevity of mangrove restoration or infrastructure resilience);
• S – stewardship and governance quality (for example, strength of local institutions, FPIC quality, community oversight);
• U – uncertainty (for example, confidence intervals on biomass estimates, health data quality, model assumptions).

These coefficients are derived using rules encoded in relevant rulesets, possibly with inputs from Sys.DigitalTwin (for example, legal status of protected areas, enforcement history, socio-political stability).

For each capital.class and listing window in 2026Q2, we now have:

• ΔI,
• a routed set of Q_primary and Q_spillover values, and
• a coefficient vector (v, a, P, S, U).

Step 7 — Issuance Kernel and CalcProof (Layer 5, Gate 2)

Layer 5 applies the issuance kernel, L4.Eq.Kernel (or equivalent), which combines ΔI and the coefficients (v, a, P, S, U) to produce actual issuance quantities Q for each capital.class and listing window.

The details of the kernel are defined in Section 2, but conceptually:

• High P and S, and low U, support higher issuance from the same ΔI.
• Low P or S, or high U, reduce issuance or hold some potential credits as unissued or conditionally issued (for example, to be released later under RELEASE_U if uncertainty resolves).

Sys.CalcService runs the kernel for the 2026Q2 period, producing:

• quantities such as:
  • Q(NCU.Coastal.2026Q2),
  • Q(HCU.Health.2026Q2),
  • Q(SCU.Community.2026Q2),
  • Q(MCU.Infrastructure.2026Q2);
• along with any associated held-back quantities and advisory flags.

Sys.CalcService packages all inputs and outputs into a Data.CalcProof**. The CalcProof includes:

• references to the IndicatorPackages and their hashes,
• ruleset_id and adapter_id used,
• parameter values (v, a, P, S, U and any other kernel parameters),
• computed Q values by capital.class and window,
• results of any golden tests and guard checks.

Sys.Camunda routes the CalcProof to the Gate 2 approver (for example, a specialized Verifier or governance delegate). The approver checks:

• that the appropriate ruleset and adapter versions were used;
• that the IndicatorPackages referenced are approved;
• that tests and guards passed;
• that there are no policy violations (for example, P, S, U outside allowed bands without mitigating controls).

Assuming the checks pass, the approver signs the CalcProof. It is now eligible to drive issuance.

Step 8 — Issuance, Registry, and Corporate Actions (Layer 6)

Sys.Registry receives the approved CalcProof and applies ISSUE corporate actions for each capital.class and window.

For example:

• ISSUE lot Lot_NCU_Coastal_2026Q2 with:
• capital.class = NCU.Coastal,
• window = 2026Q2,
• quantity = Q(NCU.Coastal.2026Q2),
• references to the CalcProof and AdapterSpecs.
• ISSUE analogous lots for HCU.Health.2026Q2, SCU.Community.2026Q2, MCU.Infrastructure.2026Q2.

Each lot has a Data.CUTMetadata record populated accordingly. Over time, additional corporate actions occur:

• TRANSFER actions as credits are bought, sold, or assigned.
• RETIRE actions as credits are used to satisfy obligations or program rules.
• RELEASE_U actions if initially held-back quantities are later released based on improved data.
• BURN actions if integrity issues are discovered (for example, reversal or fraud).

At the end of 2026Q2, the circulating quantities for each listing are computed from the net effect of all corporate actions applied up to the reporting date.

Step 9 — Pricing and Admissible Marks (Layer 7)

Sys.PricingEngine obtains market and benchmark data for the relevant listings:

• For NCU.Coastal.2026Q2, there may be active trades on approved venues, plus benchmark curves for coastal protection value.
• For HCU.Health.2026Q2 and SCU.Community.2026Q2, benchmarks or program-defined pricing curves may dominate, possibly with some secondary trading data.
• For MCU.Infrastructure.2026Q2, pricing might be tied to co-financing agreements or benchmark curves for resilience improvements.

Sys.PricingEngine applies L7.Eq.Mark for each listing, producing admissible prices:

• P(NCU.Coastal.2026Q2, t),
• P(HCU.Health.2026Q2, t),
• P(SCU.Community.2026Q2, t),
• P(MCU.Infrastructure.2026Q2, t),

for the reporting date t (end of 2026Q2).

These prices are logged with references to data sources and parameters used.

Step 10 — INAV Calculation and NAV Pack (Layer 8, Gate 3)

Sys.NAVService pulls:

• circulating quantities Q_{c,w}(t) from Sys.Registry (computed from all corporate actions), and
• admissible prices P_{c,w}(t) from Sys.PricingEngine.

It applies the canonical INAV equation:

$$INAV(t)=\sum_{\text{capital, class, window, lot}} {\text{circulating\_quantity}(\text{capital, class, window, lot},t) \times \text{admissible\_price}(\text{capital, class, window, lot},t)}$$

For the purposes of illustration, consider just the four listings in 2026Q2:

$$\begin{matrix} INAV(t) & =Q(\text{NCU.Coastal.2026Q2},t) \cdot P(\text{NCU.Coastal.2026Q2},t) \\ & +Q(\text{HCU.Health.2026Q2},t) \cdot P(\text{HCU.Health.2026Q2},t) \\ & +Q(\text{SCU.Community.2026Q2},t) \cdot P(\text{SCU.Community.2026Q2},t) \\ & +Q(\text{MCU.Infrastructure.2026Q2},t) \cdot P(\text{MCU.Infrastructure.2026Q2},t) \\ & + \ldots \end{matrix}$$

where “…” stands for other listings in the system and portfolio beyond these four.

Sys.NAVService composes:

• a Data.NAVSnapshot for t, including INAV(t) and breakdowns by capital and listing;
• a Data.MonthlyAuditPack for 2026Q2, including:
  • NAVSnapshot(s),
  • registry extracts and reconciliations,
  • pricing sources and calculations,
  • summaries of relevant IndicatorPackages and CalcProofs,
  • any exceptions, overrides, or restatements.

Sys.Camunda routes the pack to Role.NAVCommittee for Gate 3.

The NAV Committee:

• reviews reconciliations between registry balances and reported holdings;
• checks that prices used are admissible according to policy;
• reviews any anomalies, restatements, or unusual events;
• signs or rejects the pack.

Assuming they sign, the INAV(t) for 2026Q2 becomes the official VLAS INAV figure for that period.

S1.9.3 Summary of Artifacts and Decisions in the Example

In this single reporting window, we have:

• Three approved Data.IndicatorPackage artifacts (mangrove, health, infrastructure).
• One or more Data.AdapterSpec artifacts per method, governing their mapping into VLAS.
• A set of ΔI values and capital allocations produced by Layers 1–3.
• Coefficients (v, a, P, S, U) produced by Layer 4.
• One or more Data.CalcProof artifacts capturing issuance calculations for 2026Q2.
• Data.CUTMetadata records for each issued lot (NCU.Coastal.2026Q2, etc.).
• Multiple Data.CorporateAction entries capturing lifecycle changes.
• Admissible prices P_{c,w}(t) computed by Sys.PricingEngine.
• A Data.NAVSnapshot** and Data.MonthlyAuditPack for t (end of 2026Q2).
• Three gates:
  • Gate 1: Verifier approvals for IndicatorPackages.
  • Gate 2: Approvals for CalcProofs.
  • Gate 3: NAV Committee signoff on INAV and the audit pack.

An independent third party, given:

• the public standard and rulesets, and
• the artifacts listed above,

can re-perform the entire chain from IndicatorPackages to INAV(t) and confirm that:

• allocations respect non-inflation constraints;
• coefficients are within governed ranges;
• credit quantities follow from ΔI and the kernel;
• registry balances and corporate actions reconcile;
• prices are admissible and correctly applied;
• INAV(t) matches the canonical equation.

This is the practical meaning of VLAS being deterministic, non-inflationary, and re-performable.

S1.10 Gate-to-Role-to-Control Matrix (Authoritative; supersedes prior S1.10 + S1.13)

S1.10.A — Gate Controls (by issuance stage)

Figure 9 — Three gates, six control dimensions. If a cell fails, the standard specifies the response.

S1.10.B — Continuous Conformance Controls (periodic/alwayson)

Observation: The matrix is the operational “board” for audits: if a cell fails, the standard tells you exactly what to block, burn, or restate.

S1.11 What Lives in Layer 0 vs What Lives in Registries (Expanded; Normative)

S1.11.A — Inside Layer 0 (this canon)
Keys and typing: canonical keys, units, and ranges for variables/indicators/functions/equations; UCUM units only; no bare numbers.
Actors & authorities: roles, gates, segregation rules; quorum definitions; signer data structure.
Objects & events: CreditLot schema; lifecycle events (ISSUE/RELEASE_U/TRANSFER/RETIRE/BURN); Position semantics.
Functions & equations: fully typed signatures; LaTeX; invariants; guard conditions; required goldentest categories (minimal/nominal/adverse/infeasible).
Adapter/benchmark/test schemas: strict field lists; allowed enumerations; JSONschema definitions.
Change control: semantic versioning rules; effective/deprecation windows; migration & sunset rules.

S1.11.B — Normative Registries (by reference)

• METHODS — AdapterSpec per method: identity, source schema, MRV cadence, mapping $T:X \mapsto I$, α, β, $P/S/U$schedules, crosscapital dampeners, windows.
• COEFF — Permanence bands; stewardship ladders; uncertainty tiers; $v/a$caps & smoothing; forcemajeure policies.
• CLASSES — Capital subclasses and canonical units (e.g., NCU.Watershed, MCU.Energy, HCU.Training).
• BENCH — Admissible pricing benchmarks: curve/table spec, provenance, hash; venue policy haircuts.
• TEST — Golden tests & fixtures: vectors, expected results, tolerances; fixture hashes; negative test catalogue.
• ADAPTERSXWALK** — Clauselevel crosswalks to external frameworks; variance field and resolution policy.

Publication format (registries). Each entry shall include: {id, version, sha256, uri, effective_date, deprecation_date, status{proposed|active|deprecated}}. Engines shall not mix major versions in a single issuance run.

Reader note: If it isn’t in Layer 0 or a referenced registry with a version and a hash, the engine must ignore it.

S1.12 External Alignment Surfaces (Expanded; Informative)

Purpose. VLAS adapters allow VLAS outputs (lots, positions, INAV) to feed directly into existing disclosure and certification frameworks. This section clarifies how the mapping works and what not to do.

Figure 10 — Adapters export from VLAS. External frameworks are consumers — they do not modify VLAS.

A. CSRD / ESRS (EU) — Adapters map VLAS quantities and evidence to ESRS datapoints while preserving noninflation constraints. VLAS INAV and capital slices support ESRS E1 (climate), E2 (pollution), E4 (biodiversity & ecosystems), Sseries (workforce/community), and governance statements. Clauselevel mappings must identify period, place geometry, capital class, window, adapter version, and variance** (if any). See European Commission — CSRD overview and EFRAG ESRS implementation guidance for the current scope and implementation notes.

B. TNFD — VLAS place geometry, risk drivers, and capital impacts render to TNFD’s recommended disclosures and LEAP approach. Adapters expose the indicator lineage and decision logs to support governance/strategy/metrics targets. See TNFD Final Recommendations (Sept 2023).

C. SEEA Ecosystem Accounting — VLAS naturalcapital outputs (NCU subclasses) align to SEEA EA stocks/flows and ecosystem assets; geometry, time, and method metadata enable national statistical offices to integrate VLAS series without loss of meaning. See UN SEEA Ecosystem Accounting resources.

D. ISO 140641 (GHG quantification/verification) — Where carbon is in scope, VLAS leverages ISO principles for quantification and verification; AdapterSpecs declare scopes, baselines, and uncertainty methods. See ISO 140641:2018**.

E. EU CRCF (Carbon Removals Certification Framework) — VLAS removalclass outputs (e.g., certain NCU subclasses) can generate CRCFeligible artifacts when permanence and monitoring provisions meet the regulation’s thresholds; adapters must disclose any variance. See Regulation (EU) 2024/3012 (CRCF).

F. ISSB (IFRS S1/S2) — VLAS portfolio marks (INAV) and decision logs can be surfaced as investorfocused sustainability disclosures under IFRS S1/S2; adapters map governance, strategy, risk management, and metrics to VLAS artifacts. See ISSB/IFRS overview and navigator.

G. U.S. SEC Climate Rules (status note) — Where a filer is subject to SEC climate rules, VLAS adapter exports can populate risk/financialimpact disclosures and (as applicable) Scope 1/2 emissions attestations. Status in 2024–2025: rules adopted but subject to stays and litigation; filers should follow current SEC guidance and court developments. See Federal Register rule, SEC press release, and news coverage of the litigation/stays.

Observation: Adapters are clause-level bridges, not prose summaries. If a clause conflicts with VLAS issuance or lifecycle, VLAS governs; the adapter discloses variance and how it is resolved in reporting.

S1.13 Publication Requirements (Formal & Normative)

A conformant deployment shall publish the following artifacts, on the stated cadence, with the stated fields. All files must be machinereadable (JSON or CSV for ledgers; PDF for signed summaries), hashpinned**, and retained per policy.

S1.13.A — Monthly (or periodend) required publications**

• Adapter Registry Digest — {id, version, sha256, effective_date, deprecation_date, status} for all active and deprecated adapters; include α, β, $P/S/U$schedule version IDs.
• Gate Ledger — For Gate 1/2/3: gate_id, package_id or calcproof_id, ruleset_id@version, signer (person+role+org), timestamp (UTC), decision (approve/deny), evidence hashes, FPIC state.
• CorporateAction Ledger (Registry) — Chronological ISSUE/RELEASE_U/TRANSFER/RETIRE/BURN events with lot serial, quantity (typed units), reason codes, hashes, and counterparty (for transfers).
• Positions Snapshot — Holder, lot serial, circulating quantity (typed units), last action timestamp, vintage, class, window.
• Pricing & Venue Statement — Venue list, VWAP period, haircuts applied, benchmark IDs (if used), admissible mark per listing, adverseevent notes.
• INAV/NAV Reconciliation — For each listing: circulating × admissible price = INAV slice; portfolio INAV; eliminations; reconciliation note to NAV; signed by NAV Committee.
• Disclosure Crosswalks — Clauselevel exports for CSRD/ESRS, TNFD, SEEA, ISO/CRCF, and (if applicable) SEC/IFRS S1/S2; include variance indicators and links to artifact hashes.
• Exceptions & Restatements — Table of exceptions (type, scope, rationale, sunset) and restatements (period, magnitude, action taken, before/after quantities/prices).

S1.13.B — Quarterly required publications

• GoldenTest Report** — Per equation/function: pass/fail summary, fixture IDs (hashes), tolerance bands, changes since prior quarter.
• Security & Privacy Attestation — Signature and hash policy, key rotation events, dataminimization checks, FPIC attestation ledger.

S1.13.C — Annual required publications

• Method & Coefficient Update Log — All COEFF/METHODS changes with effective/deprecation windows, migration notes, and affected listings.
• Independent Verification Summary — Verifier’s assurance opinion scope and exceptions over the year’s Gate 1/Gate 2 decisions and registry traces.

Signature & retention. All publications shall include {publisher_org, signer (person+role), timestamp, sha256} and be retained for the statutory period. Where law requires, a notarized PDF is included alongside the machinereadable files.

Reader note: These are mustpublish lists. If a period has no changes (e.g., no new adapters), publish a signed “no change” digest with the period timestamp.

Part 2: Definitions, Rules, Gates

S2.0 Conventions (Normative)

Section 2 is the canonical glossary for VLAS Layer 0. It defines symbols, variables, objects, and terms used in equations and artifacts across the standard. This subsection sets the conventions that apply to everything in Section 2.

S2.0.1 Verbal Forms

Section 2 uses the same verbal forms as Section 1, with one additional clarification: symbol and type definitions in this section are binding.

• shall / must – required. If a symbol, type, unit, or range is defined with “shall” or “must”, any implementation that diverges is not conformant.
• shall not / must not – prohibited.
• should / recommended – strongly advised; deviations must be explicitly justified and documented.
• may / optional – genuinely optional; does not affect conformance.

When this section says:

• “is denoted by” – it is specifying the canonical symbol or name that must be used in equations and artifacts.
• “has type” – it is specifying the abstract type (for example, real number, integer, enumeration, identifier).
• “has unit” – it is specifying the canonical UCUM unit or that the variable is dimensionless.
• “takes values in” – it is specifying the admissible range or set of values.

Where this section gives an example value or illustrative calculation, the example is informative; the definition of the symbol is normative.

S2.0.2 Units and Dimensions

All quantitative variables in this section shall carry explicit units, unless they are defined as dimensionless.

• The unit system for VLAS shall be UCUM (Unified Code for Units of Measure).
• If a quantity is dimensionless, its unit shall be recorded as 1 (UCUM dimensionless) and its interpretation described in the text (for example, “fraction of baseline”, “probability”, “weight in [0,1]”).
• Engines and schemas shall not accept “bare numbers” without an associated unit or declared dimensionless type.

Where a variable’s definition refers to a physical quantity (for example, mass, area, time, concentration), this section shall specify:

• its underlying physical dimension (for example, mass, area, time), and
• the canonical UCUM representation (for example, kg, m2, a for year, mg/L).

If implementations store or transmit data in alternative units (for example, tCO2e/ha instead of kg/m2), they shall provide explicit mappings to the canonical unit, and the mapping shall be lossless to the precision required by the standard.

S2.0.3 Ranges and Bounds

Every scalar variable defined in this section shall have a declared admissible range.

Ranges are expressed using standard interval notation:

• $\left[ a , b \right]$– closed interval, including both endpoints;
• $(a,b]$– open at $a$, closed at $b$;
• $[a, \infty )$– all values greater than or equal to $a$.

For example, a weight that must lie between 0 and 1 inclusive is written:

$$w \in [0,1]$$ For each variable, this section specifies:

• type (for example, real number, integer, Boolean, enumeration);
• unit (UCUM code, or 1 for dimensionless);
• admissible range (interval or enumerated set);
• interpretation (how to read a given value).

Implementations shall enforce these ranges:

• at compile time where possible (for example, ruleset validations), and
• at runtime via guard conditions and input validation.

Any value outside the defined range shall be treated as an error (see S2.9 for error classes and guard violations).

S2.0.4 Time Windows and Indexing

Time in VLAS is organized around windows. Credits, coefficients, and INAV are indexed by windows, not just continuous timestamps.

• A window is a labeled period (for example, a calendar quarter, program year, or other defined interval).
• Listings (for example, NCU.Coastal.2026Q2) are always tied to a specific window.
• Coefficients such as $v,a,P,S,U$are defined per capital.class, per window, unless explicitly specified otherwise.

Section 2 uses the following conventions:

• Symbol t – a point in time (for example, a reporting date) expressed as a timestamp.
• Symbol w – a window identifier (for example, 2026Q2), treated as an abstract label with a defined start and end.
• Symbol W\_c – the set of windows for a given capital.class $c$.

When an equation is written as:

$${Q}_{c,w}(t)$$ this denotes the quantity of credits for capital.class $c$ and window $w$ that is in a particular state (for example, circulating) at time $t$.

Implementations shall ensure that:

• any window used in listings and equations has a clear start and end;
• events and corporate actions that affect a listing are timestamped and can be ordered within or across windows;
• reporting periods for INAV are clearly associated with windows and times (for example, “INAV at end of 2026Q2”).

S2.0.5 Geometry and Place Representation

VLAS is explicitly place-based. Assets and programs are associated with places, which must be represented in a way that is precise enough for:

• environmental and social integrity (for example, spatial overlap checks), and
• alignment with external frameworks (for example, SEEA, jurisdictional boundaries).

Conventions:

• A place shall be represented as a polygon or multipolygon with an associated coordinate reference system (CRS).
• Each place shall have a stable identifier (place\_id) and may have multiple geometric representations (for example, different CRS, resolutions) linked to the same logical place.
• Asset identifiers (asset\_id) shall be linked to one or more places via Sys.DigitalTwin or an equivalent graph.

Where area is needed in equations (for example, in A\_cap), the standard shall specify:

• the units to use (for example, m2 or ha), and
• whether area refers to:
  • the entire place,
  • the part of the place relevant to the method, or
  • the part of the place attached to a specific asset.

Implementations should align place representations with established environmental accounting standards (for example, SEEA EA) but the VLAS requirement is: geometries must be unambiguous and sufficient to support the integrity logic defined in Layer 0.

S2.0.6 Execution Artifacts and Equation Grammar

VLAS equations, guards, and workflows are expressed in an abstract grammar (VLAS-DSL) and compiled into execution artifacts (BPMN, DMN, code) by Sys.HAIL.

Conventions for Section 2:

• Equation names
  • Equations are referenced as L<layer>.Eq.<Name> (for example, L3.Eq.PrimaryAllocation, L4.Eq.Kernel, L8.Eq.NAV).
  • Flows and processes are referenced as L<layer>.Flow.<Name> (for example, L2.Flow.VerifierApproval).
• Display equations
  • Normative equations in this section shall be written in LaTeX-style display form, on their own line, enclosed by \\[ and \\].
  • Every display equation shall be followed by a “where” clause defining all symbols used in that equation.
• Execution artifacts
  • For each equation or flow defined in Section 2, at least one of the following execution artifacts should exist in conformant implementations:
    • a BPMN or equivalent workflow model for human and system steps,
    • a DMN or equivalent decision table for discrete choices,
    • a code implementation generated by Sys.HAIL (Sys.CalcService logic).
  • Execution artifacts shall not contradict the equations and symbol definitions given in Section 2.
• Textual references
  • When Section 2 references an equation in narrative, it will use the canonical label (for example, “as defined in L3.Eq.PrimaryAllocation”) and the variables will be those defined in this glossary.

In cases where an implementation needs additional derived variables, intermediate computations, or convenience functions, these:

• may be added in the execution layer, but
• shall not change the meaning of the core variables and equations defined in this section.

S2.1 Core Capital & Class Terms

S2.1.1 The Five Capitals (Canonical Domains)
This standard provides a holistic framework for measuring verified regenerative actions across Five Capitals. All issued credits MUST be classified under one of these five domains. The canonical domains are {Natural (N), Human (H), Social (S), Built/Manufactured (M), Financial (F)}.

S2.1.2 Credit Class (unchanged, but now follows directly)
Credit Class — A class label within a capital domain that defines units and method families.
Type: enumeration keyed as NCU, HCU, SCU, MCU, FCU (Natural, Human, Social, Manufactured, Financial Capital Units).

Examples (illustrative):

• NCU.Watershed — Water retention and habitat uplift
  Units: e.g., m³, ha·yr, or dimensionless index 1, declared per method.

• MCU.Energy — Avoided energy use or reliability gains
  Units: e.g., kWh·yr or equivalent reliability metric.

• HCU.Training — Human capacity uplift
  Units: e.g., people·yr or index 1.

External alignment (informative):

• Nature classes can be mapped to SEEA Ecosystem Accounting place-based stocks and flows.
• Carbon-relevant flows can align with ISO 14064-1 where t ``CO₂e is the declared unit.
• Long-lived removal or storage methods may support EU CRCF certification dossiers for specific NCU subclasses.

Listing — Market-facing symbol defined as capital.class.window (e.g., NCU.Coastal.2026Q2).
Fungibility is confined to the listing scope: two credits are fungible only if they share the same capital, class, and window and meet all class-specific equivalence conditions declared in the class specification.

S2.2 Variables, Parameters, and Functions (with types, units, ranges)

Observation

VLAS explicitly separates:

• What changed — the integrity uplift, $\Delta I$,
  from

• How it behaves in time — velocity $v$and acceleration $a$,
  and

• How durable, well-governed, and certain it is — permanence $P$, stewardship $S$, and uncertainty $U$.

This separation allows clear, transparent governance in the math itself, not in footnotes or off-ledger adjustments.

Each variable below is defined with:

• Type — including whether it is dimensionless or carries a UCUM unit;
• Range — closed or half-open interval;
• Example or interpretation — including where it is used in the VLAS stack.

S2.2.1 Integrity and Routing Variables

ΔI — Integrity uplift (baseline-adjusted outcome)

• Meaning: Normalized uplift in integrity between a declared baseline and reporting window, after all method-specific adjustments (e.g., baselines, leakage, additionality, sampling corrections) are applied.
• Type:
  • Fraction (unitless, UCUM code 1) when the method declares an index or normalized score; or
  • Dimensioned scalar when the method declares a physical unit (e.g., t ``CO₂e, ha, m³).
• Range:
  • If fractional/index: $\left[ 0 , 1 \right]$.
  • If physical: method-specific nonnegative range, typically $[0,+ \infty )$.
• Example: Canopy cover rises from 42% → 50% over the baseline window; the method normalizes this change to $\Delta I=0.08$(dimensionless).

α_c — Primary allocation weight to capital $c$

• Meaning: Fraction of the integrity uplift $\Delta I$allocated directly to capital $c$(N, H, S, M, or F) by the Capital Router.
• Type: Fraction (unitless).
• Range: $\left[ 0 , 1 \right]$.
• Constraint (non-inflation):

$$\sum_{c} {{ \alpha }_{c}} \leq 1.$$

• Example:
  $\alpha ={N:0.8,M:0.2}$allocates 80% of $\Delta I$to NCU and 20% to MCU.

β_{c \to c’} — Spillover dampener from capital $c$to capital ${c}^{'}$

• Meaning: Fraction used to propagate a portion of uplift in capital $c$into spillover effects in another capital ${c}^{'}$, without inflating total system integrity.
• Type: Fraction (unitless).
• Range: $\left[ 0 , 1 \right]$.
• Constraint (non-inflation, per source capital):

$$\forall c:\sum_{{c}^{'}} {{ \beta }_{c \rightarrow {c}^{'}}} \leq 1.$$

• Example:
  ${ \beta }_{\left\{ N \rightarrow H \right\}}=0.25$yields a Human Capital spillover
  $\Delta {I}_{H}=0.25 \times \Delta {I}_{N}$.

W_i — Aggregation weight for sub-indicators $i$

• Meaning: Weight for combining multiple normalized sub-indicators into a single composite indicator inside an adapter (e.g., combining soil carbon, infiltration, and biodiversity into one integrity index).
• Type: Fraction (unitless).
• Range: $\left[ 0 , 1 \right]$.
• Constraint (convex combination):

$$\sum_{i} {{W}_{i}}=1.$$

• Use: Applied within adapter logic to aggregate sub-indicators before or as part of computing $\Delta I$and/or coefficients.

S2.2.2 Temporal and Quality Coefficients

These coefficients qualify the behavior and trust level of the uplift in time and governance.

v — Velocity of integrity uplift (first derivative)

• Meaning: Rate of change of integrity uplift over time in the relevant window (e.g., per month, per year). Captures how fast the system is improving.
• Type:
  • Rate[1/time] when $\Delta I$is dimensionless, or
  • Unit-consistent rate when $\Delta I$has units (e.g., t ``CO₂e`` / year, m³ / year).
• Range: Bounded interval declared per method and window, typically $\left[ {v}_{min} , {v}_{max} \right]$. Bounds are used as guards against gaming via short windows or noisy spikes.
• Use: Input to the Temporal Engine and Issuance Engine; can be used directly or via exponents in the issuance kernel.

a — Acceleration of integrity uplift (second derivative)

• Meaning: Second derivative of integrity uplift with respect to time. Captures whether integrity improvement is accelerating, stable, or decelerating.
• Type:
  • Rate²[1/time²] when $\Delta I$is dimensionless, or
  • Unit-consistent second derivative (e.g., t ``CO₂e`` / year²).
• Range: Method-declared bounded interval $\left[ {a}_{min} , {a}_{max} \right]$, with caps to limit short-window artifacts and numeric instability.
• Use: Used by the Temporal Engine and Issuance Engine, often as a leverage term for methods that reward sustained acceleration or penalize volatility.

P — Permanence coefficient (durability / reversal risk)

• Meaning: Measures expected durability of uplift and exposure to reversal. This may encode contractual covenant length, ecological persistence, hazard risk, buffer structures, and legal protection.
• Type: Fraction (unitless).
• Range: $(0,1]$.
• Interpretation:
  • Values near 1 indicate high durability and low reversal risk.
  • Values materially less than 1 encode higher reversal risk and/or shorter durability bands.
• External alignment (informative):
  Methods may map permanence bands and buffer arrangements to categories used in policy or certification regimes (e.g., long-lived vs. short-lived removals) but the VLAS permanence coefficient $P$governs issuance math.

S — Stewardship coefficient (governance quality & FPIC)

• Meaning: Encodes the quality of governance, community benefit structures, and FPIC (Free, Prior, and Informed Consent) status into a single multiplicative factor.
• Type: Fraction (unitless).
• Range: $\left[ 0 , 1 \right]$.
• Interpretation:
  • $S=1.0$only when FPIC is valid, stewardship commitments are in force, and relevant governance checks are met.
  • Breaches in governance, FPIC withdrawal, or material non-compliance reduce $S$or block recognition entirely, per method- and adapter-level rules.

U — Uncertainty deduction (conservative haircut)

• Meaning: Encodes overall uncertainty in measurement, modeling, sampling, and verification into a single discount factor, applied as a reduction in effective quantity.
• Type: Fraction (unitless).
• Range: $[0,1)$.
• Interpretation:
  • Higher $U$means higher uncertainty and therefore a larger deduction.
  • $U$may be derived from verification tier, sampling error estimates, model uncertainty bands, and other method-specific factors.
• Use: The issuance kernel typically applies a factor $\left( 1 - U \right)$to enforce conservative recognition of uncertain uplift.

S2.2.3 Issuance, Scaling, and Identification

Q — Issued quantity (credit units)

• Meaning: The final quantity of credits issued for a given capital·asset·window, after routing, temporal qualification, permanence, stewardship, and uncertainty have been applied.
• Type: Quantity[unit per class]; unit is declared by the Credit Class (e.g., t ``CO₂e, ha·yr, index 1).
• Range: Nonnegative: $Q \geq 0$.

Normative Issuance Kernel (canonical form)

For a given routed capital slice $\Delta {I}_{c}$and coefficient set $\left( v , a , P , S , U \right)$in a specified window, a common class of VLAS methods use the following kernel:

$$Q={A}_{\text{cap}} \cdot \Delta {I}_{c} \cdot P \cdot S \cdot {v}^{{ \alpha }_{\text{kern}}} \cdot {a}^{{ \beta }_{\text{kern}}} \cdot (1-U),$$

where:

• ${A}_{\text{cap}}$is an area or asset scale factor (if applicable);
• ${ \alpha }_{\text{kern}}$and ${ \beta }_{\text{kern}}$are kernel exponents (distinct from routing weights ${ \alpha }_{c}$); and
• the method may set ${ \alpha }_{\text{kern}}=0$or ${ \beta }_{\text{kern}}=0$when velocity or acceleration are not used.

Important:

• The exact kernel form and exponents MUST be declared in the method’s equation definition and associated adapter.
• All kernel parameters and exponents MUST be part of the signed ruleset and appear in the Data.CalcProof so that an auditor can recompute $Q$from first principles.

A_{\text{cap}} — Area / asset scale factor

• Meaning: Scale factor used for area- or asset-bounded methods (e.g., hectares of land, kilometers of river, number of devices).
• Type: Scalar[unit], with units declared by the method (e.g., ha, km, devices).
• Use: Some methods multiply normalized $\Delta I$(dimensionless) by ${A}_{\text{cap}}$to produce dimensioned $Q$in class units (e.g., t ``CO₂e, m³, ha·yr).

S2.2.4 Identifiers and Ruleset Anchors

These variables ensure every calculation is uniquely tied back to place, time, ruleset, and evidence.

place_id — Place identifier

• Meaning: Stable identifier for the geographic place (or set of places) to which measurements and credits apply.
• Type: UUID (stable over time).
• Fields (in associated metadata): Polygon vertices, coordinate reference system (CRS), validity interval.
• Use: Supports crosswalks to public statistics and ecosystem accounts, and avoids ambiguity about where integrity is measured and credited.

window — Time window for fungibility and accounting

• Meaning: Defines the time slice during which integrity is measured, credited, and considered fungible (e.g., 2026Q2, 2026H1, calendar year).
• Type: ISO 8601 period representation.
• Constraint: Coefficients, listings, and fungibility are window-pinned; a credit’s listing, coefficients, and admissible price must all reference the same window.

ruleset_id — Signed bundle ID for active artifacts

• Meaning: Identifier for the full, signed bundle of artifacts (equations, DMN decision tables, BPMN process definitions, adapters, tests) used in a given calculation.
• Type: String (includes semantic version and cryptographic digest, e.g., semver + sha256).
• Use: Appears in Data.CalcProof, Data.CUTMetadata, and audit bundles so that any calculation can be tied unambiguously to the exact logic and configuration used.

adapter_id — AdapterSpec identifier

• Meaning: Identifier for the Ontology Adapter specification (method mapping + routing configuration $\alpha , \beta$+ coefficient schedules) used for a given IndicatorPackage.
• Type: String; semver; signed.
• Use: Ensures all routing, coefficient derivations, and unit transformations are traceable to a specific, versioned adapter.

bundle_hash — IndicatorPackage Merkle root

• Meaning: Cryptographic root hash of the entire IndicatorPackage, including values, provenance, and attachments.
• Type: sha256 (hex).
• Use: Provides tamper-evidence and replay protection; appears in Data.CalcProof and registry records to bind credits to the exact measurement evidence used.

ucum — UCUM unit code for magnitudes

• Meaning: The UCUM (Unified Code for Units of Measure) code used for every magnitude (e.g., m3, kg, t{CO2}e, %, 1).
• Type: Code string.
• Use: Engines SHALL reject bare numbers; all magnitudes MUST carry a UCUM unit (or 1 for dimensionless quantities). This ensures unambiguous, machine-parseable units across the VLAS stack.

S2.3 Objects and Data Structures (Normative)

This subsection defines the canonical data objects used across the VLAS stack. For each object, it specifies:

• purpose and scope,
• where it lives in the 8-layer architecture,
• minimum required contents at Section 2 level, and
• how it links to other artifacts.

Field-by-field schemas and types can be represented in JSON Schema, DTDL, or equivalent, but the semantics and minimum contents here are normative.

S2.3.1 Data.IndicatorPackage (Layer 2 — Input Parser & Governance)

Purpose

Data.IndicatorPackage is the canonical ingest bundle for VLAS. It contains the indicators, provenance, governance evidence, and adapter references for a given asset or program and window. It is the only admissible input to the calculation stack at Gate 1.

Scope

• One IndicatorPackage may cover one or more assets within a place for a single time window (or a defined set of windows if the method requires), under a single AdapterSpec.
• Multiple IndicatorPackages may exist for the same place and window if more than one method or adapter is in use.

Minimum Contents

At a minimum, Data.IndicatorPackage SHALL include:

• Identifiers
  • package\_id — unique identifier.
  • place\_id — logical place identifier.
  • asset\_ids``[] — one or more asset identifiers.
  • window — applicable time window(s).
  • adapter\_id and adapter\_version — link to the AdapterSpec.
• Indicators (indicators.json)
  • indicator\_name — canonical indicator label.
  • value — numeric value.
  • ucum — UCUM unit code for the value or 1 if dimensionless.
  • timestamp or period — when the measurement applies.
  • QA\_grade or equivalent quality flag(s).
  • Optional: error\_band, confidence\_interval, or other uncertainty descriptors.
• Provenance (provenance.json)
  • devices, labs, methods, and actors involved in measurement;
  • sampling frames, baselines, and data-processing steps;
  • references to legal or program documentation relevant to the measurement process.
• Governance evidence
  • FPIC\_state — FPIC status (e.g., valid, not\_required, revoked, disputed), with date and reference;
  • links or attachments for community agreements, governance documents, and any local consent processes.
• Attachments (attachments/)
  • supporting files (e.g., lab reports, shapefiles, photos, PDF agreements), referenced by stable URIs.
• Hashing and signatures
  • bundle\_hash — cryptographic hash over indicators, provenance, governance metadata, and attachments;
  • one or more steward signatures attesting that the package is complete and correct to the best of their knowledge.

Gate and Layer Linkage

• Layer: L2 (Input Parser & Governance).
• Gate: Gate 1 (Verifier approval).
• Only IndicatorPackages with an explicit Gate 1 approval (Verifier signature over bundle\_hash and FPIC\_state) MAY be used as inputs to Sys.CalcService for issuance calculations.

S2.3.2 Data.CalcProof (Layer 5 — Issuance Engine & Gate 2)

Purpose

Data.CalcProof is the canonical proof that a specific issuance calculation has been performed under a specific ruleset and adapter, using specific input data and parameters. It binds:

• logic (ruleset),
• data (IndicatorPackage and coefficients), and
• results (credit quantities Q).

No VLAS credits may be recognized without an associated, approved CalcProof.

Scope

• One CalcProof may cover one or more capital classes, assets, and windows, as long as the same ruleset and adapter are used and the calculation context is coherent (per method and governance).

Minimum Contents

At a minimum, Data.CalcProof SHALL include:

• Identification and configuration
  • calc\_proof\_id — unique identifier.
  • ruleset\_id and ruleset\_version — link to the DSL and compiled artifacts.
  • adapter\_id and adapter\_version — link to the AdapterSpec.
  • place\_id and asset\_ids``[] — scope.
• Input references
  • bundle\_hash — hash of the IndicatorPackage used.
  • references to any pre-computed coefficients (v, a, P, S, U), or declarations that they were derived in-line from IndicatorPackage + AdapterSpec under the ruleset.
  • optional references to any external tables or benchmark curves declared in the ruleset.
• Parameters and coefficients
  • explicit values of:
    • $\Delta I$(integrity uplift) per capital slice,
    • routing weights ${ \alpha }_{c}$,
    • spillover dampeners ${ \beta }_{c \rightarrow {c}^{'}}$,
    • coefficients $v,a,P,S,U$per capital.class and window,
    • any kernel exponents ${ \alpha }_{\text{kern}},{ \beta }_{\text{kern}}$or other kernel parameters,
    • scale factors such as ${A}_{\text{cap}}$if applicable.
• Outputs
  • issued quantities $Q$by capital.class and window;
  • any held-back quantities (e.g., due to uncertainty), with conditions for potential RELEASE_U;
  • any diagnostic flags (e.g., warnings about parameter edge-cases that still passed guards).
• Equation and test references
  • explicit reference to the equations used (e.g., L3.Eq.PrimaryAllocation, L4.Eq.Kernel), including canonical LaTeX representation;
  • golden test IDs and results;
  • guard checks and their outcomes.
• Hashes and signatures
  • cryptographic hashes over:
    • inputs (IndicatorPackage references, coefficients, parameters),
    • the compiled representation used, and
    • the output Q vector and summary;
  • Sys.CalcService signature (or the appropriate system signer) confirming the calculation;
  • Gate 2 approver signature (Role.Verifier in issuance mode or delegated governance role) indicating “approved” or “rejected”.

Gate and Layer Linkage

• Layer: L5 (Issuance Engine).
• Gate: Gate 2 (CalcProof approval).
• Only CalcProofs with an explicit Gate 2 approval MAY be used by Sys.Registry to recognize credits.

S2.3.3 Data.CUTMetadata (CreditLot) (Layer 6 — Registry & Tokenization)

Purpose

Data.CUTMetadata (often referred to as CreditLot) defines a lot of VLAS credits issued as a result of one or more CalcProofs. It is the primary record of what each credit lot is, how it was created, and under which conditions it exists.

Scope

• One CreditLot corresponds to a specific capital.class, window, and set of provenance attributes (ruleset, adapter, place, method family, etc.).
• Lots MAY be subdivided operationally, but their identity and origin remain anchored to a single CUTMetadata record.

Minimum Contents

At a minimum, Data.CUTMetadata SHALL include:

• Identifiers
  • lot\_id — unique identifier.
  • capital\_class — e.g., NCU.Coastal, HCU.Health.
  • window — e.g., 2026Q2.
  • listing\_symbol — canonical listing string (e.g., NCU.Coastal.2026Q2).
• Issuance context
  • quantity\_issued — initial $Q$at issuance, with UCUM unit and precision;
  • ruleset\_id and ruleset\_version used;
  • adapter\_id and adapter\_version;
  • calc\_proof\_id (or references if multiple proofs are aggregated, as allowed by the standard).
• Provenance annotation
  • place\_id and asset\_ids``[] or asset-group identifiers;
  • method family and/or program tags;
  • optional: stewardship and permanence band labels if required for reporting or pricing.
• State fields
  • status — enumeration (e.g., ISSUED, CIRCULATING, RETIRED, BURNED, VOID);
  • current\_holder — account or entity ID, or “program pool” if held in a shared account;
  • optional: partitioning or tagging fields for use by portfolios or sub-ledgers.

Relationship to Corporate Actions

• The circulating quantity of a lot at any time $t$is not stored as an independent, editable field; it is derived from the initial quantity\_issued and the sequence of Data.CorporateAction entries applied to lot\_id.
• Any implementation convenience fields for “current balance” MUST be consistent with the event-sourced reconstruction from corporate actions and treated as cache only.

Gate and Layer Linkage

• Layer: L6 (Registry & Tokenization).
• CreditLots do not themselves pass through gates; they are created and modified only via corporate actions authorized by previously approved CalcProofs and governance processes.

S2.3.4 Data.CorporateAction (Layer 6 — Registry & Tokenization)

Purpose

Data.CorporateAction records every change to the lifecycle or balance of a CreditLot. Together, all corporate actions form an event-sourced ledger from which circulating quantities and positions are derived.

Scope

• Each entry affects exactly one lot\_id (or a formally defined grouping if the standard introduces batch actions).
• Sequences of corporate actions define the lifecycle of a lot from issuance to final state (e.g., retired or void).

Minimum Contents

At a minimum, Data.CorporateAction SHALL include:

• Identifiers
  • corporate\_action\_id — unique identifier.
  • lot\_id — identifier of the affected lot.
  • action\_type — one of {ISSUE, RELEASE\_U, TRANSFER, RETIRE, BURN, …} as defined in S2.4.
• Quantitative impact
  • quantity\_change — numeric delta applied to the lot’s balance (with UCUM unit and sign convention);
  • optional: closing\_balance as a computed convenience value, for ease of reporting and reconciliation.
• Context
  • timestamp — when the action took effect;
  • initiator — identity and role (e.g., Role.Registrar acting for a particular program);
  • authorization\_reference — link to contractual basis, program rule, or governance decision enabling the action;
  • optional: tags for reason codes (e.g., “programmatic retirement”, “fraud reversal”, “buffer release”).
• Linkages
  • reference to calc\_proof\_id where relevant (e.g., ISSUE and some BURN actions);
  • reference to counterparties for TRANSFER (from/to account or holder IDs).

Lifecycle Equation (Position Roll-forward)

For any lot and holder, positions MAY be defined using the standard roll-forward form (see also S2.4), for example:

$$\text{closing}=\text{opening}+\text{ISSUE}+\text{RELEASE\_U}-\text{TRANSFER\_out}+\text{TRANSFER\_in}-\text{RETIRE}-\text{BURN}.$$

Implementations MAY maintain per-lot and per-holder positions, but the authoritative state for circulating quantities is always reconstructible from the full set of Data.CorporateAction entries.

S2.3.5 Data.Position (Derived; Layers 6 and 8)

Purpose

Data.Position represents a holder-level balance in a given capital.class and window, derived from:

• the initial issuance (CreditLots), and
• the full sequence of corporate actions affecting those lots.

Positions are used heavily by Sys.NAVService and reporting.

Scope

• A Position is usually defined at the granularity of (``holder\_id``, ``capital\_class``, window) and MAY include additional breakdown dimensions (e.g., by program, vehicle, segment).

Minimum Contents

At a minimum, a Position record SHALL include:

• holder\_id — account or entity identifier;
• capital\_class — e.g., NCU.Coastal;
• window — e.g., 2026Q2;
• opening\_balance — balance at the start of the reporting period;
• closing\_balance — balance at the end of the reporting period;
• activity\_summary — aggregated ISSUE, RELEASE_U, TRANSFER_in, TRANSFER_out, RETIRE, BURN for the reporting period, with units.

The canonical roll-forward equation above applies at the Position level as well; it MUST be consistent with the event-sourced ledger of corporate actions.

Layer Linkage

• Layer 6: Positions are a derived view used by registry and operational systems.
• Layer 8: Sys.NAVService uses Positions (or per-lot balances that aggregate to Positions) as the quantity input to the INAV equation for each class and window.

S2.3.6 Data.NAVSnapshot and Data.MonthlyAuditPack (Layer 8 — Portfolio & Reporting)

Purpose

Data.NAVSnapshot and Data.MonthlyAuditPack form the top-level reporting bundle for INAV and related portfolio metrics. They are the primary artifacts used at Gate 3 and for external assurance and disclosure.

Scope

• NAVSnapshot — a single point-in-time view of INAV(t) and decompositions.
• MonthlyAuditPack — a period bundle (monthly or other governed reporting frequency) containing NAVSnapshot(s) and all supporting evidence required for re-performance.

Data.NAVSnapshot – Minimum Contents

A NAVSnapshot for reporting date $t$SHALL include:

• snapshot\_id — unique identifier;
• timestamp — the reporting time $t$;
• period or window\_set — which window(s) this snapshot covers;
• INAV — total INAV(t) value;
• decompositions:
  • by capital domain (N, H, S, M, F),
  • by capital.class,
  • by window (e.g., per listing);
• references to:
  • positions used (e.g., summary or hash of Position records),
  • pricing inputs (marks) used for each listing,
  • registry state and corporate actions up to $t$;
• summary of:
  • exceptions, overrides, or restatements affecting this snapshot, if any.

Data.MonthlyAuditPack – Minimum Contents

A MonthlyAuditPack (or equivalent period pack) SHALL include:

• one or more NAVSnapshots for the period;
• a capital balance sheet and detailed holdings breakdowns;
• extracts or hashed references sufficient to reconstruct:
  • credit quantities by capital.class and window (Positions + underlying lot balances),
  • admissible prices by capital.class and window,
  • the application of the INAV equation;
• logs and summaries for:
  • IndicatorPackages and CalcProofs relevant to new issuance in the period,
  • registry corporate actions in the period,
  • pricing events (including any fallbacks or benchmark-only pricing),
  • any restatements or corrections relating to past periods that were recognized in this reporting window;
• signatures:
  • Role.NAVCommittee signoff;
  • any additional governance signatures required by the trust or program.

Gate and Layer Linkage

• Layer: L8 (Portfolio & Reporting).
• Gate: Gate 3 applies to the MonthlyAuditPack (and its included NAVSnapshots). Only packs with explicit NAV Committee signoff are valid for external INAV reporting.

S2.4 Events, Gates, and States (Normative)

VLAS is defined not only by its variables and objects, but by a finite set of events, lifecycle states, and human gates that together determine:

• which data are admissible,
• which calculations are accepted, and
• which credit positions can be recognized in INAV.

This section defines:

• lifecycle states of CreditLots,
• allowed corporate action types,
• Gate 1 / Gate 2 / Gate 3 and their scope, and
• how events are ordered and interpreted over time.

S2.4.1 Lifecycle States of CreditLots

Every CreditLot (Data.CUTMetadata) SHALL be in exactly one of the following lifecycle states at any given time:

Figure 11 — State transitions from ISSUED to terminal states. Every transition is a signed corporate action.

• ISSUED
  Credits have been created from an approved CalcProof, are recognized on the registry, and may be held, transferred, or retired.

  • These credits may or may not yet be “circulating” depending on program design (for example, some or all may be held in a buffer pool).

• HELD_U
  Credits that have been issued but are held back from circulation pending resolution of uncertainty. The holdback fraction is declared at lot formation per the Lot Formation Framework (S1.4.4a). Credits in HELD_U are recognized on the registry and count toward total issuance, but SHALL NOT be included in circulating quantity for INAV or transferred to third parties. Transition to CIRCULATING occurs only via a RELEASE_U corporate action triggered by a verification event that reduces uncertainty.

• HELD_BUFFER
  Credits set aside as a buffer pool contribution against reversal risk. Buffer lots are linked to their parent lot via buffer_lot_ref in Data.CUTMetadata. Credits in HELD_BUFFER SHALL NOT be included in circulating quantity, transferred, or retired for obligation fulfillment. They may be released to CIRCULATING via governance-approved RELEASE_BUFFER action (if reversal risk is resolved) or BURNED (if a reversal occurs and the buffer is consumed).

• CIRCULATING
  Credits are issued and available for transfer or retirement; they are eligible to appear in holdings and INAV calculations if held by an eligible holder.

  • “Circulating” status is determined by the net effect of corporate actions (ISSUE, RELEASE_U, TRANSFER, RETIRE, BURN) as defined below.

• RETIRED
  Credits have been permanently taken out of circulation to satisfy an obligation or commitment (for example, offset, covenant, or program requirement). They SHALL NOT be transferred again.

• BURNED
  Credits have been removed due to integrity reasons (for example, reversal, fraud, or material method failure). Burned credits SHALL NOT be counted toward obligations or INAV.

• VOID
  Credits that were improperly issued and invalidated before use. VOID is typically reserved for exceptional cases where issuance itself is rescinded. VOID lots are invisible to INAV and obligations.

Implementations MAY maintain additional internal states for operational purposes, but they MUST map cleanly into this canonical set without ambiguity.

S2.4.2 Corporate Action Types

All CreditLot lifecycle changes and balance movements SHALL be expressed using a limited set of corporate actions. No other mechanism (for example, directly editing balances) is permitted.

The canonical set of action types is:

• ISSUE
  • Creates a new lot or increases the issued quantity of an existing lot, based on one or more approved CalcProofs.
  • Increases the total supply for that lot and class.
  • Requires reference to the CalcProof and ruleset used.
• RELEASE_U
  • Moves quantity from “held back due to uncertainty” into active circulation when uncertainty is resolved favorably and governance rules permit.
  • Does not change the total issued quantity; it changes the distribution between held-back and circulating.
  • Requires evidence and, where specified, additional approvals.
• TRANSFER
  • Moves quantity from one holder to another within the same lot and class.
  • Does not change total issued or circulating supply; only redistributes who holds it.
  • Requires identification of source and destination holders and authorization basis.
• RETIRE
  • Permanently removes quantity from circulation to satisfy obligations or commitments.
  • Decreases circulating supply and the holder’s balance; the retired quantity remains visible for audit but is not tradable or usable again.
• BURN
  • Removes quantity due to integrity, compliance, or fraud issues.
  • Decreases total issued supply and circulating balances.
  • MUST reference the incident or decision causing the burn (for example, reversal event, method deprecation, or fraud finding).
• RELEASE_BUFFER
  • Moves quantity from HELD_BUFFER state into CIRCULATING when reversal risk is resolved and governance rules permit, or BURNS the buffer lot when a reversal event consumes it.
  • Requires governance approval and evidence that the reversal risk period has passed or the buffer is no longer needed.
  • The parent lot’s Data.CUTMetadata MUST be updated to reflect the buffer release or consumption.

Other standardized action types MAY be added by future versions of the standard, but any new type MUST:

• have a clear effect on balances and states, and
• be expressible as a transformation on the same roll-forward equation described below.

Canonical roll-forward equation

For any lot, the circulating quantity at time $t$, denoted $\text{circ}(t)$, is given by:

$$\text{circ}(t)={\text{ISSUE}}_{\left[ 0 , t \right]}+{\text{RELEASE\_U}}_{\left[ 0 , t \right]}+{\text{RELEASE\_BUFFER}}_{\left[ 0 , t \right]}-{\text{RETIRE}}_{\left[ 0 , t \right]}-{\text{BURN}}_{\left[ 0 , t \right]},$$

where:

• ${\text{ISSUE}}_{\left[ 0 , t \right]}$is the sum of all ISSUED quantity for the lot up to time $t$;
• ${\text{RELEASE\_U}}_{\left[ 0 , t \right]}$is the sum of all RELEASE_U quantity up to time $t$;
• ${\text{RELEASE\_BUFFER}}_{\left[ 0 , t \right]}$is the sum of all RELEASE_BUFFER quantity up to time $t$;
• ${\text{RETIRE}}_{\left[ 0 , t \right]}$is the sum of all RETIRED quantity up to time $t$;
• ${\text{BURN}}_{\left[ 0 , t \right]}$is the sum of all BURNED quantity up to time $t$.

Transfers affect who holds circulating quantity but not the total $\text{circ}(t)$; their effect is captured in holder-level Positions, not in the lot-level total.

S2.4.3 Gate Definitions: Gate 1, Gate 2, Gate 3

Gates are human-in-the-loop approval points anchored to specific artifacts and layers:

• Gate 1 — IndicatorPackage Validation
  • Layer: L2 (Input Parser & Governance).
  • Artifact: Data.IndicatorPackage.
  • Role: Role.Verifier (or equivalent) approves or rejects the package.
  • Outcome: Only Gate 1–approved packages may be used for issuance calculations.
• Gate 2 — Issuance Calculation Proof Approval
  • Layer: L5 (Issuance Engine).
  • Artifact: Data.CalcProof.
  • Role: Gate 2 approver (often Role.Verifier with issuance authority, or a delegated governance role) approves or rejects the CalcProof.
  • Outcome: Only Gate 2–approved CalcProofs may be used as the basis for ISSUE actions in Sys.Registry.
• Gate 3 — INAV and Audit Pack Signoff
  • Layer: L8 (Portfolio & Reporting).
  • Artifact: Data.MonthlyAuditPack (which includes one or more NAVSnapshots).
  • Role: Role.NAVCommittee approves or rejects the pack.
  • Outcome: Only Gate 3–approved packs define official INAV for external reporting and assurance.

At each gate:

• The decision is a signature over a specific artifact and its hash, not a free-form narrative.
• A rejected artifact does not vanish; it remains part of the audit trail with status and decision reason.

S2.4.4 Gate Inputs, Outputs, and Evidence (Summary)

For clarity, the minimum input, output, and evidence requirements for each gate are:

Gate 1 – IndicatorPackage Validation

• Input
  • Data.IndicatorPackage (with bundle\_hash, indicators, provenance, governance evidence, adapter_id).
• Checks (minimum)
  • All required indicators present and within type/unit expectations of the AdapterSpec.
  • QA/QC and completeness checks pass.
  • Governance requirements (FPIC or equivalent) met or correctly classified as not\_required.
  • No material inconsistencies between indicators and provenance.
• Output
  • Gate 1 decision: approved or rejected.
  • Verifier signature over bundle\_hash, with decision and timestamp.
• Effect
  • Approved packages become admissible inputs to Sys.CalcService; rejected packages MUST NOT be used for issuance.

Gate 2 – CalcProof Approval

• Input
  • Data.CalcProof (with ruleset\_id, adapter\_id, bundle\_hash, parameters, coefficients, Q outputs, test and guard results).
• Checks (minimum)
  • The bundle\_hash corresponds to a Gate 1–approved IndicatorPackage.
  • ruleset\_id and adapter\_id are approved and not deprecated for the relevant period and method.
  • All required tests and guards passed (e.g., range checks, non-inflation conditions on α and β).
  • No evidence of tampering with parameters or coefficients.
• Output
  • Gate 2 decision: approved or rejected.
  • Gate 2 approver signature over CalcProof hash with decision and timestamp.
• Effect
  • Approved CalcProofs MAY be used by Sys.Registry to create ISSUE corporate actions and CreditLots; rejected proofs MUST NOT lead to issuance.

Gate 3 – NAV / Audit Pack Signoff

• Input
  • Data.MonthlyAuditPack (NAVSnapshots, positions, registry extracts, pricing logs, restatement details).
• Checks (minimum)
  • Positions and balances reconcile to registry state and corporate actions.
  • Prices used are admissible per standard and governance (no unapproved marks).
  • INAV equation has been applied correctly using circulating quantities and admissible prices.
  • Any restatements and exceptions are clearly documented and justified.
• Output
  • Gate 3 decision: approved or rejected.
  • NAV Committee signatures over the pack hash, with decision and timestamp.
• Effect
  • Approved packs define official INAV and related metrics for the period; rejections require correction and resubmission.

S2.4.5 Event Ordering, Idempotency, and Time

VLAS relies on clear ordering of events and gate decisions.

Event ordering

• Corporate actions for a given lot SHALL be strictly ordered in time.
• If two actions have the same timestamp, an implementation SHALL define and document a deterministic tie-break (e.g., sequence number or insertion order).
• Replaying or reordering historical actions MUST NOT be allowed except under a controlled restatement process that leaves a clear audit trail.

Idempotency

• Gate decisions are idempotent for a given artifact and version:
  • Re-applying an “approved” decision to the exact same artifact and hash SHALL NOT create a new, logically distinct decision.
  • If an artifact changes (e.g., a corrected IndicatorPackage), it receives a new hash and must pass Gate 1 again; previous approvals do not automatically carry over.
• Corporate actions SHALL be treated as immutable once committed; any correction MUST be implemented via new actions that offset or amend previous ones, not by editing or deleting historical actions.

Time

• All events and decisions SHALL carry:
  • a timestamp in a precise, unambiguous format, and
  • a reference to the time zone or an agreed-upon universal time (for example, UTC).
• The reporting time $t$used for INAV(t) SHALL be clearly defined (e.g., “end of period”, “close of day”) and consistent with registry and pricing timestamps used in the calculation.

S2.4.6 State Machine Summary

Conceptually, the lifecycle of a CreditLot under VLAS can be viewed as a state machine:

• Pre-issuance:
  • IndicatorPackages exist; some are Gate 1–approved, others are not.
  • No CreditLots yet.
• Issue:
  • An approved CalcProof passes Gate 2.
  • Sys.Registry records an ISSUE action and creates a CreditLot in ISSUED and CIRCULATING state (unless a program intentionally holds some portion back in uncertainty or buffer accounts).
• Circulation:
  • TRANSFER actions move circulating quantity between holders.
  • RELEASE_U actions move previously held-back quantity into active circulation.
  • BURN or RETIRE actions reduce circulating quantity.
• Exit:
  • When a lot’s circulating quantity reaches zero, and no further ISSUE or RELEASE_U actions are permitted, it effectively exits the tradable pool.
  • RETIRED and BURNED credits remain visible for audit and accounting but cannot re-enter circulation.

Throughout:

• Gate 1 ensures only valid evidence enters the system.
• Gate 2 ensures only valid calculations and configurations lead to issuance.
• Gate 3 ensures only well-reconciled positions and admissible prices determine INAV.

S2.5 Pricing, Venues, and INAV Terms (Normative)

This subsection defines the canonical terms for pricing, venues, and Integrity Net Asset Value (INAV). These terms govern how prices are formed, which prices are admissible for INAV, and how quantities and prices combine in reporting.

S2.5.1 Listings, Lots, and Price Targets

VLAS distinguishes between listings, lots, and marks:

• A listing is the market-facing symbol capital.class.window (e.g., NCU.Coastal.2026Q2).
• A lot (CreditLot) is a specific issuance with its own lot\_id, linked to a listing and a provenance set.
• A mark is a price or value assigned to a listing or lot at a given time.

Listing-level mark

• Meaning: A price or value defined for the entire listing (e.g., all NCU.Coastal.2026Q2 credits that meet equivalence criteria).
• Type: Monetary quantity, typically CCY / unit where CCY is a currency (e.g., USD/{tCO2}e, EUR/NCU).
• Use: Primary input for INAV calculations when credits in the listing are fungible and no lot-level adjustments are required.

Lot-level mark

• Meaning: A price or value specific to a particular lot within a listing, used when quality, risk, or other attributes differ materially between lots.
• Type: Same as listing-level mark (CCY / unit).
• Use: Applied by Sys.PricingEngine where listing-level marks are insufficient (e.g., quality tiers, vintage differences, special attributes).

All marks used for INAV MUST be generated by Sys.PricingEngine under approved configurations.

S2.5.2 Venues and Benchmarks

Venue

• Meaning: A marketplace or trading platform where VLAS credits (or claims closely tied to them) are bought and sold under defined rules.
• Type: Enumeration with metadata (name, jurisdiction, market type, access conditions).
• Examples (illustrative):
  • Dedicated VLAS exchanges or auction platforms.
  • Registered marketplaces that list NCU, HCU, SCU, MCU, or FCU instruments.

Venues used for admissible pricing MUST meet criteria set by governance (e.g., minimum transparency, volume, and integrity requirements).

Benchmark curve

• Meaning: A function or table providing reference values (e.g., monetary value per unit) as a function of one or more variables (e.g., time, region, quality band).
• Type: Function or lookup table (e.g., f(window, region, ``quality\_band``) → value).
• Examples (illustrative):
  • Social cost of carbon curves.
  • Public valuations of water security or resilience.
  • Program-defined minimum values per capital class.

Benchmarks complement or, in some cases, substitute for market data where liquidity is limited or prices are bound by policy.

S2.5.3 Raw Price Observations and Aggregates

Trade

• Meaning: A recorded transaction on an approved venue where a quantity Q of a listing (or lot) changes hands for a price p.
• Core fields: timestamp, listing or lot reference, quantity, price, venue, buyer and seller identifiers (or anonymized aliases where required by privacy rules).

VWAP (Volume-Weighted Average Price)

• Meaning: Average traded price on a venue or venue set, weighted by traded volume over a specified period.
• Type: Monetary (CCY / unit).
• General formula:

$$VWAP=\frac{\sum_{k} {{p}_{k}} \cdot {q}_{k}}{\sum_{k} {{q}_{k}}},$$

where:

• ${p}_{k}$is the trade price for trade $k$;
• ${q}_{k}$is the trade quantity for trade $k$;
• the sum is over trades in the specified period and venue set.

VWAP is often a starting point for admissible marks, but not sufficient by itself if liquidity is thin, market quality is poor, or benchmarks impose constraints.

S2.5.4 Admissible Marks and L7.Eq.Mark

Admissible mark

• Meaning: A price value generated by Sys.PricingEngine that meets all criteria to be used in INAV calculations.
• Type: Monetary (CCY / unit).
• Requirements:
  • Derived from approved venues and/or benchmark curves.
  • Computed according to the canonical pricing equation L7.Eq.Mark or its method-specific variant declared in the ruleset.
  • Not manually set or overridden without following formal governance paths and leaving a full audit trail.

While the specific functional form of L7.Eq.Mark may be method- or class-dependent, its canonical structure is:

$${P}_{c,w}(t)={f}_{\text{Mark}}({\text{VWAP}}_{c,w}(t;V),{\text{Benchmarks}}_{c,w}(t;B),{\text{QualityAdjustments}}_{c,w},{\text{LiquidityFlags}}_{c,w}),$$

where:

• ${P}_{c,w}(t)$is the admissible price for capital.class $c$and window $w$at time $t$;
• ${\text{VWAP}}_{c,w}(t;V)$denotes VWAP(s) from the set of approved venues $V$;
• ${\text{Benchmarks}}_{c,w}(t;B)$refers to benchmark values from approved benchmark sets $B$;
• quality adjustments and liquidity flags encode any governance-approved adjustments (for example, discounts for thin markets or quality tiers).

The exact form of ${f}_{\text{Mark}}$MUST be declared in the ruleset and surfaced in the Data.CalcProof or pricing logs so an auditor can re-perform or reason about the mark.

Haircut

• Meaning: A multiplicative discount applied to a preliminary price or benchmark to account for specific risks (e.g., liquidity, credit risk, governance concerns, or regulatory requirements).
• Type: Fraction in $\left[ 0 , 1 \right]$.
• Application: Typically applied as ${P}^{'}={P}_{\text{base}} \cdot (1-h)$, where $h$is the haircut.

Any haircut used for admissible marks MUST be:

• defined in the ruleset or governance configuration;
• visible in pricing logs and audit packs;
• applied deterministically and not via ad hoc, opaque judgment.

S2.5.5 Price Bands, Timestamps, and Quality Flags

Price band

• Meaning: A governed range of acceptable prices for a listing or class in a given period (e.g., min and max admissible values).
• Type: Interval $\left[ {P}_{min} , {P}_{max} \right]$.
• Use: Guards to detect and reject obviously erroneous or manipulated prices.

If a computed mark lies outside the band, Sys.PricingEngine MUST either:

• fall back to an alternative pricing mode (e.g., benchmark-only) defined in the ruleset; or
• flag the mark as non-admissible for INAV, requiring governance intervention.

Price timestamp

• Meaning: The time at which the mark is considered valid.
• Type: Timestamp (e.g., ISO 8601 in UTC).
• Use: The INAV equation uses prices ${P}_{c,w}(t)$valid as of the reporting time $t$; timestamp alignment between marks and quantities must be clear.

Price quality flag

• Meaning: Indicator of how robust a particular mark is (e.g., high\_liquidity, benchmark\_only, thin\_market, fallback\_mode).
• Type: Enumeration.
• Use:
  • For internal risk management and disclosures.
  • For audit and regulatory scrutiny—e.g., to see where and why non-standard pricing modes were used.

S2.5.6 INAV: Integrity Net Asset Value

Definition

Figure 12 — Side-by-side reporting: financial return and regenerative return measured together.

Integrity Net Asset Value, INAV, is the portfolio-level value of circulating VLAS credits, computed by multiplying:

• circulating quantities of credits, and
• admissible prices for those credits,

and aggregating them across capitals, classes, windows, and lots.

The canonical equation is:

$$INAV(t)=\sum_{\text{capital, class, window, lot}} {\text{circulating\_quantity}(\text{capital, class, window, lot},t) \times \text{admissible\_price}(\text{capital, class, window, lot},t),}$$

where:

• $\text{circulating\_quantity}(\text{capital, class, window, lot},t)$is derived from CreditLots and Data.CorporateAction up to time $t$;
• $\text{admissible\_price}(\text{capital, class, window, lot},t)$is a mark produced by Sys.PricingEngine and accepted under the L7.Eq.Mark logic;
• the summation can be re-grouped by capital, class, window, or portfolio as needed, but the underlying definition remains unchanged.

INAV vs. other NAVs

• INAV is specifically the integrity-linked component of asset value, reflecting the market and benchmark valuation of VLAS credits.
• Other NAVs (for example, total fund NAV including conventional financial assets) MAY be defined at the vehicle level, but they MUST NOT be confused with INAV. Crosswalks and reconciliations MAY be included in audit packs as informative material.

Re-performability

A conformant implementation MUST provide sufficient data in the MonthlyAuditPack for an independent party to:

• reconstruct circulating quantities by listing and lot at time $t$;
• reconstruct or verify admissible prices used for each listing and lot;
• apply the INAV equation to obtain the reported value, within rounding tolerances.

If this is not possible, INAV reporting is considered non-conformant.

S2.6 Governance and Ethics Terms (Normative)

VLAS encodes governance and ethics into the math and the artifacts, not only into policy documents. This subsection defines the glossary-level terms that connect community rights, ethical safeguards, and governance structures to variables such as the stewardship coefficient $S$and to gate logic.

S2.6.1 Free, Prior, and Informed Consent (FPIC)

FPIC (Free, Prior, and Informed Consent)

• Meaning: A documented process through which affected communities and rights-holders have the opportunity to understand, deliberate on, and consent to activities that materially affect their rights, lands, waters, or livelihoods—without coercion, before implementation, and with access to relevant information and alternatives.
• Type: Governance status, not a numeric variable.

In VLAS:

• FPIC status is recorded in Data.IndicatorPackage (e.g., FPIC\_state), with evidence attached.
• FPIC status influences the stewardship coefficient $S$and, in some methods, may act as a hard gate (no recognition allowed if FPIC is invalid or revoked).
• FPIC status may evolve over time; changes MUST be recorded as new artifacts and may trigger recalculation, BURN, or other corrective actions.

Minimal FPIC states:

• valid — FPIC has been obtained and remains in force.
• not\_required — FPIC is not required (with justification consistent with governance rules).
• revoked — FPIC was previously granted and has been withdrawn.
• disputed — FPIC status or process is under dispute.

Implementations MAY refine this taxonomy, but MUST map clearly into these minima for VLAS semantics.

S2.6.2 Stewardship Coefficient $S$and Governance Quality

Stewardship coefficient $S$

(Defined originally in S2.2; here we clarify governance semantics.)

• Meaning: Numeric representation of governance quality and stewardship commitments associated with a credit, including—but not limited to—FPIC, local benefit structures, oversight mechanisms, and contractual enforceability.
• Type: Fraction in $\left[ 0 , 1 \right]$.

Governance semantics:

• $S=1.0$only when:
  • FPIC is valid where required;
  • stewardship obligations and benefit-sharing arrangements are in place and current;
  • governance checks (as declared in the ruleset) are met or exceeded.
• $S<1.0$when:
  • governance or benefit-sharing arrangements are weaker than preferred;
  • FPIC is not required but governance safeguards are partial;
  • there are material concerns that do not justify outright recognition block but require a conservative adjustment.
• $S \rightarrow 0$(or hard block) when:
  • FPIC is revoked or violated in a way that invalidates the basis for issuance;
  • severe governance failures, fraud, or rights violations are present.

Methods and AdapterSpecs MUST define how qualitative governance gradings map into numeric $S$bands (e.g., “Gold”, “Silver”, “Baseline” stewardship tiers).

S2.6.3 Community Carve-Outs and Local Benefit Structures

Community carve-out

• Meaning: A minimum share of benefits, credits, or funding reserved for local communities and rights-holders as part of the program design.
• Type: Policy and structural design; often represented as a fraction of credit flows or financial receipts.

In VLAS:

• Carve-outs are part of program and vehicle design, not just narrative:
  • Some listings may be split into community and investor tranches.
  • Some corporate actions may be programmatically constrained (e.g., minimum RETIRE to community accounts before external transfers).
• Carve-outs can influence:
  • governance evaluations (e.g., contributing to a higher $S$band), and
  • external reporting (e.g., showing share of INAV accruing to local stewards).

Local benefit structures

• Meaning: Mechanisms through which regeneration benefits translate into tangible improvements for local communities (e.g., shared revenues, services, infrastructure rights).
• Representation: Often encoded as program rules and contractual structures; referenced in governance metadata and may affect $S$and public disclosure.

VLAS does not prescribe a single benefit-sharing model but requires:

• explicit documentation;
• ability to trace how much of INAV and flows accrue to local stewards vs external capital;
• coherent integration with stewardship evaluation.

S2.6.4 Exceptions, Escalations, and Governance Overrides

Governance exception

• Meaning: A formally recorded deviation from a default rule (e.g., temporarily accepting a lower data quality tier, or using a fallback pricing mode) under special circumstances.
• Type: Structured record with:
  • exception type,
  • scope,
  • rationale,
  • approving authority,
  • start and end conditions (or review date).

In VLAS:

• Exceptions MAY be used, but MUST be:
  • explicitly recorded;
  • time-bounded or periodically reviewed;
  • visible in relevant artifacts (e.g., CalcProof flags, audit packs).

Escalation path

• Meaning: A defined process for handling suspected integrity breaches, governance failures, or systemic risks (e.g., repeated restatements, method failures).
• Representation: Narrative and workflow; may be captured in BPMN as escalation paths from Gate 1/2/3 to Role.GovernanceCommittee.

Override

• Meaning: A decision by a governance body (e.g., Governance Committee or NAV Committee) to deviate from automated system output (e.g., to halt recognition, suspend pricing updates, or delay INAV signoff).
• Requirement: Any override MUST:
  • be justified in writing;
  • be traceable to a specific role and timestamp;
  • be visible in audit packs;
  • never silently change past numeric outputs without a clear restatement process.

S2.6.5 Conflict of Interest and Separation of Duties (Glossary-Level)

Conflict of interest (COI)

• Meaning: A situation in which a role’s incentives or obligations may materially bias decisions in ways that compromise integrity (e.g., a party benefiting financially from higher INAV serving on the NAV Committee).
• Treatment in VLAS:
  • Certain role combinations are disallowed or restricted (see S1.6 and S1.7).
  • Governance rules MUST define COI policies for Verifiers, NAV Committee members, Registrars, and service providers.

Separation of duties

• Meaning: Design principle where critical steps in the Sensor-to-NAV pipeline are distributed across distinct roles to prevent unilateral manipulation.
• Examples:
  • Role.Steward submitting IndicatorPackages cannot also approve them at Gate 1.
  • The same individual cannot unilaterally control Gate 1, Gate 2, and Gate 3 for the same scope without explicit exceptional governance and documentation.

The glossary itself does not enumerate all prohibited combinations but requires that:

• section-level constraints in S1.6 and S1.7 are reflected in access control, and
• COI and separation-of-duty rules are explicit and auditable.

S2.7 External Framework Terms (Adapter Surfaces) (Informative / Normative Where Stated)

VLAS is designed to align with, and translate into, multiple external frameworks without ceding control of issuance or lifecycle. This subsection defines key external terms as they appear in VLAS, focusing on their role as adapter surfaces.

Key principle:
VLAS governs how credits are created, circulated, and retired.
External frameworks govern how outcomes are reported, planned, or regulated in specific jurisdictions and regimes.
Adapters bridge these worlds.

S2.7.1 BPMN and DMN (Process and Decision Grammars)

BPMN 2.0 (Business Process Model and Notation)

• Meaning: Standard notation for modeling business processes (flows, tasks, gateways, events).
• Role in VLAS:
  • Used to represent Gate workflows, Sensor-to-NAV flow, and operational processes.
  • Critical flows like L2.Flow.VerifierApproval and L5.Flow.CalcProofApproval are modeled as BPMN diagrams.

DMN (Decision Model and Notation)

• Meaning: Standard notation for decision tables and logic.
• Role in VLAS:
  • Used to encode discrete decisions (e.g., mapping stewardship assessments to numeric $S$bands, choosing pricing modes) in a transparent, machine-readable way.

Execution artifacts in BPMN and DMN MUST be consistent with the equations and variable definitions in Section 2. Where there is a discrepancy, the standard’s equations and symbol definitions prevail.

S2.7.2 UCUM (Units), SEEA (Ecosystem Accounting), and ISO 14064-1 (GHG)

UCUM (Unified Code for Units of Measure)

• Meaning: Standard code system for representing units of measure unambiguously.
• Role in VLAS:
  • Every magnitude MUST carry a UCUM unit (or 1 for dimensionless).
  • Adapters MUST declare the UCUM units they accept and produce.

SEEA EA (System of Environmental-Economic Accounting — Ecosystem Accounting)

• Meaning: Framework for measuring ecosystem extent, condition, and services in a way that connects to economic accounts.
• Role in VLAS:
  • VLAS places and classes can be mapped to SEEA EA ecosystem asset and service categories.
  • Adapters MAY export VLAS Integrity and credit flows into SEEA-compatible tables, but SEEA does not govern VLAS issuance.

ISO 14064-1 (GHG Accounting and Verification)

• Meaning: Standard for quantifying and reporting greenhouse gas emissions and removals at the organization or project level.
• Role in VLAS:
  • Methods focusing on GHG outcomes (especially in NCU classes) MAY align their measurement and reporting with ISO 14064-1.
  • VLAS may include ISO-aligned metrics in IndicatorPackages and external reports, but the issuance kernel and credit lifecycle remain governed by VLAS rules.

S2.7.3 CSRD/ESRS, ISSB, TNFD, and Financial Reporting Frameworks

CSRD / ESRS (Corporate Sustainability Reporting Directive / European Sustainability Reporting Standards)

• Meaning: EU regulatory framework and standards for corporate sustainability reporting.
• Role in VLAS:
  • VLAS may provide CSRD/ESRS-aligned disclosure fields (e.g., capital-specific metrics, scenario narratives, risk exposures).
  • Adapters MAY define mappings from VLAS capital metrics and credits into ESRS topical disclosures.

ISSB (International Sustainability Standards Board — IFRS S1/S2)

• Meaning: Global baseline standards for sustainability-related financial disclosures (S1) and climate-related disclosures (S2).
• Role in VLAS:
  • VLAS outputs can serve as underlying data for ISSB-aligned disclosures (e.g., physical and transition risk metrics).
  • VLAS may provide pre-structured data feeds to reporting platforms implementing ISSB standards.

TNFD (Taskforce on Nature-related Financial Disclosures)

• Meaning: Framework for assessing and disclosing nature-related dependencies, impacts, risks, and opportunities.
• Role in VLAS:
  • VLAS capital flows and place-based integrity uplift can be mapped into TNFD’s LEAP (Locate, Evaluate, Assess, Prepare) structure.
  • Adapters may include TNFD-ready dashboards and metrics built from VLAS data.

These frameworks inform how INAV and underlying capital flows are disclosed, but do not alter VLAS issuance or registry logic. Any required adjustments for reporting (e.g., aggregations, scenario stress) MUST be clearly identified as reporting transformations.

S2.7.4 EU CRCF, SEC Climate, and Policy-Driven Alignment

EU Carbon Removal Certification Framework (CRCF)

• Meaning: Emerging EU framework for certifying carbon removal activities and units.
• Role in VLAS:
  • Specific NCU subclasses (e.g., long-lived removals) may be designed to satisfy CRCF technical criteria.
  • VLAS may produce documentation bundles aligned with CRCF requirements (e.g., permanence, monitoring, liability) while maintaining VLAS’s multi-capital scope.

SEC Climate (US Securities and Exchange Commission climate-related disclosure rules)

• Meaning: Regulatory requirements for climate-related risk and emissions disclosures for SEC registrants.
• Role in VLAS:
  • VLAS outputs may support registrants’ climate risk assessments and disclosure of mitigation or adaptation investments.
  • Adapters may map between VLAS integrity uplift and the metrics required in SEC climate-related filings.

Policy-driven frameworks influence how VLAS outputs are interpreted and used in regulatory contexts. VLAS implementations that serve such contexts MUST ensure that:

• mapping and alignment logic is explicit and governed;
• any divergences (e.g., between VLAS integrity metrics and policy-defined metrics) are disclosed and documented;
• no external framework quietly alters VLAS issuance or lifecycle without going through ruleset and governance processes.

S2.7.5 Adapter Surfaces and Variance Flags

Adapter surface

• Meaning: The boundary where VLAS outputs and data structures are transformed or mapped into external framework formats (e.g., CSRD, TNFD, SEEA tables).
• Representation: Usually defined as:
  • data schemas;
  • transformation equations;
  • decision tables indicating how VLAS variables map to external categories.

Variance flag

• Meaning: Marker indicating where a mapping to an external framework involves non-trivial assumptions, approximations, or divergences (e.g., different baselines, scopes, or valuation approaches).
• Type: Enumeration or structured annotation.
• Use:
  • Signals to auditors and regulators where VLAS and external frameworks do not align perfectly.
  • Ensures that such variances are not silently collapsed into a single number.

Adapters SHALL NOT:

• change the meaning of VLAS variables or credits;
• retroactively drive issuance or lifecycle changes;
• hide material differences between frameworks.

They SHALL:

• make mappings explicit and versioned;
• include variance flags where assumptions or choices can materially affect interpretation.

S2.8 Worked Micro-Examples (Informative)

This section provides short, concrete numeric examples to illustrate how the glossary terms and equations work in practice. All numbers are illustrative only; they are not normative requirements or target values.

Each example uses symbols defined in S2.2–S2.5 and shows how they appear in the 8-layer stack.

S2.8.A Router Weights and Spillover Dampeners

Scenario

A restoration program improves watershed health. After method-specific processing, an adapter computes:

• Integrity uplift for the method and window:

$$\Delta I=0.20$$

interpreted as a dimensionless index (unit 1), representing a 20% improvement over baseline.

The AdapterSpec defines the primary routing across capitals:

• ${ \alpha }_{N}=0.70$(Natural capital)
• ${ \alpha }_{M}=0.30$(Manufactured capital, due to improved water infrastructure)
• ${ \alpha }_{H}=0$, ${ \alpha }_{S}=0$, ${ \alpha }_{F}=0$

Check non-inflation constraint:

$${ \alpha }_{N}+{ \alpha }_{M}=0.70+0.30=1.00 \leq 1.$$

Primary allocations (Layer 3 — Capital Router):

$$\begin{matrix} \Delta {I}_{N}^{\text{primary}} & ={ \alpha }_{N} \cdot \Delta I=0.70 \cdot 0.20=0.14 \\ \Delta {I}_{M}^{\text{primary}} & ={ \alpha }_{M} \cdot \Delta I=0.30 \cdot 0.20=0.06 \end{matrix}$$

The AdapterSpec also declares spillover dampeners from Natural to Human and Social:

• ${ \beta }_{N \rightarrow H}=0.25$
• ${ \beta }_{N \rightarrow S}=0.10$

Check spillover constraint for source capital $N$:

$${ \beta }_{N \rightarrow H}+{ \beta }_{N \rightarrow S}=0.25+0.10=0.35 \leq 1.$$

Spillover allocations (still Layer 3):

$$\begin{matrix} \Delta {I}_{H}^{\text{spillover}} & ={ \beta }_{N \rightarrow H} \cdot \Delta {I}_{N}^{\text{primary}}=0.25 \cdot 0.14=0.035, \\ \Delta {I}_{S}^{\text{spillover}} & ={ \beta }_{N \rightarrow S} \cdot \Delta {I}_{N}^{\text{primary}}=0.10 \cdot 0.14=0.014. \end{matrix}$$

Interpretation:

• Natural integrity uplift of 0.14 is primary.
• Manufactured uplift of 0.06 is primary (e.g., more resilient water infrastructure).
• Human uplift 0.035 and Social uplift 0.014 are recognized as spillovers.

No allocation exceeds the original $\Delta I=0.20$once non-inflation constraints are enforced.

S2.8.B Temporal and Quality Coefficients

Scenario

The same watershed program covers ${A}_{\text{cap}}=500$hectares (ha) in the reporting window.

For Natural capital in this window, the Temporal Engine and governance rules derive:

• $v=0.05\;{\text{year}}^{-1}$(5% increase per year over the last 3 years)
• $a=0.01\;{\text{year}}^{-2}$(improvement accelerating modestly)
• $P=0.90$(high permanence due to legal protection and physical stability)
• $S=0.85$(strong but not perfect stewardship and FPIC profile)
• $U=0.15$(moderate uncertainty due to sampling and model assumptions)

All ranges tested:

$$\begin{matrix} v & \in [0,{v}_{max}]\text{(method-specific)}, \\ a & \in [{a}_{min},{a}_{max}]\text{(method-specific)}, \\ P & \in (0,1], \\ S & \in [0,1], \\ U & \in [0,1). \end{matrix}$$

Values are within admissible ranges, so no guard violation is triggered. These coefficients will feed into the issuance kernel.

S2.8.C Issuance Kernel: From ΔI to Q

Scenario

We now compute the issued quantity $Q$for Natural capital in the same example.

Inputs:

• Routed integrity uplift (Natural primary from S2.8.A):
  $\Delta {I}_{N}^{\text{primary}}=0.14$(dimensionless).

• Area factor: ${A}_{\text{cap}}=500\text{ ha}$.

• Coefficients (from S2.8.B):

$$v=0.05\;{\text{year}}^{-1},a=0.01\;{\text{year}}^{-2},P=0.90,S=0.85,U=0.15.$$

• Kernel exponents (declared in the ruleset for this method):

$${ \alpha }_{\text{kern}}=0.5,{ \beta }_{\text{kern}}=0$$ (meaning the kernel uses the square root of velocity, and does not use acceleration directly).

Kernel form (one common class):

$$Q={A}_{\text{cap}} \cdot \Delta {I}_{c} \cdot P \cdot S \cdot {v}^{{ \alpha }_{\text{kern}}} \cdot {a}^{{ \beta }_{\text{kern}}} \cdot (1-U).$$

Plugging in Natural capital values:

$$\begin{matrix} {Q}_{N} & =500 \cdot 0.14 \cdot 0.90 \cdot 0.85 \cdot (0.05{)}^{0.5} \cdot (0.01{)}^{0} \cdot (1-0.15) \\ & =500 \cdot 0.14 \cdot 0.90 \cdot 0.85 \cdot \sqrt{0.05} \cdot 1 \cdot 0.85. \end{matrix}$$

Compute the components stepwise (informative):

• $500 \cdot 0.14=70$
• $70 \cdot 0.90=63$
• $63 \cdot 0.85=53.55$
• $\sqrt{0.05} \approx 0.2236$
• $53.55 \cdot 0.2236 \approx 11.97$
• $11.97 \cdot 0.85 \approx 10.17$

So:

$${Q}_{N} \approx 10.17\text{ NCU units}$$

(in whatever unit the class defines, e.g., NCU.Coastal index units).

Key points:

• The kernel is fully determined by declared parameters and coefficients.
• All parameters and the kernel form must appear in the signed ruleset and CalcProof, so an auditor can recompute ${Q}_{N}$from $\Delta I$and the coefficients.

S2.8.D Corporate Actions and Position Roll-Forward

Scenario

A single lot Lot\_NCU\_Coastal\_2026Q2 is created for Natural capital, listing NCU.Coastal.2026Q2, with:

• Issued quantity from the CalcProof: ${Q}_{N}=10,000$units (for simplicity, using a round number in this example).

The registry applies the following corporate actions over time (same units):

• At ${t}_{1}$(issuance date):
  • ISSUE = +10,000
  • Lot enters CIRCULATING state (assuming no initial hold-back).
• At ${t}_{2}$:
  • TRANSFER\_out from Steward account: 4,000
  • TRANSFER\_``in to Investor A: 4,000
  • (Net circulating quantity for the lot remains 10,000; only holders change.)
• At ${t}_{3}$:
  • Investor A RETIREs 1,500 units to meet a commitment.
• At ${t}_{4}$:
  • Governance BURNs 500 units due to an integrity issue discovered in a portion of the project.

Lot-level circulating quantity at time ${t}_{4}$:

$$\begin{matrix} \text{circ}({t}_{4}) & ={\text{ISSUE}}_{\left[ 0 , {t}_{4} \right]}+{\text{RELEASE\_U}}_{\left[ 0 , {t}_{4} \right]}-{\text{RETIRE}}_{\left[ 0 , {t}_{4} \right]}-{\text{BURN}}_{\left[ 0 , {t}_{4} \right]} \\ & =10,000+0-1,500-500 \\ & =8,000. \end{matrix}$$

Holder-level positions:

• Steward account:
  • Opening balance: 10,000 at ${t}_{1}$.
  • After transfer at ${t}_{2}$: 6,000.
  • No further actions shown: $6,000$at ${t}_{4}$.
• Investor A:
  • Opening balance: 0.
  • After transfer at ${t}_{2}$: +4,000.
  • After RETIRE 1,500 at ${t}_{3}$: closing balance = 2,500 at ${t}_{4}$.

Check that holder balances sum to circulating quantity:

$$6,000(\text{Steward})+2,500(\text{Investor A})=8,500$$

There is a mismatch of 500 units, which must match the BURN action:

• After BURN of 500 units, those 500 are removed from circulation and no longer in any holder’s balance.
• Correct reconciling view (conceptual):
  • Total issued = 10,000
  • Retired = 1,500
  • Burned = 500
  • Circulating = 8,000
  • Holder balances = 6,000 (Steward) + 2,000 (Investor A) if the BURN was taken from a specific holder’s position (e.g., 500 from Investor A).

In a correct implementation, BURN would be applied to a specific holder’s position, and the registry’s corporate actions and positions would reconcile exactly.

This example illustrates:

• the roll-forward equation,
• how corporate actions drive both total circulating quantity and holder positions, and
• why reconciliations are central for audit and INAV.

S2.8.E INAV Slice: Quantities × Admissible Prices

Scenario

At reporting time $t$, Sys.NAVService is computing INAV for the same listing NCU.Coastal.2026Q2, plus a Human capital listing HCU.Health.2026Q2.

From registry and positions:

• NCU.Coastal.2026Q2 circulating quantity:

$${Q}_{\text{NCU.Coastal.2026Q2}}(t)=8,000$$

• HCU.Health.2026Q2 circulating quantity:

$${Q}_{\text{HCU.Health.2026Q2}}(t)=5,000$$

From Sys.PricingEngine (admissible marks as of time $t$):

• $P(\text{NCU.Coastal.2026Q2},t)=12.00\text{ USD/NCU}$
• $P(\text{HCU.Health.2026Q2},t)=8.50\text{ USD/HCU}$

Contribution to INAV from these two listings:

$$\begin{matrix} {INAV}_{\left\{ \text{NCU,HCU} \right\}}(t) & ={Q}_{\text{NCU.Coastal.2026Q2}}(t) \cdot P(\text{NCU.Coastal.2026Q2},t) \\ & +{Q}_{\text{HCU.Health.2026Q2}}(t) \cdot P(\text{HCU.Health.2026Q2},t) \\ & =8,000 \cdot 12.00+5,000 \cdot 8.50 \\ & =96,000+42,500 \\ & =138,500\text{ USD}. \end{matrix}$$

The full system-level INAV(t) would sum these contributions with all other listings and lots:

$$INAV(t)=\sum_{\text{all capital, class, window, lot}} {{Q}_{c,w,\text{lot}}}(t) \cdot {P}_{c,w,\text{lot}}(t).$$

This example shows how:

• circulating quantities derived from corporate actions (Layer 6), and
• admissible prices from Sys.PricingEngine (Layer 7)

are combined in Sys.NAVService (Layer 8) to yield INAV, in a fully re-performable way.

S2.9 Error Classes and Guard Violations (Normative)

This subsection defines the canonical error classes and guard violations that VLAS engines and workflows MUST detect and handle explicitly. These are not optional “best practices”: they are required behavior for any conformant implementation.

Errors are grouped by what they affect:

• Type & unit integrity
• Range & non-inflation constraints
• Configuration and rulesets
• Lifecycle and registry state
• Pricing and INAV
• Governance and signatures

Implementations MAY add more granular sub-codes, but MUST at least map to these canonical classes.

S2.9.1 Type, Unit, and Dimension Errors

E1 – Unitless magnitude where unit required

• Trigger: A numeric value is provided without a UCUM unit, and the schema or AdapterSpec requires a unit.
• Examples:
  • Indicator value 42 with no ucum field.
  • Kernel parameter passed as bare number where a unit is expected.
• Required behavior:
  • IndicatorPackages containing such values MUST fail Gate 1 unless they are corrected.
  • Sys.CalcService MUST reject inputs that do not declare units for required fields.

E2 – Dimension mismatch

• Trigger: A variable is supplied with a UCUM unit that is dimensionally incompatible with the expected unit.
• Examples:
  • Providing mm where kg is expected.
  • Providing t{CO2}e/ha where the adapter expects t{CO2}e/a (tons per year) and no mapping is defined.
• Required behavior:
  • Engines MUST fail fast; no implicit conversions between incompatible dimensions are allowed.
  • Adapters MUST define explicit conversions where alternative, but dimensionally compatible, units are allowed.

E3 – Type mismatch

• Trigger: A field defined as Boolean, enumeration, or integer receives a value of a different type.
• Examples:
  • FPIC\_state contains a numeric code instead of a recognized string label.
  • A window field contains free text instead of an ISO period or governed label.
• Required behavior:
  • IndicatorPackages and CalcProofs MUST be rejected until corrected.
  • Implementations MUST not silently coerce types.

S2.9.2 Range and Non-Inflation Violations

E4 – Range violation (scalar)

• Trigger: A scalar variable falls outside its declared admissible range.
• Examples:
  • $P=1.2$where $\left. P \in (0,1 \right]$.
  • $U=-0.1$where $\left. U \in [0,1 \right)$.
  • $\Delta I<0$where the method declares nonnegative uplift only.
• Required behavior:
  • Sys.CalcService MUST treat this as a hard error and stop the calculation.
  • No CalcProof may be produced until inputs are corrected or the ruleset is updated.

E5 – Non-inflation violation (primary routing)

• Trigger: Sum of primary routing weights exceeds 1:

$$\sum_{c} {{ \alpha }_{c}}>1.$$

• Required behavior:
  • Sys.CalcService MUST fail the calculation and log the violation.
  • Adapters MUST be corrected to obey the constraint; manual overrides are not allowed.

E6 – Non-inflation violation (spillover)

• Trigger: For a given source capital $c$, sum of spillover dampeners exceeds 1:

$$\sum_{{c}^{'}} {{ \beta }_{c \rightarrow {c}^{'}}}>1.$$

• Required behavior:
  • Calculation MUST halt with an explicit error.
  • Adapter configuration MUST be corrected to restore non-inflation.

S2.9.3 Configuration, Ruleset, and Adapter Errors

E7 – Unknown or deprecated ruleset_id

• Trigger: A CalcProof or execution request references a ruleset\_id that:
  • does not exist, or
  • is marked as deprecated or revoked for the relevant period, method, or listing.
• Required behavior:
  • Sys.CalcService MUST reject the request.
  • Gate 2 approvers MUST NOT approve CalcProofs referencing deprecated or unknown rulesets.

E8 – Unknown or mismatched adapter_id

• Trigger: An IndicatorPackage references an adapter\_id that:
  • is not recognized, or
  • is not compatible with the specified method, capital.class, or place type.
• Required behavior:
  • Gate 1 MUST reject the IndicatorPackage until the adapter is corrected or re-linked.
  • No issuance calculations may proceed using invalid adapter references.

E9 – Stale configuration vs. data

• Trigger: Data refers to time windows or conditions not covered by the currently active AdapterSpec or ruleset version (e.g., using an adapter version that expired before the window or not yet active).
• Required behavior:
  • Engines MUST treat this as an error and require explicit governance action (e.g., adapter re-approval or updated version).
  • Silent acceptance of stale configuration is prohibited.

S2.9.4 Registry and Lifecycle Errors

E10 – Negative balance

• Trigger: Applying a corporate action would result in a negative balance for a lot or position.
• Examples:
  • RETIRE more units than the holder owns.
  • BURN more units than remain circulating in the lot.
• Required behavior:
  • Sys.Registry MUST reject the action.
  • If negative balances are observed due to historical errors, a controlled restatement process MUST reconstruct the correct state.

E11 – Orphan corporate action

• Trigger: A corporate action references a lot``\_id that does not exist or is incompatible with the action (e.g., referencing a VOID lot).
• Required behavior:
  • The action MUST be rejected and logged as invalid.
  • If historical orphan actions are discovered, they MUST be quarantined and excluded from state reconstruction.

E12 – Double application or duplication

• Trigger: A corporate action with the same ID or signature is recorded more than once, or an equivalent action is applied twice when only one application is intended.
• Required behavior:
  • Sys.Registry MUST enforce uniqueness of corporate action identifiers or signatures.
  • Detection of duplicates MUST trigger investigation and, if necessary, corrective actions via new compensating actions.

S2.9.5 Pricing and INAV Errors

E13 – Non-admissible price used for INAV

• Trigger: INAV computation uses a price that does not meet admissibility criteria (e.g., not produced by Sys.PricingEngine under L7.Eq.Mark, or outside allowed bands, or from an unapproved venue).
• Required behavior:
  • Sys.NAVService MUST reject the calculation or treat the mark as non-admissible, prompting fallback or governance intervention.
  • MonthlyAuditPack MUST NOT be approved at Gate 3 if non-admissible marks are included as if they were admissible.

E14 – Missing price where required

• Trigger: No admissible price is available for a listing or lot that is expected to appear in INAV for the reporting period.
• Required behavior:
  • Sys.NAVService MUST either:
    • apply a governed fallback (e.g., benchmark-only pricing) as specified in the ruleset, or
    • exclude the position from INAV and flag the omission, per governance policy.
  • In either case, the condition MUST be visible in audit packs.

E15 – INAV equation mismatch

• Trigger: Reported INAV cannot be reconciled to:

$$INAV(t)= \sum {Q}_{c,w,\text{lot}}(t) \cdot {P}_{c,w,\text{lot}}(t).$$

• Required behavior:
  • The pack MUST be rejected at Gate 3 until the discrepancy is resolved.
  • If discovered after approval, a restatement MUST be issued.

S2.9.6 Governance, Signature, and Audit Errors

E16 – Missing required signature

• Trigger: An artifact lacks a required signature (e.g., Gate 1 approval on IndicatorPackage, Gate 2 on CalcProof, Gate 3 on AuditPack).
• Required behavior:
  • The artifact MUST NOT be treated as approved.
  • Downstream processes (issuance, registry updates, INAV) MUST reject its use.

E17 – Signature mismatch or invalid hash

• Trigger: The hash of an artifact does not match the hash that was signed, or the signature fails cryptographic verification.
• Required behavior:
  • Artifact MUST be treated as tampered or corrupted.
  • Affected flows MUST halt or fall back per governance procedures; investigation and, if required, restatement MUST be initiated.

E18 – Incomplete audit trail

• Trigger: Required logs or references (e.g., corporate actions, pricing logs, gate decisions) are missing or insufficient to re-perform a calculation or INAV.
• Required behavior:
  • MonthlyAuditPack MUST NOT pass Gate 3 until the gap is resolved or explicitly labeled as a limitation.
  • Persistent inability to reconstruct the trail is a critical non-conformance.

S2.10 Cross-Reference Keys (Normative)

VLAS uses keys to ensure that equations, artifacts, and external mappings are consistently referencable across documents, code, and registries. This section defines the canonical key formats.

Implementations MAY add additional metadata or indexing schemes, but MUST preserve these minimum key forms.

S2.10.1 Equation and Flow Keys

Equations and flows are referenced using a hierarchical key:

• Equation key:
  VLAS:Equation:L``<layer>.<Name>

Examples:

• VLAS:Equation:L3.PrimaryAllocation
• VLAS:Equation:L4.Kernel
• VLAS:Equation:L8.NAV
• Flow key:
  VLAS:Flow:L``<layer>.<Name>

Examples:

• VLAS:Flow:L2.VerifierApproval
• VLAS:Flow:L5.CalcProofApproval
• VLAS:Flow:L8.NAVCommitteeSignoff

These keys MUST be used consistently in:

• rulesets and code;
• CalcProofs and audit packs;
• documentation and implementation guides.

If implementations add additional equations or flows, they SHOULD follow the same pattern.

S2.10.2 Adapter and Method Keys

Adapters and methods are referenced with:

• Adapter key:
  VLAS:Adapter``:<Domain>/<Name>/<Version>

Example:

• VLAS:Adapter:N``/``MangroveCoastalProtection``/v1.2
• Method key (if methods are formally cataloged separately):
  VLAS:Method``:<Domain>/<Name>/<Version>

Example:

• VLAS:Method:H``/``CommunityHealthBaseline``/v1.0

Rules:

• <Domain> SHOULD be one of {N, H, S, M, F} or a structured domain name (e.g., N.Coastal, H.Health).
• <Version> SHOULD use semantic versioning (e.g., v1.0.3), and MUST align with the adapter\_version or method version recorded in artifacts.

These keys MUST appear:

• in AdapterSpecs themselves;
• in IndicatorPackages (as adapter\_id);
• in CalcProofs;
• in registry metadata where relevant.

S2.10.3 Capital Class, Listing, and Benchmark Keys

Capital class key

• Format:
  VLAS:Class``:<Capital>/<``ClassName``>

Examples:

• VLAS:Class:N``/Coastal
• VLAS:Class:H``/Health
• VLAS:Class:M``/Infrastructure

Listing key

• Format:
  VLAS:Listing``:<Capital>/<``ClassName``>/<Window>

Examples:

• VLAS:Listing:N``/Coastal/2026Q2
• VLAS:Listing:H``/Health/2026Q2

This key MUST be equivalent to the text listing symbol (e.g., NCU.Coastal.2026Q2) used in markets, with a clear mapping defined in implementation.

Benchmark key

• Format:
  VLAS:Benchmark``:<Domain>/<Name>/<Version>

Examples:

• VLAS:Benchmark:N``/``SocialCostOfCarbon``/v1.1
• VLAS:Benchmark:H``/``ValueOfStatisticalLife``/v1.0

Benchmark keys MUST be referenced:

• in pricing configurations and logs;
• wherever L7.Eq.Mark uses specific benchmark curves or tables.

S2.10.4 Artifact Keys (IndicatorPackage, CalcProof, CUT, Audit Pack)

Each primary data object defined in S2.3 MUST have a key that can be used across systems:

• IndicatorPackage key:
  VLAS:IndicatorPackage:<Issuer>/<Program>/<``LocalID``>

Where <``LocalID``> can be a UUID or structured code; <Issuer> and <Program> identify the steward or program context.

• CalcProof key:
  VLAS:CalcProof``:<Issuer>/<Program>/<``LocalID``>

Must be unique for each distinct calculation run that could result in issuance.

• CreditLot (CUTMetadata) key:
  VLAS:Lot``:<Capital>/<``ClassName``>/<Window>/<``LocalID``>

Examples:

• VLAS:Lot:N``/Coastal/2026Q2/0001
• VLAS:Lot:H``/Health/2026Q2/A12B3C
• MonthlyAuditPack key:
  VLAS:AuditPack``:<``VehicleOrTrust``>/<Period>

Examples:

• VLAS:AuditPack:PRT``/2026Q2
• VLAS:AuditPack:PlaceFundX``/2027Y1

These keys MUST appear:

• in registry references,
• in logs,
• and inside the artifacts themselves.

They SHOULD be stable under archival and cross-system replication.

S2.10.5 External Mapping and Crosswalk Keys

For mappings to external frameworks, VLAS uses mapping keys:

• Crosswalk key:
  VLAS:XWalk``:<``ExternalFramework``>/<Scope>/<Version>

Examples:

• VLAS:XWalk:CSRD``/Environment/v1.0
• VLAS:XWalk:TNFD``/Core/v0.4
• VLAS:XWalk:SEEA``/``CoastalEcosystems``/v1.1

Each crosswalk key identifies:

• the external framework and version,
• the scope of mapping (e.g., particular disclosure module, ecosystem class),
• and the exact mapping tables or rules used.

These keys MUST be used:

• wherever adapters export VLAS data into external formats;
• inside audit packs when external-aligned reporting is included;
• in governance documents describing alignment.

S2.11 Minimum Evidence for Audit (Normative)

VLAS is designed so that an independent auditor, regulator, or fiduciary can re-perform the entire chain from raw indicators to INAV. This subsection defines the minimum evidence set that MUST be available for such re-performance.

Evidence requirements are grouped by stage:

• IndicatorPackages and Gate 1
• Issuance calculations and Gate 2
• Registry and lifecycle
• Pricing and marks
• INAV and Gate 3
• Restatements

S2.11.1 IndicatorPackages and Gate 1 (Evidence for Inputs)

For each IndicatorPackage used in issuance during the period under audit, the following MUST be available:

• IndicatorPackage artifact (Data.IndicatorPackage), including:
  • package\_id, place\_id, asset\_ids``[], window;
  • adapter\_id, adapter\_version;
  • indicators with values, UCUM units, timestamps, and QA flags;
  • provenance entries (devices, labs, methods, sampling frames);
  • governance evidence including FPIC status and supporting documents;
  • attachments or references to all external documents in the bundle.
• Hash and signatures:
  • bundle\_hash and the inputs to that hash;
  • steward submission signature(s) over the bundle;
  • Gate 1 Verifier decision (approved/rejected), with:
    • Verifier identity and role,
    • signature over bundle\_hash,
    • timestamp,
    • decision outcome and any machine-readable reason codes.
• Configuration context:
  • the AdapterSpec (adapter\_id, adapter\_version) in force for the period and method, including:
    • indicator definitions,
    • expected units,
    • aggregation weights ${W}_{i}$,
    • routing weights ${ \alpha }_{c}$and spillover dampeners ${ \beta }_{c \rightarrow {c}^{'}}$,
    • mappings from qualitative governance inputs to coefficients such as $S$,
    • declared ranges for key variables.

An auditor MUST be able to:

• verify that indicators match the AdapterSpec’s expectations;
• verify that the right AdapterSpec version was used;
• confirm that only Gate 1–approved packages were used in subsequent calculations.

S2.11.2 Issuance Calculations and Gate 2 (Evidence for Q)

For each issuance event in the period, the following MUST be available:

• CalcProof artifact (Data.CalcProof), including:
  • calc\_proof\_id, ruleset\_id, ruleset\_version, adapter\_id, adapter\_version;
  • references to the IndicatorPackage (bundle\_hash) and any coefficient sources;
  • explicit values for:
    • $\Delta I$by capital slice,
    • ${ \alpha }_{c}$, ${ \beta }_{c \rightarrow {c}^{'}}$,
    • $v,a,P,S,U$per capital.class and window,
    • kernel parameters (e.g., ${ \alpha }_{\text{kern}},{ \beta }_{\text{kern}}$),
    • scale factors ${A}_{\text{cap}}$where applicable;
  • outputs:
    • $Q$by capital.class and window,
    • any held-back quantities and conditions for RELEASE_U;
  • equation references and LaTeX forms (e.g., L3.Eq.PrimaryAllocation, L4.Eq.Kernel);
  • test and guard results (non-inflation checks, range checks, golden tests).
• Hashes and signatures:
  • cryptographic hashes over input references, parameters, and outputs;
  • Sys.CalcService (or equivalent) signature;
  • Gate 2 approver signature with decision, timestamp, and any reason codes.
• Ruleset evidence:
  • the full ruleset (ruleset\_id) in force, including:
    • DSL source for the equations used,
    • DMN tables where decisions influence coefficients or kernel selection,
    • BPMN flows for issuance, including Gate 2 logic.

An auditor MUST be able to:

• re-run the equations $\Delta I \rightarrow Q$using the same ruleset and parameters;
• confirm that non-inflation constraints are enforced;
• confirm that only Gate 2–approved CalcProofs underpin ISSUE actions.

S2.11.3 Registry and Lifecycle (Evidence for Quantities)

For each listing and lot relevant to the period, the following MUST be available:

• CreditLot metadata (Data.CUTMetadata) for each lot\_id:
  • capital\_class, window, listing\_symbol;
  • quantity\_issued;
  • ruleset\_id, adapter\_id, calc\_proof\_id;
  • provenance fields (place\_id, asset\_ids``[], method family, program tags);
  • lifecycle status (ISSUED, CIRCULATING, RETIRED, BURNED, VOID).
• Corporate actions (Data.CorporateAction):
  • complete list of actions for each lot\_id from inception to the end of the audit period;
  • corporate\_action\_id, lot\_id, action\_type, quantity\_change, timestamp, initiator, authorization\_reference;
  • if BURN or RETIRE, clear indication of cause (e.g., commitment, reversal, fraud).
• Position evidence:
  • per-holder Positions for relevant dates in the period:
    • opening and closing balances,
    • aggregated flows (ISSUE, RELEASE_U, TRANSFER_in/out, RETIRE, BURN),
    • holder identifiers and account types.

An auditor MUST be able to:

• reconstruct circulating quantities ${Q}_{c,w,\text{lot}}(t)$from ISSUE, RELEASE_U, RETIRE, and BURN;
• reconcile holder-level Positions with the lot-level quantities;
• detect any inconsistencies (e.g., negative balances, orphan actions).

S2.11.4 Pricing and Marks (Evidence for P)

For each listing (and lot, where applicable) that appears in INAV during the period, the following MUST be available:

• Raw pricing data:
  • trade records (prices, volumes, timestamps, venues) for the period;
  • benchmark curve data used (e.g., tables, formulas, parameter sets).
• Pricing engine logs from Sys.PricingEngine:
  • computed VWAPs or other aggregates;
  • benchmark values at relevant windows;
  • quality flags and liquidity indicators;
  • haircuts or adjustments applied;
  • final admissible marks ${P}_{c,w}(t)$(and lot-level marks, if used);
  • any fallbacks (e.g., benchmark-only modes) and triggers for these modes.
• Configuration:
  • the L7.Eq.Mark equation definition as used;
  • configuration for venue sets, benchmark sets, price bands, and fallback rules.

An auditor MUST be able to:

• reconstruct or verify admissible marks for each listing/lot;
• determine whether any marks used in INAV were out of band or non-admissible;
• see when and why any fallback or exceptional pricing modes were used.

S2.11.5 INAV and Gate 3 (Evidence for Portfolio-Level Values)

For each reporting period and NAVSnapshot, the following MUST be available:

• NAVSnapshot (Data.NAVSnapshot):
  • snapshot\_id, timestamp, period;
  • total INAV(t);
  • decompositions by capital, class, window (and lot, where required);
  • references to positions and marks used.
• MonthlyAuditPack (or equivalent):
  • the NAVSnapshots in scope;
  • registry extracts and reconciliations with positions;
  • pricing logs or hashed references;
  • summary of restatements, overrides, and exceptions;
  • crosswalk outputs (where VLAS feeds external frameworks).
• Gate 3 evidence:
  • NAV Committee decision (approved/rejected), with signatures, timestamp, and any conditions;
  • evidence of addressing prior period issues where relevant.

An auditor MUST be able to:

• recompute INAV(t) by applying the canonical equation to the provided quantities and marks;
• check that reconciliations match;
• confirm that only Gate 3–approved packs were used for official reporting.

S2.11.6 Restatements and Corrective Actions

When errors or new information require changing previously reported values, the following MUST be available:

• Restatement rationale:
  • what changed (data, ruleset, pricing, or governance finding);
  • why the original value was incorrect or incomplete;
  • scope of impact (which periods, which listings, which holders).
• Restatement actions:
  • new corporate actions (e.g., BURN, compensating ISSUE) that implement the correction;
  • revised CalcProofs if necessary;
  • updated NAVSnapshots and AuditPacks with explicit restatement labels.
• Audit trail:
  • original artifacts preserved and clearly marked as superseded;
  • clear temporal ordering of old and new values.

Restatements MUST NOT be implemented by silently editing past artifacts or logs. All changes MUST be expressed as new, additive evidence and actions.

S2.12 Quick Index: Terms, Symbols, Types, and Ranges (Normative Index)

This subsection provides a compact index of the key symbols and terms defined in Section 2. It is binding where it restates types, units, and ranges; descriptive notes remain informative.

Note: This index is not exhaustive of every narrative term, but it covers all symbols and primary variables used in equations and artifacts.