KISMET
KISMET — Kernel Interoperability, Shared Methods & Execution Trust
Depends on module:
1. Purpose, scope and status
KISMET is ZAYAZ's framework for the specification, registration, composition, execution and verification of all reusable executable kernels. It governs atomic and composite capabilities across calculation, validation, transformation, logic, analysis, simulation and authorized policy evaluation.
A KISMET kernel is an independently registered reusable executable capability, exposed through a versioned KISMET contract and executed within policy authorized by the caller or governing context. It may be implemented by a function, library, algorithm package, MICE micro-engine, read-only service, or governed composition of these and child kernels. A kernel is not restricted to micro-engines. Data, models and rules may be dependencies, but are not executable kernels by themselves.
KISMET governs capability identity, invocation, composition and trust; it does not introduce a second executable component model or scheduler. MICE remains authoritative for MICE implementations. Other implementation forms require an approved platform execution binding with equivalent authorization, isolation, evidence and lifecycle guarantees. An adapter can expose a library under the common contract without pretending that every internal function is a micro-engine.
This is a proposed master specification, version 0.2.1. SHALL, SHOULD and MAY express requirements upon adoption; they do not assert that corresponding infrastructure already exists. The K4 direction and revised kernel/controller boundaries reflect the design decisions accompanying this draft. Detailed lifecycle, schema and conformance provisions are proposed here for adoption.
The document ID KISMET is registered through this document's frontmatter in the generated document-ID registry. Named existing systems are architectural integration targets; their complete specifications and implementations have not been independently verified here. The first domain integration is the Scope 3 engine family (S3-ARCH v0.5.0).
1.1. In scope
- Public kernel contracts and their implementation bindings.
- Atomic and composite execution, dependency resolution and controlled selection.
- Input/output semantics, failures, effects, provenance and replay.
- Compatibility, release lifecycle, ownership and conformance.
- Reuse across domains without duplicating executable logic or importing unintended domain authority.
1.2. Outside KISMET's authority
KISMET does not establish scientific or regulatory method validity, decide business applicability, classify reporting categories, administer reference data, replace platform routing, or provide an independent audit store. It defines how executions respect those authorities and retain evidence of their decisions.
Not every executable component is a kernel. Connectors, application workflows and controllers remain their own component classes unless they separately expose a reusable capability under a KISMET contract. Internal helper functions need not become registered kernels.
2. Architectural concepts
| Concept | Definition |
|---|---|
| Method | An authoritative procedure defining how an outcome is obtained, including assumptions and applicability constraints. |
| Kernel | A coherent reusable executable capability with a governed contract and accountable owner. |
| Method variant | A declared alternative procedure within a capability, selected under authorized policy. |
| MICE micro-engine | An identified executable component governed by the MICE execution model. |
| Atomic kernel | A kernel with no separately governed child-kernel invocations; it may contain internal functions and declared non-kernel dependencies. |
| Composite kernel | A kernel whose implementation invokes independently governed executable capabilities and combines their outputs under a versioned composition. |
| Composition | The declared dependency graph, mappings, branch rules, combination semantics and failure behavior of a composite. |
| Kernel family | A discovery grouping of related kernels; membership alone creates no executable endpoint. |
| Execution configuration | An immutable record of resolved contracts, builds, composition, dependencies, policies and data bindings. |
| Execution | One invocation with identified inputs, context, resolved configuration, outcomes and evidence. |
Atomic/composite describes implementation structure; it is independent of domain and MICE type. An engine may implement a kernel, consume kernels, or do both. A composite transport calculation does not become a category controller merely because it coordinates child computations.
One method may have multiple governed implementations. A kernel may be used by multiple governed method references through independently versioned bindings. Each execution SHALL identify the exact methods and implementations used. Scientific meaning, interface compatibility and executable build identity SHALL remain distinguishable.
2.1. Admission test: capability versus implementation
Registration as a kernel SHALL require all of the following:
- A reusable capability boundary, with explicit semantics and consumers independent of its implementation internals.
- A versioned invocation/result contract, declared methods and caller-authorized selection policy.
- An accountable owner, approved implementation binding and inspectable dependency closure.
- Evidence, replay and conformance obligations appropriate to the capability.
- Compliance with the no-business-side-effects boundary.
Being callable, useful or already classified as a MICE engine is insufficient. Internal helpers remain implementation details unless independently registered for reuse. A MICE engine does not automatically receive a second identity; a KISMET kernel identity is assigned to the capability only when this admission test is met. Kernels may have several approved implementations, while one engine may implement several explicitly separated capabilities.
2.2. Canonical identities and the five-contract model
The sole proposed canonical grammar is KISMET-<KIND>-<OWNER>-<NAME>, with KIND in KERNEL, BINDING, RESOLVER, POLICY, COMPOSITION. Versions are independent semver fields and do not appear in an identity. Kernel aliases such as K4 are not alternate canonical identifiers. Namespace registration and the KXID execution identity require constitutional approval before operational use. There is no parallel sequential kernel-identifier series.
| Contract | Ownership | Boundary |
|---|---|---|
| KEC | Reusable atomic or composite capability; types, numerical guards and implementation contract | No business interpretation or applicability decision |
| KBC | Input mappings, resolved parameter/guard selection, resolver slots and requested policy slot | No thresholds, direction or severity |
| KRC | Reproducible data selection, technical eligibility, complete fallback chain and atomic cohort snapshot | Does not decide evidence admissibility |
| KPC | Typed verdict, interpretation and evidence admissibility | No notifications, blocking, assignments or other workflow actions |
| KCC | Composite dependency graph, typed edges, compatible version ranges and error semantics | No runtime mutation of resolved dependencies |
One executable kernel may support many domain bindings and policies. One binding may be interpreted by multiple applicable policies without duplication. The exact versions and resolved values used by an execution are pinned immutably in its execution manifest.
Authority: The normative KISMET Contract Specification owns the artifact grammar, identity grammar, requirements and schema definitions. This framework owns architectural responsibility boundaries and examples; in case of conflict the normative contract specification prevails on contract semantics. Unregistered governance references remain proposals, not operational authorisations.
3. Governing principles
KIS-001 — Coherent capability
A kernel SHALL expose a coherent reusable capability through a versioned contract. It MAY implement multiple declared methods and compose approved executable implementations or child kernels. Its boundary SHALL be understandable independently of its internal implementation.
KIS-002 — Authorized execution
Method selection, branching and fallback SHALL follow a versioned policy authorized by the caller or governing context. Kernels SHALL NOT redefine domain applicability, reporting boundaries or permitted methods. Selection SHALL NOT depend on obtaining a preferred numerical result.
KIS-003 — Explicit dependencies
Executable, policy, dataset, model and connector dependencies that can affect an outcome SHALL be declared and resolved to identifiable versions or captured execution evidence. Runtime use of an unrecorded moving “latest” dependency is non-conformant.
KIS-004 — Preserved identity
Composition SHALL preserve child identities, versions, evidence and accountability. Parent identity SHALL NOT conceal which children produced a result. Existing canonical identity mechanisms SHALL be reused rather than duplicated.
KIS-005 — Trust through evidence
Every result SHALL link to the inputs, authorized selection, resolved dependencies and execution evidence necessary to assess its declared guarantees. A composite SHALL be assessed as a composition; approved children alone do not prove correct combination.
KIS-006 — Explicit completeness and effects
Missing, failed, excluded and zero-valued results SHALL remain distinguishable. Version 0.2 kernels SHALL NOT mutate business state or initiate external business actions. Pure computation is the default; governed read-only resolution is permitted under section 7.4.
KIS-007 — Domain profiles
The common contract SHALL remain domain-neutral. Domain profiles MAY add units, evidence requirements, restrictions and stronger guarantees; they SHALL NOT weaken mandatory KISMET requirements. Scope 3's tCO2e output is a profile requirement, not a universal kernel output type.
4. Authority and governance boundaries
| Authority | Accountable for |
|---|---|
| KISMET framework owner | Common contracts, composition rules, compatibility policy and conformance criteria. |
| Method authority | Method meaning, assumptions, allowed variants and scientific/domain approval. |
| Domain controller or caller | Business applicability, authorized capabilities and policies, reporting boundaries and domain exclusions. |
| Kernel owner | Contract correctness, implementation behavior, release evidence and operational support. |
| Composite owner | Dependency integration, mappings, branch behavior, combination semantics, failure propagation and end-to-end conformance. |
| MICE execution infrastructure | Component lifecycle and execution enforcement through existing platform mechanisms. |
| ZSSR | Destination resolution and dispatch; a composition supplies logical requirements, not a competing routing authority. |
| Reference-data and policy owners | Authoritative factors, datasets, parameters and rules with appropriate administration and versioning. |
| Existing identity, lineage and evidence systems | Canonical registration, traceable records, access control and retention. |
KISMET contracts SHALL bind to existing method and component registries, including the compute-method registry and MEID/CMI mechanisms where applicable. ZAR-governed schema and data references and existing lineage/evidence mechanisms SHALL be reused. Any required registry extensions must be specified and registered; this document does not create new authoritative stores by naming them.
Conflicting authority or unresolved policy SHALL yield an explicit rejection or review outcome. A kernel SHALL NOT invent a resolution that expands its permissions.
4.1. Constitutional standing and vocabulary
KISMET is subordinate to applicable platform constitutions and to MICE-EX for MICE execution semantics. It proposes delegated authority over kernel capability contracts and composition; it does not claim constitutional standing merely by stating invariants. The framework owner SHALL register this relationship in the Constitution Manifest through the established governance process before platform-wide adoption.
The Constitutional Lexicon SHALL define executable kernel, composition, execution configuration and kernel identity. “Executable kernel” in KISMET SHALL be distinguished from “Object Kernel” in TrustGate material; no shared meaning or identity is implied. The exact manifest and lexicon bindings require verification against their authoritative specifications.
4.2. TrustGate and ZRR boundary
Validation and policy-evaluation capabilities remain in scope. A validation kernel may execute a schema or constraint check; it cannot confer TrustGate acceptance. A policy-evaluation kernel may evaluate an authorized ruleset; it cannot replace Policy Resolution or become an alternative ruleset authority.
TrustGate stages may invoke kernels under their own contracts. Invoking the same kernel elsewhere SHALL NOT bypass the canonical pipeline, reorder its stages or manufacture an authoritative TrustGate decision. ZRR remains authoritative for rulesets it governs. Caller authorization means authority legitimately delegated by the platform, not arbitrary caller preferences.
4.3. Method approval and the ZARM dependency
ZARM is a proposed method-authority integration target based on review feedback; its substantive specification and operational approval mechanism have not been verified. An empty document, unresolved reference or future registry entry SHALL NOT count as approval.
Until the permanent mechanism exists, a production method SHALL either reference a registered interim approval record authorized by the applicable governance owner, or remain blocked from production approval. That record SHALL identify method/version, approver and delegated authority, applicability, evidence, validity and supersession. Development validation does not confer production approval. Migration to ZARM SHALL preserve existing approval lineage.
5. Kernel declaration and contract
Every kernel SHALL publish the following information through canonical registration mechanisms. Field names below are conceptual requirements, not a newly registered wire schema.
| Declaration area | Required content |
|---|---|
| Identity and ownership | Canonical kernel/component references, accountable owner, lifecycle status and support responsibility. |
| Capability | Purpose, supported operations, methods, variants, assumptions and exclusions. |
| Contract | Input, output and options schemas; units and semantic bases; preconditions and postconditions. |
| Implementation | MICE/component binding or other approved executable binding, release and build proof. |
| Composition | Atomic/composite designation; composition specification and dependency constraints where applicable. |
| Policy | Authorized selection, parameter resolution, branching and fallback rules. |
| Execution behavior | Pure computation or governed read-only resolution; permissions, captured observations and retry provisions. Business side effects are prohibited in v0.2. |
| Evidence and replay | Required provenance, replay profile, retention references and environment constraints. |
| Compatibility | Version policy, supported domain profiles and migration/deprecation provisions. |
| Conformance | Method approval references where required, verification evidence and release approval. |
Inputs SHALL distinguish activity data from policy and reference data. Caller-supplied values SHALL NOT override administered parameters merely by appearing in an options object. Domain profiles SHALL identify the governing authority and permitted override bounds.
Contracts SHALL state whether state, time, randomness, external services or mutable data affect outputs. Relevant state and observations SHALL be captured or immutably referenced where replay requires them.
5.1. Proposed authoritative homes and registration work
The following are proposed bindings, not claims of completed registration. The KISMET owner SHALL publish one verified binding manifest before implementations are approved. Authors SHALL NOT substitute local conventions for unresolved entries.
| Concept | Proposed home and representation | Owner / required binding |
|---|---|---|
| Kernel declaration | Authoritative ZAR-governed capability registration; owning kernel specification supplies the human-readable contract. A MICE engine's mice metadata references its KSMT bindings; it is not a competing declaration store. | KISMET owns declaration schema; kernel owner owns each declaration. Exact ZAR family/path and metadata extension remain registration tasks. |
| Composition release | Immutable version of the registered composite declaration, including graph, mappings and dependency constraints. | Composite specification; release reference and schema registered in the binding manifest. |
| Execution configuration | Persistent immutable artifact containing resolved dependency lock, build references and policy/data bindings. Dependency lock is embedded, not a mandatory separate artifact. | KISMET owns proposed ARTIF-KISMET-EXECUTION-CONFIGURATION; runtime ID type and CSI binding require registration. |
| Transport policy | Versioned governed policy/dataset referenced by configuration; reuse the canonical policy representation when verified. | Transport Kernel specification; policy administration remains with the authorized policy owner. |
| Execution evidence | Persistent batch-capable artifact referenced through canonical execution_ref; uses component CMI and build_hash proof where applicable. | KISMET owns proposed ARTIF-KISMET-EXECUTION-EVIDENCE; reuse an existing equivalent artifact if verified. Runtime ID and CSI binding require registration. |
| Invocation and result | Registered CSI payload contracts; persist results/evidence through the verified artifact model rather than inventing a new store. | KISMET common envelope; domain/kernel specification owns payload extension. |
| Lineage | Existing USO-tail convention references execution evidence and component identities; detailed manifests remain outside the tail. | Existing lineage authority; KISMET defines required links, not an alternative lineage system. |
For each new artifact, the binding manifest SHALL contain its ARTIF type, runtime identifier type, input/output CSI contract as applicable, producer, owning specification, schema address/version, retention and access policy. Proposed ARTIF names above are registration requests only. Exact existing CMI, USO, execution_ref and build_hash schemas must be inspected before wire bindings are finalized. Non-MICE builds require approved equivalent build proof, not fabricated MEIDs.
6. Common invocation and result envelope
6.1. Invocation
An invocation SHALL identify the requested kernel contract and operation, input payload or immutable input references, execution context, authorization/policy references, and correlation identity. It SHALL include a stable request identity for correlation and retry deduplication; this is distinct from execution identity and input content identity.
Execution context includes only the domain, entity, time and authorization information necessary for the capability. Domain tags retained for provenance SHALL NOT become hidden branch inputs. Any context that affects computation SHALL be an explicit contract input or policy binding.
Before execution, the platform SHALL resolve an immutable execution configuration or reject unresolved requirements. Authoring-time version ranges are permitted; executed versions SHALL be exact and recorded.
6.2. Result
A result SHALL contain:
- Execution identity, kernel contract and resolved configuration references.
- Typed output and its units/semantic basis where applicable.
- Outcome status, completeness and unresolved input/component information.
- Methods and branches used, with selection and fallback reasons.
- Root and child execution references, including transformations and allocations.
- Applicable uncertainty, quality indicators and replay declaration.
- Structured failures/warnings and evidence references.
KISMET SHALL NOT introduce COMPLETE / PARTIAL / REJECTED / FAILED as an independent status vocabulary. Execution status uses the canonical platform execution vocabulary; result coverage is expressed separately as counts and unresolved item references; domain disposition remains the caller's authority. Partial output is permitted only by an explicit contract. A successful invocation does not establish domain eligibility for reporting. Section 6.4 defines the required binding and mapping work.
6.3. Errors
Errors SHALL identify the failing component, stage, affected input or child reference, error class, retryability and affected evidence/result references. Typical classes include invalid input, unauthorized method, incompatible basis, unavailable dependency, incomplete data and execution failure. Domain profiles may define specific codes through canonical schema governance.
6.4. Status and domain mapping
One canonical execution vocabulary SHALL be used, with an approved mapping for each execution binding. KISMET adds no parallel enum. Completeness is a separate structural measure and domain disposition is a separate reference.
| Situation | Execution meaning | Completeness / domain treatment |
|---|---|---|
| All requested items computed | Canonical successful-execution status | All items accounted for; reporting eligibility remains a domain decision. |
| Policy permits some uncomputed items | Canonical status for the completed execution, as approved in the mapping | Missing items and reasons explicit; never claim full coverage. |
| Invocation denied before calculation | Canonical admission-denied/rejection code, exact value to be bound | No calculation result; does not manufacture a TrustGate rejection. |
| Runtime failure | Canonical execution-failure code | Identify affected items and any usable outputs permitted by contract. |
| Scope 3 UNCOMPUTED | No automatic mapping to technical failure | Domain disposition assigned by the Scope 3 controller with missing-data evidence. |
| TrustGate HOLD or other decision | Retain its canonical decision reference | Kernel cannot issue or override that decision. |
The mapping manifest SHALL specify exact registered codes, schema versions and transition semantics before production use. Descriptive phrases in this table are not wire values.
6.5. Draft envelope field contract
This is a concrete field-level design for the first wire-schema deliverable. It is not a registered or executable JSON Schema. Canonical reference, status and context definitions remain binding dependencies; production adoption is blocked until they are resolved and the schema package is published.
| Invocation field | Shape and constraint |
|---|---|
schema_ref | Required canonical schema/version reference. |
request_ref | Required stable request reference; reused for retries of the same request. |
kernel_ref | Required registered KISMET kernel identity plus exact public contract version. |
operation | Required declared operation name. |
authorization_ref | Required reference to effective authorization. |
policy_refs | Required list of versioned policies; may be empty only for a contract requiring none. |
context_ref | Required authorized execution-context reference. |
items or input_manifest_ref | Exactly one: nonempty array of uniquely identified items, or immutable batch manifest. Each item has item_ref and exactly one inline input or immutable input reference. |
requested_configuration_ref | Optional exact configuration pin; otherwise resolved before execution. |
| Result field | Shape and constraint |
|---|---|
schema_ref, request_ref, kernel_ref | Required registered result schema and matching request/capability references. |
execution_ref, configuration_ref | Required execution and effective immutable configuration references for admitted executions. |
execution_status | Required canonical vocabulary reference and registered code; no KISMET enum. |
coverage | Required requested, computed and unresolved item counts plus attribution manifest; counts reconcile against the requested item set. Missing items never count as zero-valued computed items. |
results or result_manifest_ref | Exactly one; possibly empty for failure. Each contribution has item reference, typed output and evidence selector. |
evidence_ref | Required batch/root evidence artifact reference. |
errors | Required array, possibly empty, using registered error definitions with item/node selectors. |
domain_disposition_ref | Optional caller-owned disposition; never synthesized as platform authority by the kernel. |
Pre-admission errors use the canonical platform error envelope and request reference; they SHALL NOT fabricate an execution configuration or claim a calculation occurred. Counts express structural coverage, not emissions magnitude or business materiality. Exclusions require a traceable caller-authorized input scope or domain disposition.
The first schema package SHALL include invocation, result, configuration, batch-evidence and canonical-status bindings plus valid/invalid examples for single, batch, composite, partial and denied requests. It SHALL be validated before controller integrations are built against it.
7. Composite execution
7.1. Composition declaration
A composite SHALL declare child capabilities, data mappings, execution dependencies, branch predicates, allowed variants, combination rules and failure behavior. The realized execution graph SHALL be recorded.
Graphs SHOULD be acyclic. Iteration or recursive behavior requires an explicit contract with termination conditions, resource limits and recorded iteration state. Hidden recursive calls are non-conformant.
A composition MAY be data-dependent—for example, one node per transport leg—provided the expansion rules are versioned and the realized nodes are individually identifiable.
7.2. Selection and fallback
Internal method selection is permitted within the authorized capability policy. A composite SHALL reject or return control when a required fallback exceeds that policy. Every fallback SHALL record its trigger, authorization and resulting method.
Choosing a road engine for a road leg is execution planning. Choosing whether a shipment belongs in Scope 3 category 4 is a domain decision. The two SHALL remain separate.
7.3. Combination and compatibility
Before combining outputs, a composite SHALL verify compatible units, time/entity scope and domain-specific bases. Any normalization or conversion SHALL be governed and traceable. Parent totals and their children SHALL not be counted twice.
Uncertainty propagation SHALL specify assumptions, including relevant correlations and shared factors. A composite SHALL NOT infer a stronger quality or replay guarantee merely because it aggregates results. It SHALL distinguish input uncertainty, methodological uncertainty and execution reproducibility.
Unknown correlation SHALL NOT default silently to independence. Shared factor draws SHALL be represented as shared uncertainty sources. A registered uncertainty policy SHALL state the propagation algorithm and correlation assumptions; where dependence is unknown, use an approved conservative treatment or report that combined uncertainty is unavailable. A shared source need not imply correlation of +1 between all final outputs: sensitivity and other uncertainty sources still matter.
7.4. Failures, retries and effects
The composition SHALL define whether child failure fails the whole execution or permits an explicit partial result. Missing output SHALL NOT default to zero unless a domain contract explicitly establishes that semantic meaning.
Kernels SHALL NOT write ledger entries, update business records, send messages, make purchases or initiate other external business actions. Those operations belong to separately authorized controllers, connectors or control-plane components outside the kernel calculation graph. Compensation mechanisms are therefore outside the v0.2 kernel contract.
Read-only reference resolution, including EFDER lookup, is permitted through declared platform dependencies. Effective values and their versions SHALL be captured or immutably referenced. Live external acquisition, such as flight or route lookup, SHALL be performed through a governed connector dependency at the acquisition boundary; the calculation consumes the captured observation rather than hiding an uncontrolled network call inside a formula.
Platform-managed evidence persistence, operational telemetry and semantically transparent caching are not business effects. They SHALL NOT change calculation semantics or bypass access control. Retries SHALL preserve request correlation, record attempts and avoid duplicating published result contributions. Replay SHALL use the recorded observation rather than silently refetching current data.
7.5. Dependency upgrades
A child release SHALL NOT silently replace the version in a released execution configuration. An upgrade SHALL produce a new immutable composition release or dependency-lock revision, with impact assessment and appropriate conformance evidence. A contract version may remain unchanged when compatible, but the changed execution configuration must be distinguishable.
7.6. Composition compatibility and execution closure
A KCC declares compatible dependency ranges, not exact pinned child versions. Before execution, the authorised runtime resolves the transitive graph to exact artifact and implementation versions and preserves that closure (or a content-addressed closure reference). Mid-execution substitution is prohibited except through an explicitly authorised, predeclared substitution rule captured in the execution evidence.
8. Evidence and replay
Every execution SHALL retain or immutably reference its effective inputs, contracts, builds, policies, data versions and result. Composites add realized graph structure, child references, mappings and combination evidence. Content hashes support integrity but do not substitute for retaining accessible replay inputs.
The replay profiles are those of the Replay Constitution (REPLAY-CONSTITUTION) and TG-RP; KISMET adds no profile. The following obligations apply to kernels under each profile:
| Profile | Required claim |
|---|---|
| EXACT | The defined observable outputs reproduce under the recorded inputs, dependencies and required execution environment. The contract defines equality/canonicalization. |
| BANDED | Outputs reproduce within a declared comparison rule and tolerance. The tolerance originates from governed replay policy and is referenced, not defined, by the kernel contract (Replay Constitution §6, §8). |
| RECORDED | The original observation or decision is retained; recomputation equivalence is not promised. |
Every kernel declares exactly one replay profile (Replay Constitution §5, CR-100). For a composite, the declared profile belongs to the released composition and SHALL be no stronger than the weakest profile among the dependencies that composition may invoke; each execution additionally records the profile actually realized by its graph. A composite's end-to-end claim SHALL be justified from its children, mappings and combination operations. It cannot claim EXACT recomputation of a live external response solely because the original response was recorded. Replaying from a recorded response and reproducing the external service's behavior are distinct claims.
Randomized algorithms MAY support EXACT replay when the generator and version, seed or stream state, sample count, parameters, ordering and relevant numerical environment are fixed. Parallel random streams and reduction order SHALL be controlled where they affect exactness. A statistical confidence interval is not a replay tolerance.
Replay uses recorded versions. Recalculation with revised factors, policies or engines creates a new execution linked to the original and SHALL NOT overwrite the original evidence.
Evidence access SHALL respect entity/tenant boundaries and data permissions. Retention requirements and the consequences of expired source access SHALL be declared; indefinite replay SHALL NOT be promised without retained dependencies.
8.1. Batch evidence and granularity
Logical execution attribution is not a requirement to persist one heavyweight artifact per item, leg or child. Kernels SHALL support a batch evidence representation where the workload benefits from it. One batch root may reference partitioned manifests and result tables; storage cardinality is an implementation choice subject to the following traceability requirements.
- Share immutable configuration, dependency closure, common factors/policies and graph templates once per applicable group.
- Attribute each output to its input item, leg or allocation through stable selectors within those manifests.
- Record per-item branches, fallback reasons and exceptional dependency bindings where they differ; homogeneous items may share an explicit mapping rule.
- Record retries, missing items and failures without overwriting prior attempts or counting repeated contributions twice.
- Preserve independently executed child references where they exist; use node/item selectors for batched internal work instead of fabricating separate execution artifacts.
- Permit extraction of an item's audit evidence with its required shared context and access controls intact.
Aggregation, deduplication or compression SHALL be lossless with respect to required attribution. Sampling traces is not a substitute for evidence supporting every reported result. Partitioning SHALL respect tenant/entity permissions. Batch configuration must not leak unrelated parties' inputs when evidence is exported.
8.2. Custody of immutable evidence
ZAR retains the canonical lineage, identities and parent/child execution relationship; ALTD retains immutable integrity evidence and anchoring receipts. KISMET adds no independent audit database. Its manifest SHALL carry exact implementation build hashes, immutable input/output payload references and hashes, resolved guards, resolver snapshots, governing policy and exact dependency closure. The manifest includes anchoring state, distinguishing pending/failed anchoring from proof of anchoring. A hash without a retained and accessible payload is insufficient for replay.
Statistical reproducibility within a declared tolerance is required for stochastic kernels; seed, RNG implementation/version, iteration count, distribution-specification evidence and numerical environment are recorded. Bitwise reproduction is not promised across differing hardware or libraries. Evidence references and ALTD state must be verified under the existing constitutional mechanisms before claims of end-to-end auditability.
9. Lifecycle and change governance
Recommended lifecycle states are draft, validated, approved, deprecated and withdrawn, mapped to existing canonical lifecycle values during integration. Approval SHALL identify the approving authority, scope and evidence. Implementation conformance does not replace method-authority approval.
| Change | Required treatment |
|---|---|
| Public schema or semantic change | Compatibility assessment, contract version change where required, consumer migration guidance. |
| Executable change | New immutable release/build identity and relevant verification. |
| Composition or child-version change | New composition/configuration identity and integration assessment. |
| Method-definition change | Method-authority review and binding/version updates. |
| Factor or parameter update | New governed data/policy version, distinguishable execution configuration and impact/restatement assessment. |
| Withdrawal | Block new unauthorized executions while preserving historical records and permitted replay. |
Compatibility is semantic as well as structural. Adding a default, changing rounding or altering method precedence can change outcomes even when schemas still validate. Releases SHALL document such changes.
10. Controller relationship
Controllers own domain applicability, capability authorization, boundary rules, exclusions and accountable assembly of domain results. They SHALL delegate substantive domain formulas, numerical allocation, uncertainty propagation and calculated quality scores to governed executable capabilities.
Controllers MAY perform bookkeeping required to coordinate execution. They SHALL NOT duplicate kernel formulas or create ungoverned alternate computation paths. Allocation policy belongs to the domain controller; calculation of that allocation belongs to the selected executable capability.
Internal method allocation is different from reporting allocation. For transport, allocating aircraft emissions to a passenger or cargo consignment is part of the transport method; allocating a journey result to a reporting entity/category is a separately authorized domain operation. Contracts SHALL identify each allocation stage and prevent double application.
11. Transport Kernel — Reference composite (Scope 3 alias K4)
11.1. Capability and components
The Transport Kernel has a stable KISMET kernel identifier to be allocated during registration. K4 is its Scope 3 alias, not its canonical platform identity. It provides all-mode transport calculation through a journey contract. Its mode-specific MICE dependencies cover air, road, rail, sea and inland waterways. ATME retains its identity and independent release lifecycle as the air engine.
Create separate engines for materially distinct models and governance lifecycles, rather than automatically creating an engine per vehicle subtype. Vehicle/fuel/vessel profiles can remain governed data where the same procedure applies.
K4 may be reused across freight, travel, commuting and scenario analysis. It does not decide a journey's Scope 3 category, reporting inclusion or business ownership.
The Transport Kernel SHALL have a named accountable composite owner registered before approval. The proposed responsibility sits with the Computation Hub transport capability owner; this document does not appoint a person or assert an existing assignment. That owner approves combination semantics, dependency releases, uncertainty policy and end-to-end evidence. ATME and other mode owners retain their component accountability.
11.2. Journey model
A journey contains locations, legs and transported items or passenger groups. Participation records bind quantities to legs. Each leg identifies mode, origin, destination, time context and available activity observations.
Observed distance/fuel, supplied route and endpoint-derived distance are distinct input types with provenance. Policy determines their precedence and fallback. Coordinates require a declared reference system; facility identifiers are used where available. Endpoint separation is not automatically travelled distance.
An illustrative journey is A → B by road, B → C by sea and C → D by air. K4 resolves the permitted mode calculations, executes them and combines compatible results. A cargo item that leaves at C is not attributed to the air leg.
K4 evaluates the supplied transport plan. Route discovery and optimization are separate capabilities unless explicitly included in a future authorized contract. Journey-total distance can support reconciliation but cannot silently replace missing leg-level activity.
11.3. Result and evidence
K4 returns leg results, journey totals, supported mode/gas breakdowns, input and route provenance, uncertainty, completeness and root/child execution evidence. Results SHALL identify relevant emissions boundaries and characterization bases before aggregation.
Mode-engine changes require a new resolved K4 configuration. ATME's Monte Carlo variant preserves its declared seeded replay requirements; its uncertainty interval remains an output. Missing legs yield authorized fallback, explicit partial output or failure, never an apparently complete zero-filled result.
11.4. Scope 3 integration
The category controller selects K4 and an authorized transport policy. K4 selects permitted per-leg methods. Category-specific allocation is then executed through a governed capability where needed. The controller emits the category result, and S3-SUM performs inventory consolidation without double-counting K4's detail and totals.
The Scope 3 integration is normative in the Scope 3 Engine Architecture (S3-ARCH, v0.5.0), which absorbed the original change proposal and is aligned with the v0.2 identity, effects, status, batch-evidence and uncertainty provisions of this specification: D2–D4, sections 4.2, 6, 7 (with the Transport Kernel journey contract in 7.3 until the kernel's own specification is written), 8, 10 and 15.
11.5. Additional domain examples
The Scope 3 category-specific composition example will be added after that architecture is complete. It is not a dependency or release blocker for the foundational KISMET KEC/KBC/KRC/KPC/KCC contract model. The existing Transport/K4 example remains an architectural illustration and is not, by itself, evidence of production conformance.
12. Conformance and verification
Conformance SHALL be demonstrated for the released execution configuration and declared domain profiles. Verification SHALL cover meaningful behavior rather than merely mirroring implementation details.
Required evidence, as applicable, includes:
- Contract validation, units and semantic-basis checks.
- Authoritative reference cases for method correctness and boundary conditions.
- Selection/fallback tests proving authorization boundaries and recorded reasons.
- Composition checks for mapping, aggregation, missing children and double counting.
- Replay tests appropriate to the declared profile, including seeded stochastic execution.
- Dependency upgrade impact and compatibility evidence.
- Checks that business effects are prohibited and retries do not duplicate published contributions.
- Access-scope and evidence-export checks for cross-entity reuse.
A composite SHALL pass end-to-end verification even when every child already conforms independently. Certification SHALL state its scope and limitations; it is not a blanket guarantee of scientific accuracy, regulatory acceptance or future compatibility.
13. Adoption and outstanding integration work
- Register the framework document (done:
KISMET) and assign accountable framework ownership. - Map this conceptual contract onto existing MICE, method registry, identity, routing and evidence schemas.
- Define registered wire schemas and domain profiles without duplicating existing authorities.
- Implement K4 as the first composite reference case and align Scope 3 profiles.
- Publish release/conformance procedures and immutable dependency resolution.
- Extend coverage incrementally to reusable validation, transformation, policy-evaluation and other kernels.
Before production adoption, resolve the exact registry extension points, ownership/approval assignments, replay-environment guarantees, retention policy, approved non-MICE execution bindings and migration of reusable transport parameters out of Scope 3-specific naming where appropriate. These are integration tasks, not permission for implementations to invent competing conventions.
13.1. Production adoption gates
The following remain open and SHALL be resolved before production conformance is claimed:
- Verify canonical registry/artifact definitions and publish the section 5.1 binding manifest, including KISMET kernel identifier allocation.
- Publish and validate the section 6.5 wire schemas and exact canonical status mappings.
- Register constitutional subordination, lexicon terms and accountable owners.
- Establish method approval through a substantive permanent or explicitly registered interim authority.
- Approve execution bindings, including non-MICE implementations, and demonstrate absence of business side effects.
- Verify batch attribution, replay and uncertainty policy using representative transport workloads.
Draft examples or passing local schema checks alone do not satisfy these gates. No registry writes, method approvals or canonical code assignments are performed by publishing this document.
14. Decision record
| Decision | Rationale |
|---|---|
| Implementations are broader than MICE | Libraries, functions, services and compositions can realize a registered capability through approved execution bindings. |
| Stable KSMT identities are retained | Capability identity is separate from implementing engines and local aliases. |
| v0.2 prohibits business side effects | Acquisition and business actions remain explicitly governed outside calculation. |
| Batch evidence preserves item attribution | Shared manifests reduce storage without losing auditability. |
| All reusable executable kernels are in scope | Reuse and trust requirements apply beyond numerical calculations. |
| Kernels may be composite and expose several methods | A coherent capability such as transport requires multiple procedures. |
| K4 covers all transport modes | Consumers receive one reusable journey capability. |
| ATME and other mode engines retain independent identities | Specialized methods need independent ownership, improvement and evidence. |
| Journeys contain explicit legs and participation | Mode, route and transported quantity vary within one journey. |
| Controllers delegate substantive calculations | Business authority stays separate from reusable executable logic. |
| Existing platform authorities remain authoritative | KISMET provides common obligations without competing registries or routers. |
Source basis: S3-ARCH v0.2.2 and the subsequent KISMET/K4 design discussion dated 2026-10-14. External scientific methods and regulatory requirements are referenced as domain-owned concerns, not newly specified by this framework.
15. Revision history
| Version | Changes |
|---|---|
| 0.1.0 | Initial master proposal with composite transport reference architecture. |
| 0.2.0 | Broadened implementation forms beyond MICE; added kernel admission criteria and KSMT capability identities; prohibited business side effects; clarified TrustGate/ZRR boundaries; added batch evidence, proposed registration homes, envelope field contracts and status mapping requirements; defined constitutional subordination, method-approval gates, uncertainty handling and transport ownership. |
| 0.2.1 | Repository frontmatter (placed under architecture/kismet/); document ID recorded as registered; replay section anchored to the Replay Constitution (one profile per component, composite profile no stronger than its weakest dependency, BANDED tolerance from governed policy); section 11.4 points to S3-ARCH instead of the unpublished change proposal. |
Review feedback informed this revision. References to ZARM, the Constitution Manifest and Constitutional Lexicon describe required integrations whose authoritative definitions have not been independently inspected. This draft deliberately marks those bindings unresolved rather than presenting invented registrations as existing platform facts.
16. v0.3.0 alignment record (2026-10-17)
Aligned the framework with the five governed contracts, sole KISMET identity grammar, typed verdict authority, independent artifact versioning, ZAR/ALTD evidence custody and the separation of eligibility from admissibility. This revision is a candidate for constitutional and semantic-conformance review, not a production registration or deployment attestation.