AENET.cloud PUBLIC GATEWAY
K.PUBLIC.GATEWAY
ENไทย中文
use-cases K.PUBLIC.USE_CASES

USE CASES

What can AENET do?

Evidence-backed use cases for the AENET ecosystem: what each one solves, who it is for, how the workflow moves through the systems, and its current availability.

Every use case below is written only from public repository evidence. If the evidence is not enough, the page says so — AENET never invents capability claims.

A public, honest development queue

ACTIVE — the development queue and the full public development log are live on aenetcloud.com.

Problem it solves

A large build needs a public, auditable record of what is being developed, in which order and in what state — without exposing the private tooling.

Who it is for

Observers, contributors and operators who want to track the AENET build roadmap and progress honestly.

Overview

The development queue is an active, public system: a canonical state machine (DISCOVERED → SPECIFIED → BUILDING → VERIFYING → PREVIEW → RELEASED) recorded in a public snapshot and mirrored by a development log with one entry per gateway version.

Workflow

  1. A work item enters the queue with an explicit state and coordinate
  2. The queue snapshot is published to public-data/development-queue.public.json
  3. Each gateway version is written up in the public development log
  4. Observers track status honestly — no fake progress percentages
  5. Early-access requests join the queue through the only public write path

Systems involved

Related architecture

Evidence

  • knowledge/systems/development-queue.json (status: active)
  • public-data/development-queue.public.json
  • content/development-log/2026-08-16-public-gateway-v0*.md
  • docs/DEVELOPMENT_QUEUE.md

Next step

Read the development log, then request early access. → Early Access

K / KAP language research (evidence-honest)

PARTIAL — KAP contracts are live and validated; K Language internals are honestly marked insufficient-public-evidence.

Problem it solves

A public AI ecosystem needs a way to research and document languages (the K family, KAP contracts) without exposing private repositories or inventing evidence.

Who it is for

Linguists, language researchers and curious readers who want to understand how AENET documents its language work honestly.

Overview

AENET documents two language threads in public: KAP, an active declarative contract style with machine-verified JSON companions in this repository, and K Language, whose internals are honestly marked insufficient-public-evidence because the public repository does not document them.

Workflow

  1. KAP contracts are authored as declarative .kap files (site, navigation, content, traffic)
  2. JSON runtime companions in contracts/ are machine-verified by npm run check
  3. The language contract (contracts/public-language.contract.json) fixes locale behavior
  4. Knowledge blocks record KAP as active and K Language as insufficient-public-evidence
  5. The public side never reads from or writes to the private K Language repository

Systems involved

Related architecture

Related research

