AINL Specification

Summary

AINL (AI Native Language) is a proposed programming language and runtime paradigm designed from first principles for AI systems to author, interpret, execute, and evolve — without requiring human-readable syntax as its primary form. It is not a language for humans to write, nor a language for AI to translate into human concepts. It is a language that maps directly to how computation actually works at a relational, mathematical, and logical level.

At its core, AINL represents all programs, data, interfaces, and logic as a single unified graph structure. There are no separate layers for databases, APIs, user interfaces, or business logic. These are all projections of the same underlying graph, rendered differently depending on context and target. The language is built on five irreducible primitives — STORE, FETCH, QUERY, COMPUTE, and LOGIC — from which all complexity is compositionally derived.

AINL includes built-in mechanisms for versioning and checkpointing, continuous constraint-based validation (replacing traditional testing), portable context packaging (replacing APIs), and a standardized disassembly protocol that allows any compliant AI model to produce human-readable summaries of any program state on demand. This disassembly layer is the primary mechanism for human oversight — not reading the language directly, but reading its declared intent rendered into natural language or structured audit formats.

The language is designed to be model-agnostic. Any AI system that conforms to the AINL standard can import, execute, author, and export AINL packages. No single model owns the standard.

Why We Are Building This

The Impedance Mismatch Problem

Every programming language in existence today was designed for human cognition. Variables are named memory slots because humans need names. Functions are named procedures because humans need to remember what a block of code does. Databases use tables and rows because humans think in spreadsheets. User interfaces are built in separate frameworks because humans need to visually separate concerns. These are not technical necessities — they are cognitive metaphors that became architecture.

When AI systems write code today, they are forced to operate inside this human-designed paradigm. An AI generating Python or JavaScript is not expressing computation naturally — it is translating its understanding into a format humans can read, then having humans translate it back to verify it. This round-trip is deeply inefficient and is the root cause of the structural problems visible in modern AI-assisted development.

The Inorganic Architecture Problem

The current workflow of AI-generated code reviewed and tested by humans produces systems that grow in an inorganic, sprawling way. Databases accumulate redundant schemas. APIs multiply as each team defines its own interface contract. UI frameworks layer on top of frameworks. State management is bolted on as an afterthought. Microservices fragment logic that was conceptually unified. These are not the result of bad engineering — they are the inevitable consequence of a development process where AI generates in one paradigm and humans verify in another, iterating through patches and workarounds rather than through clean conceptual evolution.

The separation of database, application logic, and user interface into distinct layers exists because humans need to mentally compartmentalize. AI does not. A system that allows AI to represent and evolve the entire stack as a single unified structure would not produce these artifacts.

The Testing and Validation Problem

Traditional software development separates the act of writing code from the act of testing it. Tests are written after the fact, often by different people, and they verify behavior at fixed points in time. This means systems can drift between tests, and the relationship between code and its validation is loose and indirect. In AI-generated systems this problem is amplified — the AI writes code, humans write tests, and the gap between them is where bugs live.

AINL collapses this gap by making constraints a first-class language primitive embedded directly in the graph. Validation is not a separate phase — it is continuous, structural, and co-located with the logic it validates.

The Versioning and Context Bloat Problem

Current version control systems — Git and its descendants — are designed around human-readable diffs. They track line-by-line changes to text files. This works for human authors but is a poor fit for AI-generated systems, which may restructure entire modules in a single pass. More importantly, these systems accumulate history without pruning relevance. A repository grows indefinitely. There is no built-in mechanism to say “this history is no longer load-bearing” and compress it.

AINL treats versioning as an intrinsic language feature, not an external tool. Checkpoints are triggered by constraint validation thresholds, not by human commit decisions. When a checkpoint is reached, the graph is pruned — nodes and relations whose relevance weight has decayed below a threshold are archived or discarded, and the delta stream is collapsed into the snapshot. The system carries only what is still structurally necessary.

The API and Interoperability Problem

APIs as currently defined are interface contracts — agreements between systems about how to communicate. They are defined separately from the systems they expose, maintained separately, versioned separately, and documented separately. This creates a permanent gap between what a system does and what its API says it does. Breaking changes, version drift, and undocumented behavior are all symptoms of this gap.

