1. Introduction #

1.1 The Problem #

The generative AI revolution has produced hundreds of specialized tools — each with its own API format, authentication method, and response structure. This fragmentation creates developer burden through custom integration code for each provider, vendor lock-in when switching providers requires rewriting applications, workflow friction when chaining tools requires format conversion, and no standard way to compare outputs across providers.

A parallel problem exists inside AI agents themselves: without a naming standard, every team invents its own key vocabulary for fields, configuration properties, and persona data. Keys proliferate without governance — some snake_case, some camelCase, some abbreviated, some redundant — until the system becomes unmaintainable and incompatible with external implementers.

1.2 The Solution #

AIX addresses both problems with a single specification. It defines a standard envelope for AI task requests and responses so any AIX-compliant tool can accept standardized inputs, return standardized outputs, be swapped with any other tool in the same category, and chain seamlessly with other AIX tools in workflows. It also defines a canonical naming convention so every field, key, and identifier in the AIX ecosystem is unambiguous, hierarchical, and implementable by developers with no internal context.

1.3 Heritage: CrossARM (2014) #

AIX follows the pattern established by CrossARM, a data interchange standard developed by Ubertrends LLC in 2014 for cross-platform marketing data exchange. CrossARM’s governing principle was: use Schema.org canonical names where they exist, and invent proprietary extensions for what Schema.org does not cover.

// CrossARM 2014 — Schema.org base vocabulary
givenName, familyName, worksFor, address, email, telephone  (Person)
brand, legalName, duns, isicV4                              (Organization)

// CrossARM 2014 — Proprietary extensions (Schema.org had no equivalent)
facebookName, twitterName, twitterFollowers, engagementRate
uniqueVisits, timeOnSite, bounceRate, influencerRating

AIX v2.0 formalizes this pattern. Schema.org canonical names are used wherever applicable. Fields that Schema.org does not cover are defined as AIX extensions, noted as such in the registry.

1.4 Relationship to Existing Standards #

2. Core Naming Principles #

These principles govern every field name, key, and identifier in the AIX specification and in any AIX-compliant implementation.

2.1 camelCase Throughout #

All field names and identifiers use camelCase. No snake_case, no kebab-case, no PascalCase for field names. This aligns with JSON, JavaScript, and modern API conventions.

// ✓ Correct
givenName  familyName  jobTitle  telephoneMobile  linkedinUrl

// ✗ Incorrect
given_name    // snake_case
given-name    // kebab-case
GivenName     // PascalCase

Layer-specific exceptions: - Database columns use snake_case by PostgreSQL convention. API responses, JSON exports, and all specification field names use camelCase. ORM/serialization layers handle the translation (e.g., given_name → givenName). - Slugs and URLs use dash-case (e.g., futuresight-studio, rss-discovery). Slugs are identifiers in routing and storage contexts, not AIX field names, and follow web convention. Slug values are never used as AIX field keys. - Schema version strings use the format {type}-v{N} (e.g., studio-json-v1, canvas-document-v1). These are opaque version identifiers, not field keys, and are exempt from the camelCase rule.

2.2 Hierarchical Namespace #

Every internal AIX identifier (agent configs, format types, quality passes, module keys) follows a strict four-part hierarchy. Each segment narrows scope from broad to specific. Underscores serve exclusively as namespace separators — they are not snake_case within a segment.

{component}_{objectType}_{identifier}_{property}

writingAgent_format_default_systemPrompt
writingAgent_format_newsletter_outputRules
researchAgent_qualityPass_hallucinationSweep_systemPrompt
personaAgent_voice_brand
publishingModule_emailStudio_studioJson

2.3 Schema.org Base + AIX Extensions #

For persona data and interchange fields, AIX uses Schema.org canonical property names where they exist. When Schema.org does not have a suitable property, AIX defines extensions, marked ‘AIX extension’ in the Source column.

2.4 No Abbreviations #

All segments use full English words. The only exceptions are established industry acronyms registered in the AIX permitted acronym list.

Permitted acronyms: aix, api, url, html, json, uuid, naics, rss, uma

rss added 2026-05-12. RSS (Really Simple Syndication / RDF Site Summary) has been the W3C-canonical name for the format since 2002. uma added 2026-05-09. UMA (Unified Module Architecture) is the registered module platform layer in the AIX ecosystem.