Evidence

  • knowledge/systems/kap-language.json (status: active)
  • knowledge/systems/k-language.json (status: insufficient-public-evidence)
  • kap/*.kap + kap/README.md (declarative contracts)
  • contracts/public-language.contract.json (locale contract)

Next step

Read the KAP Language system detail, then the research observation model. → Early Access

Local AI and model routing (private, documented)

PRIVATE — the model router, agent runtime and spine are private systems; public evidence is limited to the knowledge model.

Problem it solves

An AI ecosystem needs a router that sends each request to the right model — but today the model router is private, so public evidence only documents its design.

Who it is for

AI builders evaluating AENET's routing and inference architecture.

Overview

The AENET Model Router is the private system responsible for routing requests to the right model. It is documented in the public knowledge model as a private system — public evidence covers its role, inputs and outputs, not live behavior.

Workflow

  1. A request arrives at the model router (private)
  2. The router selects the target model based on the request
  3. The agent runtime executes the task with the selected model
  4. Results flow through the spine (private)
  5. Only sanitized knowledge about this flow is public — never live data

Systems involved

Related architecture

Related research

Evidence

  • knowledge/systems/aenet-model-router.json (status: private)
  • knowledge/systems/aenet-agent-runtime.json (status: private)
  • ARCHITECTURE.md — private core separation
  • SECURITY.md — public side never reaches private systems

Next step

Read the system detail for the model router, then the architecture data flow. → Early Access

Multi-agent software engineering (architecture, not live)

PRIVATE — agent runtime, core, spine and model router are private; no public execution evidence exists yet.

Problem it solves

Complex builds need multiple specialized agents working together — but AENET's agent runtime and core are private, so public evidence documents the architecture, not live runs.

Who it is for

AI builders and researchers studying multi-agent orchestration.

Overview

AENET documents an agent runtime, core, memory and spine as private systems that orchestrate specialized agents. Because they are private, the public layer only shows their roles, boundaries and dependencies — never fake execution numbers.

Workflow

  1. A build goal is decomposed into agent tasks (private core)
  2. Specialized agents execute with the agent runtime (private)
  3. Model routing selects the right model per task (private)
  4. Memory and spine coordinate state (private)
  5. The public side receives only sanitized knowledge and snapshots

Systems involved

Related architecture

Evidence

  • knowledge/systems/aenet-agent-runtime.json (status: private)
  • knowledge/systems/aenet-core.json (status: private)
  • knowledge/systems/aenet-spine.json (status: private)
  • SECURITY.md — no agent surface on the public side

Next step

Read the agent runtime system detail, then the public/private boundary. → Early Access

A public window with a strict private boundary

LIVE — aenetcloud.com serves sanitized snapshots, the Public API v1 and localized pages today.

Problem it solves

An AI ecosystem needs a public presence that can never become an attack surface, a control channel or a privacy leak.

Who it is for

Visitors, partners and operators who need to observe the AENET build without any path into the private core.

Overview

AENET Cloud Public is a live, read-only observation layer: sanitized snapshots, static pages, a bounded Public API v1 and an anonymous traffic channel — all behind a strict one-way boundary that never reaches the private AENET Core.

Workflow

  1. The core exports a sanitized snapshot through the public gateway
  2. The snapshot layer publishes static pages + public-data JSON
  3. The Public API v1 serves read-only endpoints (/api/v1/time, /api/v1/status, …)
  4. Visitors read pages, research and the glossary; anonymous traffic is summarized, never fingerprinted
  5. Nothing from the public side can write to, call or reach the AENET Core

Systems involved

Related architecture

Related research

Evidence

  • PUBLIC_BOUNDARY.md — one-way, snapshot-only, read-only boundary
  • ARCHITECTURE.md — public gateway / private core separation
  • knowledge/systems/aenet-cloud-public.json (status: preview)
  • release/current.json — release 1.0.0-rc2

Next step

Read the architecture, then browse the systems map. → Early Access

Evidence-grounded research and knowledge organization

PARTIAL — the search knowledge model, glossary and KAP Language are active; K Language is marked insufficient-public-evidence.

Problem it solves

Research, language work and system knowledge need to be organized, searchable and evidence-grounded instead of scattered documents.

Who it is for

Researchers, linguists and curious readers who want a searchable, evidence-based knowledge model.

Overview

The public side organizes knowledge as a search model: system blocks with trilingual fields, a relationship graph, a vocabulary and a Go Search Compiler that turns it all into crawlable static pages. KAP Language is active; K Language is explicitly marked insufficient-public-evidence rather than over-claimed.

Workflow

  1. Knowledge blocks (systems, architecture, concepts) are curated from public evidence
  2. The relationship graph is the single source for related systems
  3. The Go Search Compiler validates and renders static, localized pages
  4. Localized pages are not indexed until a translation is complete
  5. Facts without public evidence are marked insufficient-public-evidence — never invented

Systems involved

Related architecture

Related research

Evidence

  • knowledge/systems/kap-language.json (status: active)
  • knowledge/systems/k-language.json (status: insufficient-public-evidence)
  • public-data/search-graph.public.json
  • docs/PUBLIC_SYSTEM_MAP.md · docs/CONTENT_MODEL.md

Next step

Browse the glossary, then read the research index. → Early Access

Every use case below is written only from public repository evidence. If the evidence is not enough, the page says so — AENET never invents capability claims.