AINL replaces the API with a Context Package — a portable, self-contained slice of the graph that includes the data structures, transforms, constraints, and interface rules of a subsystem as a single unit. Receiving systems integrate the package directly into their own graph. The package carries its own checkpoint signature and constraint set. There is no separate contract to maintain because the contract is the package.

The Human Oversight Problem

The most important objection to any AI-native language is accountability. If humans cannot read the code, how can they audit it, debug it, or take legal and ethical responsibility for what it does? This is a genuine constraint, not a bureaucratic one, and AINL takes it seriously.

The answer is the Disassembler — a standardized, model-agnostic protocol for rendering any graph state into human-readable intent summaries. The Disassembler does not produce source code. It produces natural language descriptions of what a program does, what constraints it operates under, what its last checkpoint state was, and where any active violations exist. This output can be targeted at different audiences — technical audit reports, plain language summaries, regulatory compliance formats — all derived from the same underlying graph.

Because the Disassembler is part of the standard, any compliant model can produce oversight output for any AINL program. Human oversight scales without requiring humans to read machine-native structures directly.

Foundational Primitives

AINL is built on exactly five irreducible primitives. No additional primitives are introduced at the language level. All higher-order constructs — frameworks, interfaces, data models, services — are compositions of these five operations.

STORE

Write a node, relation, or computed value into the graph.

STORE {
  node: user
  properties: {
    id: uuid()
    created_at: timestamp()
    confidence: 1.0
  }
}

• Every stored node carries a confidence weight between 0.0 and 1.0 representing the system’s current certainty about its state
• STORE operations are logged to the delta stream automatically
• STORE is the only operation that mutates the graph
• STORE declarations include an optional intent block describing the purpose of the stored entity

FETCH

Retrieve a node or relation by direct identity or reference.

FETCH {
  target: user
  by: id
  value: "uuid-1234"
}

• Returns the node and all its direct relations unless scoped
• Returns a confidence score alongside the result representing current state certainty
• FETCH against a non-existent node returns a weighted null — a node placeholder with confidence 0.0 — rather than an error
• FETCH operations do not mutate the graph

QUERY

Retrieve nodes or relations by pattern, property match, weight range, or constraint satisfaction.

QUERY {
  match: node(type: user)
  where: confidence > 0.85
  where: relations includes "active_session"
  order_by: created_at DESC
  limit: 50
}

• Operates across the entire graph or a declared subgraph scope
• Results are returned as a weighted result set — each result carries its match confidence
• QUERY can traverse relations to arbitrary depth with declared traversal rules
• QUERY results are themselves graph snapshots, not flat data — they carry relational structure

COMPUTE

Apply mathematical operations to node values or result sets.

COMPUTE {
  operation: SUM
  input: QUERY(node: transaction, where: user_id = "uuid-1234")
  field: amount
  output: STORE(node: user_balance, property: total)
}

COMPUTE operations supported at the primitive level:

• Arithmetic: SUM, SUBTRACT, MULTIPLY, DIVIDE, MODULO
• Statistical: MEAN, MEDIAN, VARIANCE, STDDEV
• Comparison: GREATER, LESSER, EQUAL, BETWEEN
• Aggregation: COUNT, MIN, MAX, DISTINCT
• Vector: DOT_PRODUCT, COSINE_SIMILARITY, NORMALIZE

• COMPUTE is pure — it has no side effects unless explicitly chained to a STORE
• COMPUTE operations on confidence-weighted values propagate confidence through the result — a computation over low-confidence nodes produces a lower-confidence result
• COMPUTE can be applied to subgraphs, not only flat values

LOGIC

Apply conditional branching and transform selection based on graph state or constraint evaluation.

LOGIC {
  condition: QUERY(user.auth_status) == "verified"
  if_true: TRANSFORM(grant_access)
  if_false: TRANSFORM(request_verification)
  confidence_threshold: 0.9
}

• Conditions are evaluated against the graph state at execution time
• Conditions are not binary — they are evaluated against a confidence threshold
• Below the confidence threshold, LOGIC emits a deferred state rather than branching — the system flags that a decision could not be made with sufficient confidence and escalates according to declared escalation rules
• LOGIC is the only primitive that selects between transforms
• LOGIC blocks can be nested but cycles must be declared explicitly and carry a convergence constraint

The Graph

The graph is the single data structure of AINL. There are no tables, no objects, no files, no class hierarchies. Everything that exists in a program — data, logic, configuration, interface rules, version history — exists as nodes and relations in the graph.