2.5 Identifier Names the Format — Properties Define It #

The identifier segment (position 3 in the hierarchy) uses a short, stable handle. The systemPrompt and outputRules properties carry the full behavioral specification. Never encode behavior into the identifier name.

// ✓ Correct — identifier is a short stable handle
writingAgent_format_newsletter_systemPrompt
writingAgent_format_newsletter_outputRules

// ✗ Wrong — behavior encoded into identifier name
writingAgent_format_formattedNewsletterWithCuratedSections_systemPrompt

2.6 Naming Validation Tests #

Before any new key is ratified, it must pass all six tests. A key that fails any test must be revised.

3. Persona Field Registry #

The Persona Field Registry defines every field in the AIX identity vault. Each field is either a Schema.org canonical property (used as-is) or an AIX extension (defined because Schema.org has no equivalent). This registry is the authoritative source for all Persona Vault implementations.

Schema.org canonical fields are used as-is. AIX extension fields are marked ‘AIX extension’ in the Source column. The field key is the bare name — e.g., linkedinUrl, not aix:linkedinUrl.

3.1 Essentials #

3.2 Professional #

3.3 Organization #

These fields describe the author’s organization or business entity. They use Schema.org Organization vocabulary where available.

legalName is a shared field defined authoritatively in §3.4 Financial & Legal. It appears here because Organization context is where most implementations first encounter it. §3.4 is the canonical definition.

3.4 Financial & Legal #

AIX Disambiguation Pattern — Schema.org has single-value properties for address, telephone, and email. AIX extends each with a qualifier suffix: addressBusiness / addressHome, telephoneBusiness / telephoneMobile, emailBusiness / emailPersonal. The Schema.org base property is not used directly in AIX implementations.

3.5 Media Collections #

AIX v2.1 introduced the media array: a collection of Medium entries, each typed with controlled vocabulary, carrying its own name, optional brand, optional tagline, optional URL, and a primary flag.

Field Definitions #

mediumName vs. worksFor — worksFor names the organization ("Ubertrends LLC"). mediumName names the media surface ("Ubertrends"). For solo operators whose company IS their media brand, the values may converge. Template substitution contexts differ: {worksFor} = organizational affiliation; {mediumName} = publication/media byline.

mediumType Controlled Vocabulary #

Implementations MUST accept unknown mediumType values without error, treating them as other.

Template Substitution Resolution Rule #

When a Writing Agent resolves {mediumName}, {mediumBrand}, or {mediumTagline} at generation time:

This resolution rule is normative. Any AIX-compliant Writing Agent must implement it identically.

Reference Implementation Example #

"media": [
  {
    "mediumType": "newsletter",
    "mediumName": "Ubertrends",
    "mediumBrand": "FutureSight",
    "mediumTagline": "America's Most Influential Trend Spotter",
    "mediumUrl": "https://ubertrends.com",
    "isPrimary": true
  },
  {
    "mediumType": "platform",
    "mediumName": "Solo Trillion Orchestra",
    "mediumUrl": "https://solotrillion.ai",
    "isPrimary": false
  }
]

Backwards Compatibility #

AIX v2.1 is purely additive. The non-canonical {publication_name} placeholder is deprecated in favor of {mediumName}. {publication_name} will be removed in v3.0.

3.6 Social Media #

Naming pattern: {platform}Url — the Url suffix is required. Without it, linkedin is ambiguous (handle string, URL, or boolean). Schema.org equivalent: sameAs (array) — insufficient for per-platform agent use.

3.7 Contact (Email) #

3.8 Preferences #

3.9 Conversational Agent #

3.10 Published Works #

AIX v2.2 introduces fields for authors who publish long-form structured works (books, field guides, reference manuals). These fields enable book chapter chaining, sidebar attribution, and cross-referencing within multi-chapter publications.

Stranger Test validation (all 10 fields): All fields use full English words, follow the {concept}{Qualifier} camelCase pattern, and are self-describing to a developer with no internal context. bookKey and chapterKey use Key as a suffix indicating a stable slug identifier — consistent with the AIX extension pattern for opaque handles.

4. Component & Agent Registry #

Components are the top-level namespace segment in all AIX hierarchy keys. New components require a spec amendment before use.

4.7 Agent Behavioral Modes #

