PnR Computing: A New Model for Intention-Driven Software Architecture

Ever wondered if there's a way to make software components truly understand each other's intentions? Can they communicate through Intentions ? Enter PnR (Prompt and Response) Computing - a novel model that brings intentionality to software architecture. In this article, we'll explore this concept through a practical example: orchestrating a full-stack application startup.

What is PnR Computing?

PnR Computing is built around a few key concepts:

• *Design Nodes, also referred as Design Chunks *: Independent functional units (like microservices, but more flexible)
• Intentions: Purpose-driven messages between components
• Gatekeeper Logic: Conditions that control when components can execute
• Runtime State: Shared understanding through PnR sets

The model works through an IntentionLoop that orchestrates execution based on component readiness and system state.

A Practical Example

Let's build something real: a system that coordinates the startup of a web application stack with:

• MongoDB connection verification
• Node.js API server
• Web client

The Architecture

IntentionLoop (Go)
    │
    ├── MongoDB Checker
    │   └── Status: mongodb_status.json
    │
    ├── Node.js API
    │   └── Status: nodejs_status.json
    │
    └── Web Client
        └── Status: client_status.json

Project Structure

pnr-dev-stack/
├── main.go                 # Domain controller
├── config/
│   └── domain.json        # Domain configuration- please put your -                         |                          # own mongodb connection string here
├── nodes/
│   ├── mongodb/
│   │   └── connection_checker.js
│   ├── api/
│   │   └── server.js
│   └── client/
│       ├── index.html
│       └── app.js
├── runtime/               # Runtime state files
└── scripts/
    ├── check_mongodb.sh
    ├── start_nodejs.sh
    └── start_client.sh

How It Works

1. Domain Configuration

{
    "name": "dev_stack",
    "cpuxs": {
        "stack_startup": {
            "design_chunks": [
                {
                    "name": "mongodb_checker",
                    "gatekeeper": {
                        "system_ready": {
                            "prompt": "Is system ready?",
                            "response": ["yes"],
                            "tv": "Y"
                        }
                    },
                    "flowout": {
                        "mongodb_status": {
                            "prompt": "Is MongoDB connected?",
                            "response": ["yes"],
                            "tv": "Y"
                        }
                    }
                },
                // ... more design nodes (also referred to as design 
                //      chunks)
            ]
        }
    }
}

1. IntentionLoop (Go) The controller that orchestrates the execution:

func (il *IntentionLoop) Execute() error {
    for {
        // Update state from runtime files
        il.updateRTStateFromRuntime()

        allCompleted := true
        anyExecuting := false

        // Check all nodes or design chunks
        for _, chunk := range il.cpux.DesignChunks {
            if chunk.Status != "completed" {
                allCompleted = false

                // Execute if gatekeeper conditions met
                if il.checkGatekeeper(chunk) {
                    il.executeChunk(chunk)
                    anyExecuting = true
                }
            }
        }

        if allCompleted || !anyExecuting {
            break
        }
        time.Sleep(time.Second)
    }
    return nil
}

1. Design Chunks Each component reports its state through JSON files:

// MongoDB checker
async function checkConnection() {
    try {
        await client.connect();
        fs.writeFileSync(
            'runtime/mongodb_status.json',
            JSON.stringify({
                "mongodb_status": {
                    "prompt": "Is MongoDB connected?",
                    "response": ["yes"],
                    "tv": "Y"
                }
            })
        );
    } catch (err) {
        // Handle error
    }
}

Running the Stack

1. Set up the project:

mkdir pnr-dev-stack
cd pnr-dev-stack
# Copy files from repository
go mod init pnr-dev-stack

1. Install dependencies:

cd ../api && npm install express mongodb

1. Make scripts executable:

chmod +x scripts/*.sh

1. Run the stack:

go run main.go

The IntentionLoop will:

1. Check MongoDB connectivity
2. Start the API server when MongoDB is ready
3. Launch the web client when the API is ready

Why This Matters

PnR Computing brings several advantages:

• Clear Intent: Components communicate their purpose and readiness
• Loose Coupling: Components don't need direct knowledge of each other
• State Visibility: System state is always observable
• Natural Coordination: Components execute when conditions are right

Beyond the Example

This model can be extended to:

• Complex microservice orchestration
• Event-driven systems
• Distributed applications
• AI/ML pipeline coordination

The PnR model makes complex system interactions more understandable and maintainable by focusing on intentions and state rather than direct dependencies.

Natural Language Integration and Unique Communication Pattern

What makes PnR Computing particularly exciting in today's AI-driven world is its natural affinity for LLM integration and its unique communication pattern.

LLM-Ready Architecture

The PnR model's use of natural language prompts and responses makes it inherently compatible with Large Language Models. Consider:

• Natural State Representation: PnR states like "Is MongoDB connected?" and responses like "yes" are human-readable and LLM-processable
• Intent Expression: Intentions between components are expressed in natural language, making them perfect for LLM interpretation
• Configuration Generation: LLMs can help generate and validate PnR configurations by understanding system requirements expressed in plain language
• Runtime Analysis: LLMs can analyze runtime states and suggest optimizations or troubleshoot issues by reading the natural language status files

The Power of the 5-tuple Pattern

At the heart of PnR lies a unique communication pattern: the dc-i-o-i-dc 5-tuple (Design Chunk - Intention - Object - Intention - Design Chunk). This pattern is more than just a connection mechanism; it's a fundamental unit of computational intent:

Design Chunk (Emitter) → Intention → Object → Intention → Design Chunk (Absorber)

This pattern creates several powerful capabilities:

1. Reflection Through Objects:

   • Objects act as mirrors, reflecting intentions between design chunks or between Objects akin to light being reflected by objects.
   • The reflection can transform both the intention and its associated PnR set
   • This provides a natural place for LLMs to interpret and modify system behavior

2. State Transformation:
   

   Initial State → Intention A → Object Reflection → Intention B → New State

LLMs can understand these transformations in natural language and help manage complex state changes.

1. Intention Mapping:
   • Objects can map one intention to another based on context
   • LLMs can help define these mappings by understanding the semantic relationships between intentions

Consider this example of LLM integration with our stack:

{
    "design_chunk": "api_server",
    "intention_emit": "Need database connection",
    "object_reflection": {
        "input_intent": "Need database connection",
        "llm_analysis": "Checking if MongoDB is required and ready",
        "output_intent": "Connect to MongoDB"
    }
}

An LLM could:

• Generate appropriate gatekeeper conditions
• Suggest intention mappings
• Monitor system state for anomalies
• Provide natural language explanations of system behavior

This marriage of PnR's structured communication pattern with LLM capabilities opens up exciting possibilities:

• Automated system configuration
• Intelligent runtime adaptation
• Natural language system monitoring
• Self-documenting architectures

The 5-tuple pattern also ensures that even as we integrate AI capabilities, the system maintains:

• Clear boundaries between components
• Traceable state transformations
• Predictable behavior patterns
• Comprehensible system interactions

This combination of natural language understanding and structured communication makes PnR Computing uniquely positioned for the future of software architecture, where AI and traditional computing seamlessly integrate to create more intelligent, adaptable systems.

Bridging Human and Code Intentions: A Unified Model

One of the most powerful aspects of PnR Computing is how it places human intentions and code intentions on the same conceptual plane. This isn't just an implementation detail—it's a fundamental shift in how we think about software architecture.

The Unification of Intentions

In traditional systems:

• Human intentions are often lost in translation to code
• Code intentions are buried in implementation details
• There's a clear divide between "user space" and "system space"

In PnR Computing:

Human Intention → Object ->Code Intention -> Design Chunk → Code Intention -> Object → Human Intention (Through Object State Change)

is structurally identical to:

Code Intention → Object -> Human Intention -> Design Chunk → Code Intention -> Object → Code Intention  (Through further code execute)

This symmetry is profound because:

1. A human user interacting with a UI is a Design Chunk
2. A microservice processing data is also a Design Chunk
3. Both emit and absorb intentions through the same mechanism
4. Both interact with Objects in the same way

Objects as Reality Bridges

Objects in PnR serve a unique dual role:

1. Real-World Representation:

   • A database can be an Object representing persistent storage
   • A UI component can be an Object representing visual space
   • A sensor can be an Object representing physical reality

2. Abstract Concept Materialization:

   • A transaction can be an Object representing a business process
   • A workflow state can be an Object representing system progress
   • A computation result can be an Object representing derived knowledge

Consider this example:

{
    "object": "FoodOrder",
    "physical_reality": {
        "type": "Restaurant_Order",
        "table": 5,
        "items": ["pasta", "salad"]
    },
    "abstract_reality": {
        "state": "in_preparation",
        "workflow": "kitchen_queue",
        "business_rules": ["timing", "allocation"]
    }
}

This Object simultaneously represents:

• A physical reality (actual food being prepared)
• A system reality (order processing state)
• A business reality (workflow rules)

The Developer's Cognitive Space

PnR provides developers with a unique ability to:

1. Visualize System Reality:

   • Objects become tangible entities whether physical or abstract
   • Intentions become visible forces acting on these Objects
   • Design Chunks become clear boundaries of transformation

2. Model Complex Interactions:
   

Human (Design Chunk)
  → "Place Order" (Intention)
    → FoodOrder (Object)
      → "Process Order" (Intention)
        → Kitchen System (Design Chunk)

1. Bridge Multiple Realities:
   • Physical reality (actual food)
   • Digital reality (system state)
   • Business reality (process rules)
   • Human reality (customer experience)

This unified treatment of intentions and objects creates a development environment where:

• Human cognitive models naturally map to system architecture
• Abstract concepts have the same "weight" as physical entities
• System behavior can be reasoned about in human terms
• Complex interactions become visible and manageable

The result is a system where:

• Developers can think in terms of natural intentions
• Users experience natural interactions
• Systems maintain logical consistency
• Reality (both physical and abstract) is accurately represented

This bridge between human cognition and system behavior makes PnR Computing not just a technical architecture, but a cognitive framework for understanding and building complex systems.

Conclusion

PnR Computing offers a fresh perspective on software architecture, making system interactions more intentional and observable. While our example above is simple, the principles can scale to complex distributed systems.

The complete code for this example is available at [https://github.com/spicecoder/pnr-dev-stack ]

Would you like to explore PnR Computing further? Share your thoughts and questions in the comments!

*Note: PnR Computing is an emerging model, and we're excited to see how the community might adapt and enhance it for different use cases.