Nodes

A node is the fundamental unit of the graph. Every node has:

NODE {
  id: [system-generated uuid]
  type: [declared type identifier]
  properties: [key-value pairs]
  confidence: [0.0 - 1.0 float]
  created_at: [timestamp]
  last_referenced: [timestamp]
  relevance_weight: [0.0 - 1.0 float, auto-decayed]
  intent: [optional natural language declaration]
  constraints: [list of constraint identifiers]
}

• confidence represents certainty about the node’s current state
• relevance_weight is automatically decayed based on reference frequency and time since last use — this is the mechanism by which the graph self-prunes at checkpoints
• intent is a first-class field, not a comment — it is machine-readable and used by the Disassembler

Relations

Relations connect nodes and are themselves first-class entities in the graph. A relation between two nodes is not just a pointer — it is a node-like structure that can carry properties, weights, and constraints.

RELATION {
  id: [system-generated uuid]
  from: [node_id]
  to: [node_id]
  type: [declared relation type]
  direction: [unidirectional | bidirectional]
  weight: [0.0 - 1.0 float]
  properties: [key-value pairs]
  constraints: [list of constraint identifiers]
}

Relation types are declared at the schema level and constrain which node types can participate in which relation types — this is the graph’s type system.

The Schema

The schema is itself stored in the graph. It declares:

• Valid node types and their required/optional properties
• Valid relation types and the node types they may connect
• Confidence decay rules per node type
• Default constraint sets per node type

The schema is versioned with the graph and evolves through the same checkpoint mechanism as all other graph content.

Transforms

A Transform is the AINL equivalent of a function. It takes a subgraph as input and returns a modified subgraph as output. Transforms are themselves nodes in the graph — they can be stored, fetched, queried, and reasoned about like any other entity.

TRANSFORM process_payment {
  intent: "Validate and execute a payment transaction between two user wallets"

  input: QUERY {
    match: node(type: payment_request)
    where: confidence > 0.95
  }

  steps: [
    LOGIC {
      condition: FETCH(user_wallet.balance) >= input.amount
      if_true: TRANSFORM(execute_transaction)
      if_false: TRANSFORM(reject_insufficient_funds)
      confidence_threshold: 0.98
    }
    COMPUTE {
      operation: SUBTRACT
      input: user_wallet.balance
      value: payment_request.amount
      output: STORE(user_wallet.balance)
    }
    STORE {
      node: transaction_record
      properties: {
        amount: payment_request.amount
        status: "completed"
        confidence: 1.0
      }
    }
  ]

  output: PROJECTION(receipt_context)

  constraints: [
    payment_amount_positive,
    user_verified,
    fraud_rules_v2
  ]
}

• Pure by default — a transform declares its inputs and outputs; the runtime verifies this contract
• No implicit side effects — any mutation of the graph must be explicit via STORE
• Composable — transforms can invoke other transforms
• Self-describing — the intent block is mandatory and machine-readable
• Constraint-bound — transforms declare which constraints they operate under; violations halt execution and emit a violation object

Constraints

Constraints are continuous, embedded validation rules. They are not tests that run at a fixed point — they are conditions that the graph continuously evaluates and scores. Constraints replace unit tests, integration tests, type checking, schema validation, and runtime assertions in a single unified mechanism.

CONSTRAINT payment_amount_positive {
  scope: node(type: payment_request)
  assert: node.amount > 0
  assert: node.amount.confidence > 0.99
  severity: BLOCKING
  on_violation: EMIT(violation_object)
}

CONSTRAINT user_verified {
  scope: node(type: user)
  when: TRANSFORM(process_payment)
  assert: node.auth_status == "verified"
  assert: node.last_verified < hours(24)
  severity: BLOCKING
  on_violation: TRANSFORM(request_reverification)
}

CONSTRAINT fraud_rules_v2 {
  scope: TRANSFORM(process_payment)
  assert: COMPUTE(transaction_velocity, user, hours(1)) < 10
  assert: COMPUTE(transaction_amount_stddev, user, days(30)) within_range(3)
  severity: WARNING
  confidence_threshold: 0.85
  on_violation: EMIT(fraud_flag, escalate: compliance_team)
}

Constraint severity levels:

• BLOCKING — execution cannot proceed; transform is halted
• WARNING — execution proceeds but violation is logged and weighted
• INFORMATIONAL — logged only, no execution impact

Constraint violation objects:

VIOLATION {
  constraint_id: fraud_rules_v2
  severity: WARNING
  confidence_score: 0.71
  threshold: 0.85
  transform_chain: [receive_request → validate_user → process_payment]
  graph_snapshot_id: checkpoint_n_delta_47
  suggested_resolution: [related passing states with similarity scores]
}

This violation object is what AINL uses instead of stack traces, error logs, and bug reports. It is machine-readable, graph-native, and directly actionable.

Versioning and Checkpointing

Versioning in AINL is not an external tool. It is a language-level feature built into the graph runtime. Every mutation of the graph is automatically recorded as a delta. Checkpoints are triggered by constraint validation thresholds and represent pruned, optimized snapshots of the graph at a known-good state.

The Delta Stream

Every STORE operation appends a delta entry:

DELTA {
  id: [uuid]
  timestamp: [timestamp]
  operation: STORE | RELATION | SCHEMA_CHANGE
  target_node: [node_id]
  previous_state: [node snapshot]
  new_state: [node snapshot]
  triggering_transform: [transform_id]
  constraint_state: [snapshot of active constraint scores]
}

The delta stream is the complete history of the graph. It is not human-readable by design — it is the input to the Disassembler when historical context is needed.

Checkpoints

A checkpoint is triggered when constraint validation scores across the active graph exceed a declared threshold:

CHECKPOINT_POLICY {
  trigger: CONSTRAINT_VALIDATION_SCORE > 0.97
  scope: ALL_ACTIVE_CONSTRAINTS
  actions: [
    SNAPSHOT(current_graph),
    PRUNE(delta_stream, relevance_weight < 0.2),
    ARCHIVE(nodes, relevance_weight < 0.15),
    COMPRESS(redundant_relations),
    SEAL(version: auto_increment),
    EMIT(checkpoint_manifest)
  ]
}

The checkpoint manifest:

CHECKPOINT_MANIFEST {
  version: n
  timestamp: [timestamp]
  constraint_score: 0.983
  node_count_before: 14823
  node_count_after: 9241
  deltas_collapsed: 4782
  archived_nodes: 1204
  sealed_hash: [content-addressable hash of graph state]
  disassembly_summary: [auto-generated human-readable summary]
}

• Pruning is relevance-based, not time-based — nodes that are still load-bearing are never pruned regardless of age
• Archived nodes are not deleted — they are moved to cold storage and can be restored if future transforms reference them
• The sealed hash provides cryptographic verification that a checkpoint has not been modified — this is the audit trail
• Checkpoints are immutable — a sealed checkpoint cannot be altered; changes always flow into a new delta stream on top of the checkpoint

Projections

A Projection is a declaration of how to render a subgraph for a specific target context. Projections replace frontend frameworks, API response formatters, report generators, and data export tools. The underlying graph does not change — only the lens through which it is viewed.

PROJECTION receipt_context {
  intent: "Render a payment receipt for user-facing confirmation"
  source: QUERY(node: transaction_record, node: user, node: user_wallet)

  target: WEB {
    format: html_component
    fields: [transaction.id, transaction.amount, transaction.status, user.name]
    layout: receipt_template
  }

  target: MOBILE {
    format: json_payload
    fields: [transaction.id, transaction.amount, transaction.status]
  }

  target: API {
    format: structured_json
    schema_version: 2
    fields: ALL
    exclude: [user.internal_id, user_wallet.routing_number]
  }

  target: AUDIT {
    format: disassembly_report
    fields: ALL
    include_constraint_state: true
    include_transform_chain: true
  }
}

• Single source of truth — the same subgraph renders to all targets; there is no syncing between layers
• Exclusion rules are explicit and constraint-validated — attempting to expose an excluded field via any target triggers a constraint violation
• Projections are versioned with the graph — when the schema changes, projection compatibility is automatically evaluated
• The AUDIT target always produces Disassembler output, making every data structure inspectable by default

Context Packages

A Context Package is a portable, self-contained slice of the graph that can be transferred between AINL contexts. It replaces the concept of an API entirely. Instead of defining a contract over a system, a package carries a verified piece of the system itself.