AIX-compliant agents may declare a behavioral mode that governs how they respond to inputs and initiate actions.

4.7.1 The Problem #

Without a standard mode declaration, agents default to their training bias — typically “helpful general assistant” — regardless of the role they are assigned. A naming standard alone does not solve this; behavior must be declarable and queryable at the protocol level.

4.7.2 The behavioralMode Field #

{
  "aix": "2.2",
  "agent": {
    "id": "rosie",
    "role": "chief_of_staff",
    "behavioralMode": "observer",
    "allowedModes": ["observer", "orchestrator", "briefing", "off"]
  }
}

4.7.3 Standard Mode Vocabulary #

4.7.4 Mode Transitions #

Behavioral mode transitions must be explicit. An agent must not self-transition between modes based on conversation context alone. Mode changes require a direct user instruction, a scheduled trigger, or an orchestration signal from another AIX-compliant agent.

4.7.5 Mode Declaration in Task Envelopes #

{
  "aix": "2.2",
  "task": { "type": "content_authoring", "provider": "anthropic", "model": "claude-sonnet-4-6" },
  "meta": { "requestId": "req_abc123", "timestamp": "2026-05-01T09:00:00Z", "agentMode": "orchestrator" }
}

4.7.6 Soul Documents #

A Soul Document is a persistent identity file that defines an agent’s role, constraints, personality, and behavioral boundaries. Loaded before any system prompt, conversation history, or user input.

The Soul Document pattern was formalized in AIX 2.1 based on implementation experience with Solo Trillion Orchestra’s Rosie agent and the OpenClaw project’s SOUL.md architecture.

4.7.7 Relationship to Existing Standards #

4.8 Module Manifest Standard #

AIX v2.2 formally ratifies the module manifest hierarchy for the Unified Module Architecture (UMA) platform layer. Modules are self-describing units that declare their identity, requirements, and contracts in a standardized manifest.

4.8.1 Module Key Hierarchy #

Module keys follow the four-part AIX hierarchy with a specialized pattern:

{moduleType}Module_{moduleId}_{property}

publishingModule_emailStudio_studioJson
publishingModule_emailStudio_publishRecord
researchModule_rssDiscovery_feedUrl

Module type segments (position 1): - publishingModule — Content publishing and distribution modules - researchModule — Research, discovery, and source modules - writingModule — Writing assistance and generation modules - personaModule — Identity and voice customization modules

Module ID segment (position 2): The registered moduleId in camelCase (e.g., emailStudio, rssDiscovery). This corresponds to the module’s app_id slug converted to camelCase. Note: the manifest’s moduleId field stores the dash-case slug ("futuresight-studio"); the AIX hierarchy key uses its camelCase equivalent (emailStudio). These are the same module — different representations for different contexts.

Property segment (position 3+): The specific property or data schema key.

4.8.2 Module Manifest Schema #

Every AIX-compliant module carries a manifest object:

{
  "aixVersion": "2.2",
  "moduleId": "futuresight-studio",
  "moduleType": "publishing",
  "displayName": "FutureSight Studio",
  "version": "1.0.0",
  "requires": ["writingAgent", "personaAgent"],
  "inputContracts": ["content_authoring"],
  "outputContracts": ["studio-json-v1"],
  "permissionScopes": ["persona:read", "writing:generate", "publishing:send"],
  "billing": { "model": "per_use", "unit": "generation" }
}

Slug-to-camelCase rule: The module’s app_id is dash-case (futuresight-studio). The AIX module key uses camelCase for the identifier segment (emailStudio). The dash-case slug is used in routing and database storage only; the camelCase form is the canonical AIX key.

5. Reserved Segment Vocabulary #

5.1 Object Type Segments (Position 2) #

documentType deprecated: The documentType object segment (used in v2.0–v2.1 keys like writingAgent_documentType_article_systemPrompt) is deprecated in v2.2. New keys use format. Deprecated keys remain in the registry marked [DEPRECATED]; do not use for new implementations.

5.2 Identifier Segments (Position 3) #

Format Identifiers (under writingAgent_format) #

default is the open-form workhorse — shaped entirely by the user’s persona and config, producing articles, proposals, field guides, business plans, or any freeform document. Named formats have a defined structure.

