CPUX: Cognitive Execution Paths Without Hidden Logic—Logic Through Perception

Abstract

Keybyte Systems, Intentix Lab , Melbourne, [email protected] Supported by AusIndustry Grant IR2405165 __________________________________AbstractModern cloud-native applications distribute business logic across multiple layers: application code, orchestration frameworks, service meshes, and infrastructure configurations. This distribution creates ”hidden logic”—execution rules embedded in infrastructure that are invisible during design and difficult to trace at runtime. We present Intention Space , a computing model built on the CPUX (Common Path of Understanding and Execution) paradigm that consolidates all business logic into explicit, design-time declarations using plain-language state pulses. In our model, Design Nodes (DNs) contain computation while Gatekeepers declare execution conditions as named pulses (e.g., ”payment validated”: Y). The infrastructure provides only mechanical enforcement through an Intention Loop that matches runtime state to Gatekeepers without adding decision logic. We demonstrate that complex workflows—traditionally requiring nested if-then branching and explicit loops—can be expressed as linear CPUX sequences where execution paths emerge from data state rather than code branching. Our Golang implementation shows complete elimination of orchestration code while maintaining full cognitive traceability. Beyond technical innovation, CPUX addresses a critical social computing crisis: the lack of accountability in distributed social platforms. By creating unique, device-level CPUX footprints for every interaction, our model enables verifiable traceability from device identity through user intention to executed action—restoring accountability to social computing while preserving privacy. We argue this separation of intent (CPUX) from enforcement (infrastructure) is essential for building LLM-integrated, auditable, and socially responsible distributed systems.Keywords: CPUX, Intention Space, Design Nodes, Cognitive Computing, Data-Driven Execution, Microservices Architecture, Cloud Computing, LLM Integration, Social Computing Accountability__________________________________1. Introduction1.1 The Hidden Logic ProblemConsider a typical e-commerce order processing system deployed on Kubernetes with Istio service mesh:// order-service/main.go (Business Logic Layer) func ProcessOrder(order Order) error { if order.Amount > 1000 { if err := premiumValidator.Validate(order); err != nil { return retry(premiumValidator.Validate, 3, order) } } else { standardValidator.Validate(order) } // … more branching logic }# k8s/hpa.yaml (Infrastructure Layer) spec: metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 80 # Hidden rule: Scale when CPU > 80%# istio/retry-policy.yaml (Service Mesh Layer) spec: http: - retries: attempts: 3 perTryTimeout: 2s # Hidden rule: Retry 3 times on failureQuestion: What is the complete execution flow for a $1500 order that fails validation on first attempt?Answer: One must read and correlate:Application code (branching logic)Kubernetes manifests (scaling rules)Istio configurations (retry policies)Service mesh observability logs (runtime behavior)This hidden logic distribution creates fundamental problems:Traceability : No single artifact shows complete flowTestability : Must test infrastructure + code interactionsAuditability : Business stakeholders cannot validate logicMaintainability : Changes require coordinating multiple layersLLM Integration : No structured representation for AI reasoningSocial Accountability : Cannot trace interactions to source devices/users1.2 The Core InsightWe observe that traditional computing conflates two distinct concerns:What should happen(business intent)How to make it happen(mechanical execution)Current architectures intertwine these concerns across code, configuration, and infrastructure, making systems cognitively opaque.Our Contribution: We introduce CPUX (Common Path of Understanding and Execution) , a paradigm that separates business intent from infrastructure enforcement:CPUX Structure : Declares all possible execution paths as sequences of Design Nodes (DNs) with plain-language Gatekeeper conditionsInfrastructure : Provides mechanical execution (Intention Loop) that enforces CPUX declarations without adding decision logicDevice-Level Identity : Each CPUX execution tied to unique device fingerprint + user intention, enabling social computing accountabilityResult : Complete business logic is visible in CPUX; infrastructure remains purely mechanical; every social interaction is traceable1.3 Key ContributionsFormal Model : CPUX as cognitive execution contract with Design Nodes, Intentions, Objects, and Pulses as primitive componentsElimination of Hidden Logic : All business decisions visible in design-time CPUX declarations; infrastructure adds zero decision logicPlain-Language State Declarations : Execution conditions expressed as named pulses (e.g., ”inventory confirmed”: Y) enabling business stakeholder review and LLM integrationData-Driven Execution : Runtime branching eliminated from code; execution paths emerge from pulse state matching via SyncTestSocial Computing Accountability : Device-level CPUX fingerprints create unique, traceable identity for every social interaction, addressing the accountability crisis in platforms like Facebook, Twitter, TikTokImplementation & Evaluation : Golang framework code sample with concrete use case demonstrating zero orchestration code while maintaining full traceability1.4 Paper OrganizationSection 2 examines related work. Section 3 presents the PnR computing model and CPUX formalism. Section 4 details the architecture and implementation. Section 5 evaluates our approach through metrics and case studies. Section 6 discusses LLM integration. Section 7 introduces CPUX for social computing accountability—the urgent global need. Section 8 concludes with future directions.__________________________________2. Related Work2.1 Workflow Orchestration SystemsAWS Step Functions [1] and Azure Logic Apps [2] provide visual workflow definition with explicit state machines. However, they:Use proprietary JSON/XML DSLs (not plain language)Embed conditional logic in workflow definitions (still branching)Remain platform-specific (vendor lock-in)Require reading workflow definitions to understand flowCannot trace to device/user identityApache Airflow [3] and Temporal [4] define workflows as code with DAG structures. They improve on step functions ,recoverability but:Business logic still in code (if-then branches)Workflow orchestration separate from executionNo plain-language condition declarationsNo device-level traceabilityCPUX Advantage : All logic in plain-language pulses, platform-agnostic, no explicit branching in declarations, device-level identity for every execution, recoverability built into platform. 2.2 Service Mesh & OrchestrationIstio [5] and Linkerd [6] provide traffic management, retries, circuit breaking. Kubernetes Operators [7] encode reconciliation logic. These systems:Hide business rules in YAML configurationsDistribute logic across mesh config + operator codeFocus on infrastructure concerns (not business flow)Lack unified view of complete execution pathNo user/device attributionCPUX Advantage : Consolidates all execution logic in CPUX; infrastructure config aligned with business intent; device identity integral.2.3 Event-Driven ArchitecturesApache Kafka [8], AWS EventBridge [9] enable event-driven systems with loose coupling. Reactive systems [10] promote message-passing. However:Event flows implicit (must trace message paths)Conditional logic in event handlers (code-level branching)No design-time declaration of all possible flowsNo provenance tracking to source deviceCPUX Advantage : Explicit declaration of all event-driven paths as DN sequences with visible Gatekeepers; device identity in event provenance.2.4 Intent-Based SystemsIntent-Based Networking [11] translates high-level intents to network configurations. Policy-based management [12] separates policy from mechanism. Closest to our work, but:Focus on infrastructure (not application logic)Policies often domain-specific (not general computing)Limited plain-language expressivenessNo user accountabilityCPUX Advantage : General-purpose computing model with full plain-language pulse declarations applicable to any domain; device-level user accountability.2.5 Formal Methods & Model CheckingTLA+ [13], Alloy [14], and Petri Nets [15] enable formal specification and verification. These are powerful but:Require specialized formal notation (high learning curve)Specification separate from implementation (sync problems)Not designed for runtime executionNo social computing traceabilityCPUX Advantage : Declarations are executable; CPUX structure IS the implementation contract; device identity embedded.2.6 Social Computing & AccountabilityBlockchain-based identity [16] and zero-knowledge proofs [17] address digital identity but:Focus on cryptographic primitives (not execution tracing)Don’t integrate with application logicNo cognitive representation of intentFederated social networks [18] (Mastodon, ActivityPub) improve decentralization but:Still lack device-level traceabilityNo structured intent representationCannot prove user intended specific actionCPUX Advantage : First system to integrate device identity, user intention, and execution trace in single cognitive framework.2.7 PositioningCPUX is the first system to combine:Plain-language execution conditions (like Intent-Based Networking)Executable specifications (unlike formal methods)Complete flow visibility (unlike distributed orchestration)Zero hidden infrastructure logic (unique contribution)Device-level social accountability (unique contribution)__________________________________3. The PnR Computing Model3.1 Core Abstractions3.1.1 Pulse: Atomic State UnitA Pulse is the fundamental data unit representing a named state with optional response and trivalence:Pulse = (Name: String, Response: Value, Trivalence: {Y, N, U})Name : Plain-language identifier (e.g., ”payment validated”)Response : Optional value (e.g., transaction ID)Trivalence : Y (yes/true), N (no/false), U (undecided)