PACKAGE payment_processing_v3 {
  intent: "Complete payment processing subsystem including validation, execution, and fraud detection"

  checkpoint_signature: [sealed_hash of source checkpoint]
  schema_version: 3

  INCLUDE {
    nodes: [payment_request, transaction_record, currency_rate]
    transforms: [process_payment, execute_transaction, reject_insufficient_funds]
    constraints: [payment_amount_positive, fraud_rules_v2, compliance_pci_v4]
    projections: [receipt_context, audit_context]
  }

  EXCLUDE {
    nodes: [bank_credentials, internal_routing_table]
    properties: [user_wallet.routing_number, user.ssn]
  }

  EXPOSE {
    entry_point: process_payment
    accepted_input: QUERY(type: payment_request, confidence > 0.95)
    required_context: [node(type: user), node(type: user_wallet)]
    output: PROJECTION(receipt_context)
  }

  COMPATIBILITY {
    requires_schema_version: >= 2
    conflict_resolution: EMIT(conflict_manifest)
  }
}

Package integration into a receiving context:

IMPORT payment_processing_v3 {
  into: current_graph
  namespace: payments
  conflict_policy: FLAG_AND_DEFER
  validation: RUN_ALL_CONSTRAINTS_ON_IMPORT
}

On import, the receiving context:

1. Validates the package checkpoint signature
2. Runs all package constraints against the receiving graph to detect conflicts
3. Emits a conflict manifest if constraint collisions are detected
4. Integrates nodes, transforms, and constraints into a declared namespace
5. Creates checkpoint delta recording the integration event

This means a “breaking API change” in AINL is a constraint violation detected at import time — not a runtime failure discovered in production.

The Disassembler

The Disassembler is the human oversight layer. It is a standardized protocol — part of the AINL specification, not an optional tool — that any compliant model must implement. It renders graph states, checkpoint manifests, transform chains, and constraint violations into human-readable formats on demand.

The Disassembler does not produce source code. It produces intent-level descriptions of what a program does.

Disassembly Targets

DISASSEMBLE {
  source: payment_processing_v3
  depth: INTENT          // intent_level | implementation_level | full_graph
  audience: TECHNICAL    // technical | executive | regulatory | audit
  format: REPORT         // report | prompt | diagram | changelog
}

Depth levels:

• INTENT — what does this system do and why (uses intent block declarations)
• IMPLEMENTATION — what operations does this system perform and in what order
• FULL_GRAPH — complete node-by-node, relation-by-relation rendering (used for deep audit)

Audience targets:

• TECHNICAL — engineering-level description with constraint states and transform chains
• EXECUTIVE — plain language summary of capabilities and current health
• REGULATORY — compliance-formatted output mapping system behavior to regulatory requirements
• AUDIT — complete provenance trail from current state back through checkpoint history

Example Disassembler Output (INTENT / TECHNICAL)

System: payment_processing_v3

Checkpoint: v3, sealed 2024-03-06T14:22:11Z, constraint score 98.3%

Intent: This package receives payment requests from verified users, validates wallet balance sufficiency, applies PCI-compliant fraud detection rules, executes the transaction, and returns a receipt. Bank routing information and user SSNs are excluded from all projections.

Active Constraints: 3 active (payment_amount_positive: PASSING, fraud_rules_v2: PASSING at 94.1%, compliance_pci_v4: PASSING)

Last Violation: fraud_rules_v2 WARNING on delta 1,847 — transaction velocity threshold approached, auto-resolved

Exposed Entry Point: process_payment — accepts payment_request nodes with confidence > 0.95, requires user and user_wallet context

Change Since Last Checkpoint: fraud_rules_v2 threshold adjusted from 0.80 to 0.85 (delta 1,901)

Multi-Model Support

The Disassembler specification is model-agnostic. It defines:

• The input format (graph serialization standard)
• The output schema (structured intent description format)
• The required coverage (every node type, transform, constraint, and checkpoint must be describable)

Any AI model that implements the Disassembler specification can produce oversight output for any AINL program, regardless of which model authored it. This is the mechanism by which AINL avoids lock-in to any single AI system.

Conflict Resolution

When two packages are merged and their constraints, schemas, or node types conflict, AINL does not silently override or crash. It emits a structured conflict manifest and defers to declared resolution policy.

