docs: add state management section and trim for word count

Adds server-side state management paragraph (Conversations, Prompts,
resource registry, Compaction). Trims K8s Operator section to stay
under 1750-word JOSS limit.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: franciscojavierarceo

paper.md

@@ -1,5 +1,5 @@
 ---
-title: 'OGX: An Open-Source AI Application Server with Pluggable Providers and OpenAI-Compatible APIs'
+title: 'OGX: An Open-Source, Vendor-Neutral Generative AI Application Server'
 tags:
   - Python
   - artificial intelligence
@@ -92,11 +92,13 @@ The Responses API implements server-side agentic orchestration: the inference-to
 
 OGX is extending server-side execution with a Containers API and a Skills API. The Containers API (`/v1/containers`) manages sandboxed execution environments---matching the OpenAI Containers API---enabling models to execute shell commands in isolated Docker, Podman, or Kubernetes containers via a `shell` tool in the Responses API. The Skills API (`/v1alpha/skills`) manages versioned skill bundles that package tools, prompts, and configuration into reusable, composable units. Together, these APIs move code execution and task composition onto the server, extending the same trust-boundary principle that governs retrieval and tool authorization.
 
-For multitenant deployments, OGX provides attribute-based access control (ABAC) that enforces tenant isolation at the retrieval, tool execution, and API routing layers. The security properties of this architecture have been formally analyzed and empirically validated [@arceo2026securing].
+Unlike inference engines and API gateways that treat requests as stateless, OGX manages state natively: the Conversations API persists multi-turn history with tenant-scoped isolation, the Prompts API provides versioned prompt templates, and a resource registry tracks models, vector stores, and files as first-class server objects. A Compaction API summarizes long histories to manage context window limits. This state layer is what makes OGX a complete application server rather than a stateless proxy.
+
+For multitenant deployments, OGX provides attribute-based access control (ABAC) that enforces tenant isolation at the retrieval, tool execution, state management, and API routing layers. The security properties of this architecture have been formally analyzed and empirically validated [@arceo2026securing].
 
 ## Kubernetes Operator
 
-The OGX Kubernetes Operator [@ogxk8soperator] provides declarative, production-grade deployment through the `OGXServer` custom resource. A single CR specifies the distribution, replica count, persistent storage, inference backend, and network policies. The operator manages full lifecycle reconciliation---creation, scaling, updates, and teardown---with support for both vanilla Kubernetes and OpenShift. Key operational features include ConfigMap-driven image overrides (enabling fleet-wide image updates without redeploying the operator), automatic network policy generation per CR, multi-architecture builds (amd64/arm64) with FIPS-compliant images, and quickstart scripts for rapid provider-specific setup. The operator supports shared instances with ABAC isolation, per-tenant namespace isolation, and hybrid topologies.
+The OGX Kubernetes Operator [@ogxk8soperator] provides declarative deployment through the `OGXServer` custom resource. A single CR specifies the distribution, replica count, storage, inference backend, and network policies. The operator manages full lifecycle reconciliation with support for both vanilla Kubernetes and OpenShift, ConfigMap-driven image overrides for fleet-wide updates, multi-architecture builds (amd64/arm64) with FIPS-compliant images, and shared instances with ABAC isolation, per-tenant namespace isolation, and hybrid topologies.
 
 # Example Usage