Migration note: article and fieldGuide identifiers (previously under writingAgent_documentType_*) are deprecated. writingAgent_format_default_systemPrompt is the canonical replacement. Existing implementations using these identifiers should migrate; deprecated keys remain in §6 for reference.

Quality Pass Identifiers (under {agent}_qualityPass) #

Universal quality control vocabulary shared across all agents.

Voice Identifiers (under personaAgent_voice) #

Config Identifiers (under {agent}_config) #

5.3 Property Segments (Position 4) #

6. Canonical Key Reference #

The master reference for all currently ratified AIX hierarchy keys.

Key version markers: - Keys marked 1.x were introduced in v1.x of the specification - Keys marked 2.0** are newly introduced in v2.0 - Keys marked 2.0* replace prior v1.2 keys - Keys marked 2.2** are newly introduced in v2.2 - Keys marked [DEPRECATED] must not be used for new work; retained for backwards compatibility

6.1 Persona Agent — Voice #

6.2 Writing Agent — Format (v2.2) #

6.3 Research Agent #

6.4 UMA Platform Keys (v2.2) #

Platform-level keys for the Unified Module Architecture. These keys travel at the platform layer, not the agent layer.

6.5 Publishing Module — FutureSight Studio (v2.2) #

Keys for the FutureSight Studio publishing module (moduleId: emailStudio).

6.6 Deprecated Keys #

These keys remain in the registry for backwards compatibility. Do not use for new implementations.

7. AIX Envelope & Task Types #

7.1 The AIX Envelope #

Every AIX message is wrapped in an envelope. The aix field carries the specification version.

{
  "aix": "2.2",
  "id": "uuid-v4",
  "timestamp": "ISO-8601",
  "task": { "type": "...", "provider": "...", "model": "..." },
  "input": { },
  "output": { },
  "meta": { "cost": { }, "latency": { }, "tokens": { } },
  "error": { }
}

7.2 Task Type Registry #

7.3 Metadata Object #

"meta": {
  "cost":    { "amount": 0.018, "currency": "USD", "unit": "per_request" },
  "latency": { "totalMs": 8400, "processingMs": 8100, "networkMs": 300 },
  "tokens":  { "input": 4200, "output": 1850, "total": 6050 },
  "modelVersion": "claude-sonnet-4-6",
  "requestId": "req_abc123",
  "region": "us-east-1",
  "retention": { "inputStored": false, "outputStored": true, "retentionDays": 30 }
}

7.4 Error Object #

"error": {
  "code": "rate_limited",  // invalid_input | rate_limited | quota_exceeded |
                           // content_filtered | model_unavailable | timeout |
                           // provider_error | unknown
  "message": "Rate limit exceeded for this model.",
  "retryable": true,
  "retry_after_ms": 5000,
  "provider_error": { }   // Raw error object from provider
}

8. Task-Specific Schemas #

8.1 content_authoring #

The content_authoring task type enables AI-generated content carrying full author identity, editorial voice, structural guidelines, and hard guardrails.

Input: author object #

"author": {
  "givenName": "Michael",
  "familyName": "Tchong",
  "displayName": "Michael Tchong",
  "jobTitle": "Founder, Solo Trillion",
  "bio": "Short author bio for attribution",
  "socialProfiles": {
    "linkedinUrl": "https://linkedin.com/in/michaeltchong",
    "twitterUrl":  "https://x.com/michaeltchong",
    "youtubeUrl":  "https://youtube.com/@michaeltchong",
    "url":         "https://ubertrends.com"
  },
  "media": [
    {
      "mediumType": "newsletter",
      "mediumName": "Ubertrends",
      "mediumBrand": "FutureSight",
      "isPrimary": true
    }
  ]
}

Input: voice, research, brief #

"voiceBrand":      "...",
"voiceGuidelines": "...",
"voiceGuardrails": "...",

"researchPacket": {
  "topic":          "...",
  "thesis":         "...",
  "narrativeAngle": "...",
  "keyFindings": [
    { "finding": "...", "sourceUrl": "...", "confidence": 8, "isContrarian": true }
  ],
  "traceabilityTable": [
    { "finding": "...", "sourceUrl": "...", "supportingPassage": "...", "confidence": 8 }
  ],
  "auditSummary": { "auditPassed": true, "hallucinationsFound": 0 }
},