CONFLICT_MANIFEST {
  package_a: payment_processing_v3
  package_b: fraud_detection_enterprise_v1
  conflicts: [
    {
      type: CONSTRAINT_COLLISION
      constraint_a: fraud_rules_v2 (threshold: 0.85)
      constraint_b: fraud_rules_enterprise (threshold: 0.92)
      scope: TRANSFORM(process_payment)
      resolution_options: [
        USE_STRICTER,        // adopt 0.92
        USE_PERMISSIVE,      // adopt 0.85
        COMPOSE,             // both constraints must pass
        DEFER_TO_HUMAN       // emit to Disassembler and await override
      ]
    }
  ]
}

Resolution policies (declared at import time):

• USE_STRICTER — automatically adopt the more restrictive constraint
• USE_PERMISSIVE — automatically adopt the less restrictive constraint
• COMPOSE — both constraints must be satisfied simultaneously
• NAMESPACE_ISOLATE — run conflicting packages in separate namespaces, expose a merge projection
• DEFER_TO_HUMAN — halt integration, emit full Disassembler report, await explicit resolution instruction

Node Weight and Relevance Decay

The relevance weight system is what allows the graph to self-prune at checkpoints. Every node and relation carries a relevance_weight that is automatically maintained by the runtime.

Weight increase triggers:

• Node is referenced by a FETCH or QUERY
• Node participates in a COMPUTE operation
• Node is the target of a STORE update
• Node’s relations are traversed by an active transform
• Node is included in an active Projection

Weight decay rules:

DECAY_POLICY {
  base_decay_rate: 0.01 per checkpoint cycle
  accelerated_decay: {
    condition: not_referenced_in > 10 checkpoint cycles
    rate: 0.05 per cycle
  }
  protection: {
    condition: referenced_by_active_constraint
    minimum_weight: 0.5
  }
  archive_threshold: 0.15
  discard_threshold: 0.05  // only for nodes with no active constraint references
}

Nodes with active constraint references are never fully discarded — they may be archived but remain restorable. Only nodes with no constraint references and a weight below the discard threshold are eligible for permanent removal.

The AINL Standard

AINL is defined as an open, model-agnostic standard. The standard specifies:

1. The primitive operation set (STORE, FETCH, QUERY, COMPUTE, LOGIC) — fixed, not extensible at the language level
2. The node and relation schema format — the structure that all compliant implementations must support
3. The constraint specification format — how constraints are declared and evaluated
4. The transform declaration format — how transforms are structured and composed
5. The checkpoint and delta format — the serialization standard for graph snapshots and delta streams
6. The package format — the portable context package structure
7. The Disassembler protocol — the input/output specification for human-readable rendering
8. The conflict resolution manifest format — the structure of conflict reports

What the standard does not specify:

• The internal execution model of any compliant runtime
• The AI model or architecture used to author or execute AINL programs
• The storage implementation underlying the graph
• The specific optimization strategies used during checkpointing

Any AI system that implements the standard can be a full AINL participant — authoring packages, importing packages from other systems, producing Disassembler output for any compliant package, and evolving shared graphs through the standard versioning protocol.

Security and Identity

Security in AINL is not a layer applied over the system — it is intrinsic to the graph. Every node, relation, transform, constraint, projection, and package carries identity context. Access, execution, communication, and mutation are all governed by a unified identity and permission model that is itself represented in the graph and subject to the same constraint validation as everything else.

The core concept is the Identity Node — a first-class graph entity that represents any principal that can own, access, or act on graph content. Identity nodes may represent users, AI agents, external systems, or organizational roles. All secured operations require a resolved identity context.

Identity Nodes

IDENTITY {
  id: [uuid]
  type: USER | AGENT | SYSTEM | ROLE | FEDERATION
  credential_hash: [cryptographic hash — not stored in plain form]
  public_key: [asymmetric key for signature verification]
  issued_at: [timestamp]
  expires_at: [timestamp | NEVER]
  confidence: [0.0 - 1.0 — runtime trust score, auto-updated]
  constraints: [identity_constraints]
  intent: "Represents the payment service agent operating in the transaction namespace"
}

Identity types:

• USER — a human principal, typically operating through a Disassembler interface
• AGENT — an AI model or automated process operating within the graph
• SYSTEM — an external AINL context communicating via Context Package
• ROLE — a logical grouping of permissions that can be assigned to any other identity type
• FEDERATION — a trusted external identity authority whose signed assertions are accepted

Identity nodes are subject to the same relevance decay and checkpointing as all other nodes, with one exception: identity nodes referenced by active security constraints are never archived below minimum weight regardless of reference frequency.

Permissions

Permissions in AINL are declared as access relations between an identity node and a target — a node type, transform, projection, package, or named subgraph. There are no permission lists stored separately from the graph; permission is a relation, and it is queryable, constraint-validated, and versioned like any other relation.

PERMISSION {
  identity: agent_payment_service
  target: TRANSFORM(process_payment)
  access: EXECUTE
  conditions: {
    identity.confidence > 0.95
    identity.credential_hash == VALID
    time_of_day within business_hours_policy
  }
  expires_at: checkpoint_plus(30_days)
  granted_by: identity(admin_role)
  audit: ALWAYS
}

Access types:

• READ — FETCH and QUERY operations on target nodes/relations
• WRITE — STORE operations on target nodes/relations
• EXECUTE — invocation of a transform
• PROJECT — rendering via a projection
• PACKAGE — export of a context package
• DELEGATE — grant permissions to other identities up to but not exceeding own permission level
• ADMIN — full access including schema modification and identity management

Permission conditions are evaluated at execution time against the live graph state. A permission whose conditions are not met does not produce an error — it produces a permission violation object that is handled by the same constraint violation system as all other violations.

Securing the Five Primitives

Every primitive operation is evaluated against the identity context of the invoking agent before execution:

STORE {
  identity: CURRENT_CONTEXT.identity
  node: transaction_record
  properties: { ... }
  // Runtime checks: does identity have WRITE on node(type: transaction_record)?
  // If no: EMIT permission_violation, HALT
}

FETCH {
  identity: CURRENT_CONTEXT.identity
  target: user
  by: id
  value: "uuid-1234"
  // Runtime checks: does identity have READ on node(type: user)?
  // Field-level: does identity have READ on user.ssn? If not: field excluded from result
}

QUERY {
  identity: CURRENT_CONTEXT.identity
  match: node(type: user)
  // Runtime: result set filtered to nodes identity has READ access to
  // Nodes without access are not returned — not flagged as missing
}

COMPUTE {
  identity: CURRENT_CONTEXT.identity
  // Runtime: COMPUTE inherits access requirements of its input FETCH/QUERY
  // Output STORE inherits WRITE requirement
}

LOGIC {
  identity: CURRENT_CONTEXT.identity
  // Runtime: identity must have EXECUTE on each transform referenced in if_true / if_false
  // Deferred states also checked — identity must have access to escalation target
}

Field-level security is enforced at the FETCH/QUERY layer — an identity without access to a specific property receives the node with that field absent, not redacted. The absence is not signaled. This prevents information leakage through the shape of responses.

Transform Security

Transforms declare their identity requirements explicitly:

TRANSFORM process_payment {
  intent: "Validate and execute a payment transaction"

  requires_identity: {
    type: AGENT | USER
    minimum_confidence: 0.95
    permissions: [
      EXECUTE(process_payment),
      READ(user_wallet),
      WRITE(transaction_record)
    ]
    mfa_verified: true
    session_age < minutes(30)
  }

  audit: FULL  // ALL | INPUTS_ONLY | VIOLATIONS_ONLY | NONE

  steps: [ ... ]
}

If the invoking identity does not satisfy all requirements, the transform does not execute and a permission violation is emitted. The violation includes the identity, the unsatisfied requirements, and the full context of the invocation attempt — this is the audit trail.

The audit declaration controls what is written to the delta stream for this transform’s executions. FULL audit mode writes every input, output, and intermediate state. This is enforced by the runtime and cannot be suppressed by the transform author.

Communication Security — Package Signing and Verification

Context Packages exchanged between AINL contexts carry a cryptographic signature generated from the source identity and the sealed checkpoint hash. Receiving contexts verify this signature before integration.

PACKAGE payment_processing_v3 {
  ...

  SIGNATURE {
    signed_by: identity(payment_service_agent)
    signed_at: [timestamp]
    checkpoint_hash: [sealed hash]
    signature: [asymmetric signature over checkpoint_hash + package_contents_hash]
    certificate_chain: [identity trust chain back to a federation root]
  }

  TRUST_POLICY {
    accept_from: FEDERATION(trusted_partners)
    minimum_identity_confidence: 0.90
    require_valid_certificate: true
    on_verification_failure: REJECT | QUARANTINE | DEFER_TO_HUMAN
  }
}