"contentBrief": {
  "format":            "default",
  "toneOverride":      "contrarian",
  "targetLength":      "standard_1200",
  "targetPublication": "Solo Trillion",
  "selectedFindings":  []
}

Output #

"output": {
  "draft": {
    "headlineOptions": ["...", "...", "..."],
    "lede":    "...",
    "body":    "...",
    "sections": [{ "heading": "...", "content": "..." }],
    "cta":     "...",
    "wordCount": 1247,
    "citations": [{ "text": "...", "url": "...", "title": "..." }]
  },
  "guardrailFlags": [{ "flag": "...", "location": "...", "recommendation": "..." }],
  "finishReason": "complete"
}

8.2 voice_synthesis #

"input": {
  "text": "Welcome to the future of AI interchange standards.",
  "voice": "aria",  "language": "en-US",  "speed": 1.0,
  "emotion": "neutral",  "outputFormat": "mp3",  "sampleRate": 24000
},
"output": {
  "audio": { "url": "...", "format": "mp3", "sampleRate": 24000,
             "channels": 1, "durationMs": 3200, "fileSizeBytes": 51200 },
  "wordTimestamps": [{ "word": "Welcome", "startMs": 0, "endMs": 320 }]
}

8.3 image_generation #

"input": {
  "prompt": "A futuristic city at sunset, cyberpunk style",
  "negativePrompt": "blurry, low quality",
  "width": 1024,  "height": 1024,
  "style": "photorealistic",  "numOutputs": 1,
  "outputFormat": "png",  "seed": 42
},
"output": {
  "images": [{ "url": "...", "format": "png", "width": 1024, "height": 1024,
               "fileSizeBytes": 1048576, "revisedPrompt": "..." }],
  "nsfwDetected": false
}

8.4 text_generation #

"input": {
  "prompt": "...",  "systemPrompt": "...",
  "messages": [{ "role": "user", "content": "..." }],
  "maxTokens": 2000,  "temperature": 1.0,  "stream": false,
  "responseFormat": "markdown"
},
"output": {
  "text": "...",
  "finishReason": "complete",
  "citations": [{ "text": "...", "url": "...", "title": "..." }]
}

8.5 video_generation #

"input": {
  "prompt": "...",
  "image": { "url": "..." },
  "durationSeconds": 10,  "aspectRatio": "16:9",
  "resolution": "1080p",  "fps": 24,
  "motionIntensity": "medium",  "cameraMotion": "static"
},
"output": {
  "video": { "url": "...", "format": "mp4", "width": 1920, "height": 1080,
             "durationMs": 10000, "fps": 24, "fileSizeBytes": 8400000 },
  "thumbnail": { "url": "...", "timestampMs": 500 }
}

8.6 code_generation #

"input": {
  "prompt": "...",  "language": "python",
  "context": "...",  "framework": "fastapi",
  "includeTests": false,  "includeComments": true,
  "styleGuide": "pep8"
},
"output": {
  "code": "...",  "language": "python",  "explanation": "...",
  "files": [{ "filename": "main.py", "content": "...", "language": "python" }],
  "dependencies": [{ "name": "fastapi", "version": "^0.110.0" }]
}

9. Workflows & Chaining #

AIX supports chaining multiple tasks. The output of one step becomes the input of the next via ${step_id.output.field} variable substitution.

{
  "aix": "2.2",
  "workflow": {
    "id": "uuid",
    "name": "Research → Write → Synthesize Voice",
    "steps": [
      {
        "id": "step_research",
        "task": { "type": "text_generation", "provider": "anthropic" },
        "input": { "prompt": "Research AI agents replacing knowledge workers" }
      },
      {
        "id": "step_article",
        "task": { "type": "content_authoring", "provider": "anthropic" },
        "input": {
          "researchPacket": "${step_research.output.text}",
          "contentBrief": { "format": "default", "toneOverride": "contrarian" }
        }
      },
      {
        "id": "step_audio",
        "task": { "type": "voice_synthesis", "provider": "elevenlabs" },
        "input": { "text": "${step_article.output.draft.lede}", "voice": "aria" }
      }
    ]
  }
}

10. Provider Comparison Format #

{
  "aix": "2.2",
  "comparison": {
    "task": { "type": "voice_synthesis" },
    "input": { "text": "Hello, this is a comparison test.", "language": "en-US" },
    "results": [
      {
        "provider": "elevenlabs", "model": "eleven_multilingual_v2",
        "output": { "audio": { "url": "...", "durationMs": 2100 } },
        "meta":   { "cost": { "amount": 0.002 }, "latency": { "totalMs": 650 } }
      },
      {
        "provider": "openai", "model": "tts-1-hd",
        "output": { "audio": { "url": "...", "durationMs": 2080 } },
        "meta":   { "cost": { "amount": 0.003 }, "latency": { "totalMs": 580 } }
      }
    ]
  }
}

11. Security & Governance #

11.1 Security #

AIX does not define authentication — this is provider-specific. AIX messages must never contain API keys, passwords, or personal access tokens.

"safety": {
  "flagged": true,
  "categories": { "violence": false, "sexual": false, "hate": false,
                  "selfHarm": false, "dangerous": true },
  "actionTaken": "content_blocked"
}

11.2 Versioning #

11.3 Amendment Process #

To add a new key: (1) propose with full four-part hierarchy and plain-English description; (2) run all six validation tests from §2.6; (3) check for conflicts with §6; (4) add to candidate keys in next minor version draft; (5) upon ratification, move to canonical reference.

Retroactive changes to ratified keys are prohibited. Deprecation is handled by adding a replacement key and marking the old key [DEPRECATED] in the registry — not by renaming it.

11.4 Governance #

12. Appendix #

A. Provider Registry #

B. Language Codes (BCP-47) #

C. Media Type Mappings #

D. References #

1. Model Context Protocol (MCP) — https://github.com/modelcontextprotocol
2. Eden AI APIs — https://github.com/edenai/edenai-apis
3. Schema.org — https://schema.org
4. JSON Schema — https://json-schema.org
5. BCP-47 Language Tags — https://www.rfc-editor.org/info/bcp47
6. CrossARM Data Interchange Standard (2014) — Ubertrends LLC (internal)

E. Implementation Notes (Non-Normative) #

This appendix is non-normative. Nothing here adds requirements to the AIX standard. Material here documents staging patterns, migration sequences, and operational guidance that implementers have found useful. When the spec body and this appendix appear to disagree, the spec body governs.

E.1 Section 3.5 Media Collections — Single-Primary Subset Pattern #

AIX-compliant implementations MAY ship a single-primary subset of media[] before supporting the full array. The subset stores one Medium object (the primary one) and applies Resolution Rule Step 2 directly. The full array is purely additive: a later upgrade adds the array shape without breaking the subset implementation.

The Solo Trillion Orchestra reference implementation uses this staging pattern — single-primary subset at beta launch (May 2026), full array post-beta.

E.2 Module Manifest — Staged Rollout #

Module manifests MAY omit optional fields (billing, permissionScopes) on initial implementation. Required fields for a v1 manifest: aixVersion, moduleId, moduleType, version. Add optional fields in subsequent releases.

E.3 writingAgent_format_* Migration Guide #

Implementations using writingAgent_documentType_* keys should migrate as follows: - writingAgent_documentType_article_* → writingAgent_format_default_* - writingAgent_documentType_fieldGuide_* → writingAgent_format_default_* - writingAgent_documentType_meetingBrief_* → writingAgent_format_meetingBrief_* - All other documentType keys → corresponding format key (name maps directly)

Both key sets resolve identically during the transition. Remove deprecated keys after confirming all consumers have migrated.

13. Changelog #

Version 2.2 — May 2026 #

Minor version: additive. Formalizes module manifest hierarchy, deprecates documentType object segment in favor of format, adds slug/URL casing exception, adds Published Works field registry, and ratifies UMA Platform and FutureSight Studio canonical keys.

Version 2.1 — April 2026 #

Minor version: additive. Introduces Media Collections standard, Agent Behavioral Modes standard, and Soul Document specification.

Version 2.0 — March 2026 #

Major version: merges AIX Interchange Format Specification and AIX Naming Convention Standard into a single authoritative document.

Version 1.1 — February 2026 #

Version 1.0 — December 2025 #

Initial specification. Core task types: text, voice, image, video, code. Metadata schema with cost/latency tracking. Workflow chaining support. Provider comparison format.

Apache 2.0 Licensed · aix-standard.org · github.com/aix-standard/aix-spec · aix@ubertrends.com · Copyright 2026 Michael Tchong, Ubertrends LLC