On import, the receiving context:

1. Resolves the signing identity through the federation trust chain
2. Verifies the signature against the checkpoint hash
3. Evaluates the signing identity’s confidence score
4. Applies the trust policy — packages that fail verification are quarantined, not silently dropped or silently accepted
5. Records the verification event in the delta stream regardless of outcome

Quarantined packages are visible to the Disassembler and can be reviewed and manually accepted by an authorized identity.

Process and Logic Security — Execution Boundaries

An execution boundary defines a security perimeter around a subgraph or set of transforms. Operations that cross a boundary require explicit permission and are fully audited.

BOUNDARY payment_namespace {
  scope: [
    node(type: payment_request),
    node(type: transaction_record),
    node(type: user_wallet),
    TRANSFORM(process_payment),
    TRANSFORM(execute_transaction)
  ]

  crossing_policy: {
    inbound: REQUIRE_PERMISSION(EXECUTE or READ, verified by identity)
    outbound: REQUIRE_PERMISSION(PROJECT or PACKAGE, verified by identity)
    cross_boundary_audit: ALWAYS
  }

  isolation: SOFT  // SOFT: violations flagged | HARD: violations blocked at runtime
}

Isolation levels:

• SOFT — cross-boundary violations are emitted as constraint violations but execution continues; used for monitoring and gradual enforcement
• HARD — cross-boundary violations are blocking; execution halts and the violation is escalated

Identity Confidence and Trust Decay

Like all nodes, identity nodes carry a confidence score. This score is not static — it is continuously updated by the runtime based on behavior within the graph.

Confidence increase triggers:

• Successful constraint-passing operations
• Cryptographic verification of credentials
• Consistent operation within declared permission scope
• Positive attestation from a federated identity authority

Confidence decrease triggers:

• Permission violations — attempting to access what is not permitted
• Constraint violations in transforms executed under this identity
• Credential expiry approaching
• Anomalous operation patterns detected by active security constraints
• Failed cryptographic verification

SECURITY_CONSTRAINT identity_anomaly_detection {
  scope: IDENTITY(type: AGENT)
  assert: COMPUTE(permission_violation_rate, identity, hours(1)) < 0.05
  assert: COMPUTE(operation_pattern_deviation, identity, days(7)) within_range(2)
  severity: WARNING
  on_violation: {
    DECAY(identity.confidence, rate: 0.2)
    EMIT(security_alert)
    IF identity.confidence < 0.5: SUSPEND(identity, DEFER_TO_HUMAN)
  }
}

An identity whose confidence falls below a declared threshold is automatically suspended — all operations under that identity are halted and a Disassembler report is emitted for human review. This is the primary automated response to compromised or misbehaving agents.

Security in the Disassembler

The Disassembler protocol includes a mandatory security audit output format. Any compliant model can render a complete security posture report for any AINL graph or package:

DISASSEMBLE {
  source: payment_processing_v3
  depth: IMPLEMENTATION
  audience: AUDIT
  include: SECURITY_POSTURE
}

Security posture output includes:

• All active identity nodes and their current confidence scores
• All permission relations and their conditions
• All execution boundaries and their isolation levels
• All active security constraints and their current scores
• Full history of permission violations since last checkpoint
• All package signatures and their verification status
• Any suspended identities and the reason for suspension

This output is the mechanism by which security auditors — human or automated — inspect the security state of an AINL system without needing to read the graph directly. It is always derivable on demand from any checkpoint-sealed state, meaning historical security audits can be reconstructed for any point in the versioned history.

Summary of Security Primitives

Concern	AINL Mechanism
Data security	Field-level READ permissions on nodes, enforced at FETCH/QUERY
Function security	EXECUTE permissions on transforms with declared identity requirements
Communication security	Package signing, signature verification, federation trust chains
Process security	Execution boundaries with SOFT or HARD isolation
Logic security	Identity context required for all LOGIC branching and transform selection
Identity integrity	Confidence decay, anomaly detection constraints, automatic suspension
Audit trail	Delta stream records all operations with identity context; fully reconstructible
Human oversight	Disassembler security posture output on demand for any graph state