DEV Community: Swapin Vidya

Building Smaller Graph Neural Networks for Edge Healthcare Systems

Swapin Vidya — Fri, 08 May 2026 22:32:48 +0000

How I explored INT8 quantization, biological graphs, and CPU-only inference using PyTorch Geometric.

Healthcare AI is often discussed in terms of massive cloud infrastructure and expensive GPUs.

But many real-world systems do not operate inside large datacenters.

Small clinics, portable medical systems, rural deployments, and edge diagnostic devices frequently depend on:

low-power CPUs
limited memory
unstable connectivity
compact hardware environments

That raises an important engineering question:

Can graph neural networks become smaller and more deployable without completely losing their predictive behavior?

This project explores that question using biological graph data, Graph Neural Networks (GNNs), and manual INT8 quantization.

The Project

BioGraph-Edge-Quantizer GitHub Repository

The repository focuses on:

biological graph inference
resource-aware deployment
CPU-only execution
model compression
reproducible benchmarking

The system uses:

Python
PyTorch Geometric
GraphSAGE
TorchScript
Laravel API integration

The goal was not to build a “medical AI product.”

Instead, the focus was:

understanding how graph-based AI systems behave under hardware constraints.

Why Graphs Matter in Biology

Many biological systems naturally behave like graphs.

For example:

proteins interact with other proteins
genes regulate other genes
molecular pathways form connected networks

In this project, the graph structure comes from protein interaction relationships inspired by the STRING dataset.

Each node represents a protein.
Each edge represents a relationship or interaction.

The model then attempts a binary node classification task.

Simplified example:

Does this protein belong to a target functional category?
Is this interaction pattern significant?

This is where Graph Neural Networks become useful.

Why Use Graph Neural Networks?

Traditional neural networks process:

images
text
tabular data

But biological systems are highly interconnected.

GNNs are useful because they learn:

relationships
neighborhood behavior
graph structure

This project uses GraphSAGE, which is designed for inductive graph learning.

That means:

the model can generalize to unseen nodes
inference is more flexible for evolving graphs

The Real Problem: Edge Deployment

Most machine learning tutorials stop after:

“The model works.”

But deployment creates a different set of challenges:

memory limits
latency stability
CPU constraints
model size
reproducibility

This project explores:

INT8 weight packing
TorchScript deployment
bounded inference variance
edge-device behavior

What is INT8 Quantization?

Most neural networks store weights using FP32 (32-bit floating point values).

Quantization reduces precision.

Instead of:

32-bit weights

we use:

8-bit integer weights

The tradeoff:

smaller model
lower memory usage
possible accuracy reduction

In this project:

weights were manually converted to INT8
scale factors were stored separately
dequantization happened during inference

The Results

The interesting part was not raw speed.

It was understanding where quantization actually helps.

x86 Laptop Results

Hardware:

Intel i5-10210U
8 GB RAM
Windows 11

Results:

~75% reduction in model size
very small latency improvement
accuracy drop below 1%

That initially seemed disappointing.

But the explanation matters.

Graph neural networks are often:

memory-bound
aggregation-heavy

The bottleneck was not matrix multiplication alone.

It was:

graph traversal
feature movement
neighbor aggregation

ARM Edge Device Results

The same experiment was tested on:

Raspberry Pi 4
Cortex-A72 CPU
4 GB RAM

This time the gains became more noticeable.

Why?

Because smaller devices have:

tighter memory limits
smaller cache capacity
lower memory bandwidth

In those environments:

reduced model size matters more
memory pressure becomes a real constraint

This is an important observation for:

hardware vendors
embedded AI systems
edge healthcare infrastructure

Current System Architecture

The repository currently separates:

ML inference
API infrastructure

ML Layer

Python + PyTorch Geometric

API Layer

Laravel-based gateway

Current flow:

Laravel → Python subprocess → GNN inference → API response

This is intentionally simple for experimentation.

The repository also documents:

subprocess overhead
scalability limitations
future migration plans

Why This Matters for Medical Informatics

Medical informatics is not only about large AI models.

It is also about:

interoperability
infrastructure
reproducibility
deployment reliability
hardware-aware engineering

Even experimental systems benefit from:

deterministic execution
controlled benchmarking
transparent limitations

This project is not a clinical system.
It is a systems-engineering exploration around biological graph inference.

Important Limitations

A good engineering project should clearly state its limitations.

Current limitations include:

limited benchmarking scope
no clinical validation
subprocess overhead
no distributed inference
limited quantization optimization
prototype-level architecture

The project intentionally avoids claiming:

medical accuracy
production readiness
diagnostic capability

Why I Shared This Publicly

I wanted to document:

how edge AI systems behave
where quantization helps
where it does not
how biological graph workloads differ from standard AI pipelines

Many tutorials simplify deployment problems.

But practical ML engineering often involves:

bottlenecks
memory constraints
unstable performance behavior
tradeoffs between accuracy and footprint

Understanding those tradeoffs is valuable for:

developers
researchers
hardware engineers
students entering medical informatics

Repository

GitHub

BioGraph-Edge-Quantizer Repository

Areas Open for Collaboration

I would especially love feedback from people working in:

graph neural networks
embedded inference
medical informatics
edge hardware systems
PyTorch optimization
ONNX / TVM / ExecuTorch
biological network analysis

About the Author

Swapin Vidya

Interested in:

edge AI systems
reproducible ML infrastructure
biological graph computing
hardware-aware inference pipelines
healthcare-oriented systems engineering

GitHub:
Swapin Vidya GitHub

ORCID:
Swapin Vidya ORCID

PeachBot Models Medi: A Deterministic Clinical Input Structuring Layer for Edge AI Systems

Swapin Vidya — Fri, 01 May 2026 14:02:18 +0000

⚠️ Scope & Medical Disclaimer

This repository represents an input understanding layer within the PeachBot system.

It is:

Not a diagnostic system
Not a treatment recommendation system
Not a decision-making engine

This module is responsible only for structuring clinical input into a deterministic format.

Outputs are structured data representations and must not be interpreted as medical advice.

What PeachBot Models Medi Is

PeachBot Models Medi is a clinical input structuring framework.

It converts:

Raw Input (text / speech)
        ↓
Structured Clinical State (JSON)

This structured output is then consumed by the reasoning layer.

Why This Exists

Most systems underestimate input processing:

text → model → output

But real-world input is:

Noisy
Ambiguous
Context-dependent

This layer ensures:

Clean, structured, and validated input before any reasoning occurs.

Role in PeachBot System

User Input
    ↓
PeachBot Models Medi  ← (THIS LAYER)
    ↓
Structured Clinical State
    ↓
PeachBot Core (Reasoning)
    ↑
PeachBot Medical KG (Knowledge)

🔍 CLI Demonstration (Real Output)

Below is an actual run of the system:

Input: "chest pan 5 days"

Output:
{
  "symptoms": [
    {
      "name": "chest_pain",
      "duration": "5 days",
      "present": true
    }
  ],
  "meta": {
    "confidence": 0.8
  }
}

Key observations:

Handles typos (pan → pain)
Extracts duration
Produces structured output
Maintains deterministic behavior

Processing Pipeline

Input
 ↓
Text Cleaning
 ↓
Context Segmentation
 ↓
Symptom Extraction
 ↓
Normalization
 ↓
Negation Detection
 ↓
Attribute Extraction
 ↓
Merge & Validation
 ↓
Structured Output

Core Capabilities

Clinical Language Understanding

Supports patient and clinical phrasing
Handles noisy real-world input

Deterministic Processing

No randomness
Repeatable outputs

Negation Handling (Critical)

"no fever" → correctly interpreted
Segment-aware logic

Attribute Extraction

Captures:

Duration
Severity
Trend

What This Layer Does NOT Do

❌ Diagnosis
❌ Treatment recommendation
❌ Clinical reasoning
❌ Risk scoring

Installation

git clone https://github.com/peachbotAI/peachbot-models-medi.git
cd peachbot-models-medi

python -m venv venv
source venv/Scripts/activate

pip install -r requirements.txt

Run CLI

python -m api.cli

Testing

pytest -v

What Currently Works

Symptom extraction
Negation detection
Normalization
Structured JSON output
CLI interaction

Current Limitations

Limited medical vocabulary coverage
English-only (currently)
Rule-heavy system
Requires tuning for edge deployment

Design Approach

This system is built with:

Deterministic logic
Explainable transformations
Config-driven pipelines
Strict separation from reasoning

Where This Can Be Used (Exploratory)

Clinical preprocessing systems
Edge healthcare pipelines
Structured data extraction
Explainable AI systems

(Exploratory use only)

🤝 Contributing

This module is designed to be extended.

You Can Contribute By:

Improving extraction rules
Expanding normalization maps
Enhancing negation detection
Adding multilingual support

Rules

Keep outputs deterministic
Avoid black-box logic
Maintain strict separation from reasoning

Repository

👉 https://github.com/peachbotAI/peachbot-models-medi

Final Note

This is not an AI that decides.

It is a system that ensures:

Correct input → enables reliable reasoning

Within PeachBot:

Understanding comes before intelligence.

PeachBot Medical KG: A Framework for Structured Clinical Knowledge Engineering

Swapin Vidya — Fri, 01 May 2026 13:47:25 +0000

⚠️ Scope & Medical Disclaimer

This repository represents an early-stage framework for clinical knowledge engineering.

It is:

Not a diagnostic system
Not a treatment recommendation system
Not a complete medical knowledge base

All outputs are structured representations of clinical patterns, not medical advice.

This framework is intended for research, system design, and community-driven knowledge structuring.

What PeachBot Medical KG

PeachBot Medical KG is a framework for building structured, explainable clinical knowledge systems.

It provides:

A schema for representing clinical data
A rule-based structure for encoding patterns
A pipeline to convert knowledge into machine-readable JSON

Think of it as:

A foundation layer for building deterministic, explainable medical knowledge systems.

Why This Exists

Many AI systems in healthcare focus on prediction:

input → model → prediction

But this approach often lacks:

Transparency
Auditability
Explicit reasoning structure

This project explores a different direction:

How to explicitly encode clinical reasoning in a structured, verifiable way.

Core Idea

Instead of predicting outcomes, the framework enables:

Clinical Patterns → Structured Rules → Knowledge Outputs (JSON)

Where:

Inputs = symptoms, signs, investigations
Output = structured knowledge objects
Logic = deterministic and explainable

What This Framework Provides

A structured schema for clinical knowledge
Rule-based pattern encoding
Deterministic knowledge generation
JSON export pipeline
Explainability by design

What This Framework Does NOT Provide

❌ No diagnosis
❌ No treatment recommendation
❌ No machine learning
❌ No real-time patient decision system
❌ No complete medical dataset

Role in the PeachBot System

peachbot-medical-kg → defines structured knowledge
PeachBot Core       → consumes and reasons over it

This separation allows:

Clean system boundaries
Independent evolution of knowledge and execution
Better validation and auditing

Architecture Overview

The framework is organized into:

Schema Layer → defines clinical data structure
Rules Layer → encodes patterns
Builders → utilities to construct rules
Engine → transforms rules into outputs
Exporters → generates structured JSON
Outputs → compiled knowledge artifacts

Repository Structure

schema/     → clinical data models  
rules/      → pattern definitions  
builders/   → rule construction tools  
engine/     → transformation logic  
exporters/  → JSON generation  
outputs/    → generated knowledge  
scripts/    → execution entry points

How to Use This Framework

1. Define Clinical Patterns

Identify structured inputs (e.g., symptoms, signals)

2. Encode as Rules

Use rule definitions to represent relationships

3. Apply Schema

Ensure consistency and structure

4. Generate Knowledge

python scripts/export_medai.py

What Currently Exists

Base schema and structure
Rule definition system
Knowledge generation pipeline
Initial example outputs

What Is Still Missing

Large-scale curated knowledge
Extensive clinical coverage
Validation datasets
Community contributions

Design Philosophy

This framework is built on:

Deterministic logic (no black-box systems)
Explainability by default
Structured, auditable knowledge
Separation of knowledge and execution

Where This Can Be Used (Exploratory)

Clinical knowledge structuring
Explainable AI pipelines
Edge-based healthcare systems
Research in medical reasoning systems

(Not for clinical deployment)

🤝 Contributing

This framework is designed to be community-extendable.

You Can Contribute By:

Adding clinical pattern rules
Improving schema design
Enhancing explainability
Structuring domain-specific knowledge

Contribution Rules

All contributions must:

Be pattern-based (not diagnostic claims)
Include clear explanations
Prefer evidence-backed reasoning
Maintain deterministic logic

Do NOT Contribute

Diagnosis statements
Treatment recommendations
Unverified medical claims
Black-box logic

Repository

👉 https://github.com/peachbotAI/peachbot-medical-kg

Final Note

This is not a finished system.

It is a framework for building structured clinical knowledge systems.

The goal is to enable:

A shared, transparent, and explainable approach to representing clinical reasoning.

Citation

Swapin Vidya. PeachBot Medical Knowledge Graph (Framework), 2026

PeachBot Edge: A Deterministic Edge Execution Engine for Stateful Signal Processing

Swapin Vidya — Fri, 01 May 2026 13:16:57 +0000

⚠️ Scope & Status

This repository represents an early-stage execution engine prototype within the PeachBot system.

Focused on experimentation and system design
Not production-ready
Not a medical or diagnostic system

The goal is to explore how stateful, deterministic systems can operate reliably on edge devices.

What PeachBot Edge Is

PeachBot Edge is the execution layer of the PeachBot ecosystem.

It is designed to:

Process signals locally (edge-first)
Maintain system state over time
Execute structured workflows deterministically

This repo focuses on runtime behavior, not model training or cloud pipelines.

Why This Exists

Most systems rely on:

input → model → output

This works well in controlled environments, but can be limiting when:

Connectivity is unstable
Latency matters
Context must persist over time

This project explores:

How to build a system that processes signals continuously and maintains context locally.

Core Execution Flow

From the current implementation:

Input Signal
    ↓
Signal Classification
    ↓
Context Construction
    ↓
Execution (core modules)
    ↓
State Update (memory + priority)
    ↓
Optional coordination (metadata)

This enables:

Stateful processing
Context-aware execution
Predictable system behavior

Key Components

Runtime Engine

Executes workflows as a graph
Supports conditional routing

Memory Layer

Maintains system state
Applies decay and priority

Signal Layer

Classifies signals (normal / anomaly / critical)
Builds execution context

Safety Layer

Handles failures
Provides fallback mechanisms

Hardware Layer

Adapts execution based on device constraints

Coordination Adapter

Supports metadata exchange across nodes
No raw data transfer

Project Structure

src/
  runtime/        # execution engine
  communication/  # coordination layer
  monitoring/     # logging
  contracts/      # structured inputs

configs/
  config.yaml     # system behavior

tests/
docs/

What Currently Works

Deterministic execution pipeline
Stateful memory updates
Graph-based workflow execution
Config-driven behavior
Testable system components

Current Limitations

Limited real-world deployment
No large-scale benchmarking
Some modules still evolving
Hardware-level optimization is ongoing

Installation

1. Clone Repository

git clone https://github.com/peachbotAI/peachbot-edge.git
cd peachbot-edge

2. Create Virtual Environment

python3 -m venv .venv
source .venv/bin/activate   # Linux/macOS

# Windows (WSL recommended)
# .venv\Scripts\activate

3. Install Dependencies

pip install -r requirements.txt

Run the System

python -m src.main

You should see:

System boot logs
Configuration load
Execution traces

Quick Example (Signal Dispatch)

from src.runtime.graph.executor import GraphExecutor
from src.contracts.payload import SignalPayload

executor = GraphExecutor()

signal = SignalPayload(
    source="sensor_01",
    data={"value": 42},
    priority=1.0
)

result = executor.dispatch(signal)
print(result.state)

Configuration

All behavior is externalized:

runtime:
  timeout: 2

memory:
  decay:
    weak: 0.9
    strong: 0.95

This allows tuning without modifying core logic.

💻 Hardware Compatibility

The system is designed to be hardware-agnostic at the software level.

✔ Tested

Windows (development machine)
CPU-only execution

🔄 Target (Compatible)

Linux edge devices
Raspberry Pi (SBC)
Custom embedded hardware

⚙️ Why It Works

Pure Python runtime
No GPU dependency
Config-driven execution
No cloud requirement

⚠️ Notes

Performance varies by hardware
SBC deployment may require tuning
Optimization is ongoing

Design Approach

This project focuses on:

Edge-first execution
Deterministic processing
Config-driven behavior
Modular architecture

Where This Can Be Used (Exploratory)

Environmental monitoring
Edge analytics pipelines
Real-time alerting systems

(Exploratory directions, not production claims.)

Integration Context

This repo works alongside:

Core → system logic
Deploy → execution control
FILA → coordination

This layer focuses specifically on runtime execution.

Testing

pytest -v

Final Note

This is an execution engine prototype, not a finished AI platform.

The aim is to explore:

How systems can operate reliably, predictably, and locally under real-world constraints.

Contributing

This repository is part of an evolving system, and contributions are welcome—especially from developers interested in edge systems, deterministic execution, and distributed architectures.

Where You Can Contribute

** Runtime & Execution**

Graph execution improvements
Performance optimization (CPU/memory)
Deterministic scheduling

** State & Memory Layer**

Memory decay strategies
Priority tuning models
State validation mechanisms

** Signal & Context Processing**

Signal classification improvements
Context enrichment strategies
Domain-specific signal adapters

** Safety & Reliability**

Fault handling mechanisms
Timeout strategies
Deterministic fallback logic

** Edge & Hardware**

Raspberry Pi / SBC testing
Resource-constrained optimization
Hardware-aware execution tuning

How to Contribute

Fork the repository
Create a feature branch

   git checkout -b feature/your-feature-name

Make your changes
Run tests

   pytest -v

Commit and push
Open a Pull Request

Contribution Guidelines

Keep implementations deterministic (no randomness)
Avoid hardcoded logic → use config-driven design
Maintain edge-first constraints (low memory, no cloud dependency)
Ensure all tests pass before submitting

Repository

👉 https://github.com/peachbotAI/peachbot-edge

Note

This is an early-stage system, so clarity, simplicity, and testability are prioritized over complexity.

If you're unsure where to start, feel free to open an issue or discussion.

Disclaimer

This system does not provide medical decisions or diagnostics.

Outputs should be interpreted as system-level signals or computational results only.

PeachBot FILA: A Lightweight Coordination Layer for Edge Intelligence Systems

Swapin Vidya — Fri, 01 May 2026 12:49:48 +0000

⚠️ Scope & Disclosure

This repository is a limited, open-source subset of the PeachBot system.

It represents the coordination layer (FILA)
It does not include full system implementation
Some components are intentionally simplified or abstracted

The goal is to provide visibility into the structure and design approach, not the complete proprietary system.

What PeachBot FILA

PeachBot FILA (Federated Intelligence Layer) is a lightweight coordination protocol prototype designed for:

Structured communication between edge nodes
Metadata-based coordination (not raw data transfer)
Deterministic, inspectable system behavior

This repository focuses on how distributed components interact, not on model training or inference.

What FILA Is NOT

To avoid confusion, this repo does not:

Implement a full AI system
Perform model training
Replace existing ML frameworks
Expose internal production logic

It is a coordination layer prototype, not a complete platform.

Core Idea

Instead of sending raw data to a central system:

edge node → structured message → coordination layer → response

This enables:

Reduced data movement
Better privacy control
Clear, structured communication

Architecture Overview

The system is structured as:

Node → generates structured metadata
Protocol Layer (FILA) → coordinates communication
System Context → maintains consistency across nodes

Execution Model

Typical flow:

Node produces structured metadata
Metadata is transmitted (not raw data)
Coordination logic evaluates context
System response is generated

Message Format (Simplified)

Example structure:

{
  "node": "PB-ALPHA",
  "signal_type": "temperature",
  "priority": "high",
  "timestamp": 1712345678
}

This ensures:

Predictable communication
Easy debugging
System transparency

Key Characteristics

Deterministic coordination
Metadata-first communication
Minimal data transfer
Edge-compatible design
Inspectable system behavior

What’s Included in This Repo

Protocol structure (simplified)
Message handling examples
Basic coordination logic
Configuration patterns

What’s Intentionally Limited

To protect system integrity:

Full distributed orchestration
Advanced coordination strategies
Internal optimization logic
Production deployment layers

Installation

git clone https://github.com/peachbotAI/peachbot-fila.git
cd peachbot-fila

Setup

python -m venv venv
source venv/bin/activate   # Linux/macOS

Windows

venv\Scripts\activate

Install Dependencies

pip install -r requirements.txt

Run Example

python -m src.main

(Entry points may evolve as the repo develops.)

Testing

pytest

Design Approach

This repo explores:

Protocol-driven system design
Deterministic coordination models
Edge-compatible communication
Modular system architecture

Where This Fits in PeachBot

Within the broader system:

Core → state and decision logic
Deploy → execution and runtime
FILA → coordination and communication

This repo focuses only on the coordination layer.

Future Work (Open Portion)

Improved protocol validation
Better message schemas
Simulation tools for multi-node systems
Documentation and examples

Contributing

Contributions are welcome in areas like:

Protocol design
Distributed systems
Edge communication

👉 https://github.com/peachbotAI
👉

peachbotAI / peachbot-fila

Deterministic, protocol-first federated intelligence layer for edge-native systems using metadata-only coordination.

PeachBot FILA (Federated Intelligence Layer)

Overview

PeachBot FILA is a protocol-first, deterministic, metadata-only coordination layer for edge-native distributed intelligence systems.

It enables multiple edge nodes to share contextual intelligence without sharing raw data.

What FILA Is Not

Not a message broker
Not a distributed system framework
Not federated learning
Not an API wrapper

FILA is a deterministic intelligence coordination protocol.

Core Principles

No Raw Data Transfer
No Centralized Control
No Cloud Dependency
Deterministic Behavior
Protocol-First Design

Architecture

Node A → publish metadata
Node B → publish metadata
System → deterministic sync → global_context

Execution Model

Nodes publish metadata (no raw data)
Messages are validated and hashed
Trust and priority are applied
Temporal decay adjusts influence
Deterministic sync produces global_context

Message Format

{ "version": "1.0", "node": "A", "signal_type": "bio_signal", "priority": "high", "timestamp": 1.0, "hash": "...", "trust": 0.9 }

Edge Compatibility

FILA produces outputs strictly compatible with peachbot-edge:

{ "data": {…

View on GitHub

Final Note

This repository is intended to:

Provide a transparent view of system structure while maintaining separation from proprietary implementation details.

It is best understood as a learning and exploration layer, not a complete system.

PeachBot Deploy: A Prototype Deployment Layer for Edge AI Systems (How It Works + How to Run)

Swapin Vidya — Fri, 01 May 2026 12:38:14 +0000

⚠️ Scope & Status

This repository represents an early-stage deployment and execution prototype for the PeachBot system.

Built for testing and validation
Not production-ready
Under active development

The goal is to explore how edge-based AI systems can be initialized, executed, and monitored with minimal infrastructure.

What This Repo Does

PeachBot Deploy provides a structured way to run an edge AI system using:

Script-based setup
Configuration-driven execution
CLI-based monitoring

It focuses on making systems easy to start, inspect, and iterate on.

CLI Interface (Demo)

The system runs through a lightweight CLI menu where you can:

Run the framework
Replay logs
Configure the system

Live Telemetry View

Once running, the system displays:

Node values and decisions
Status indicators
Signal trends
Anomaly timeline

This demonstrates a working execution loop with observable outputs.

Installation & Initialization

1. Setup Environment

Windows

scripts\start.bat

Linux / macOS

chmod +x scripts/setup.sh
chmod +x scripts/start.sh

./scripts/setup.sh
./scripts/start.sh

2. What These Scripts Do

`setup.sh`

Creates Python virtual environment
Installs dependencies
Installs PeachBot in editable mode

`start.sh` / `start.bat`

Activates virtual environment
Launches PeachBot system

Optional: Manual Setup (Advanced Users)

If you prefer manual control:

# Create virtual environment
python -m venv venv

Activate Environment

# Windows
venv\Scripts\activate

# Linux/macOS
source venv/bin/activate

Install Dependencies

pip install -r requirements.txt

Run the System

python -m launcher.system

Execution Flow (What Happens Internally)

Environment is initialized
Configuration is loaded
System modules are started
Signals are processed
State is updated
Decisions are generated
Telemetry is displayed

What Currently Works

Script-based setup and startup
CLI-driven system control
Real-time telemetry display
Deterministic signal processing
Structured execution flow

Current Limitations

Limited real-world deployment
No large-scale benchmarking
Some modules are still evolving
Hardware integration is partial

Design Approach

This system is built with focus on:

Simplicity (easy to run)
Deterministic behavior
Edge compatibility
Observable system state

Where This Can Be Used (Exploratory)

Environmental monitoring
Edge analytics pipelines
Real-time alert systems

(These are exploratory directions, not production claims.)

Future Improvements

CLI → Web interface
Better configuration management
Integration with PeachBot Core
Deployment automation
Real hardware validation

Contributing

If you're interested in:

Edge AI systems
Deployment pipelines
Real-time processing

👉 https://github.com/peachbotAI/peachbot-deploy

Final Note

This project focuses on a simple question:

How do we reliably start, run, and observe AI systems in constrained environments?

This repository is one step toward answering that.

PeachBot Core: An Early-Stage Edge AI System Prototype (How It Works + How to Run)

Swapin Vidya — Fri, 01 May 2026 11:39:00 +0000

⚠️ Scope & Status

This repository represents an early-stage prototype of an edge-native AI system.

Not production-ready
Not fully benchmarked
Under active development

The goal is to explore how state-driven, edge-first systems can operate in real-world environments with constraints like limited connectivity and latency.

What This Repo Is

PeachBot Core is a Python-based system prototype focused on:

Processing signals locally (edge-first)
Maintaining structured system state
Running iterative decision loops

It is designed as a system architecture experiment, not a finished AI product.

Why This Exists

Many AI systems today depend on:

Cloud inference
Stateless input → output pipelines

This repo explores an alternative:

How can systems operate locally, maintain context, and make decisions continuously?

Core Idea (Simplified)

Instead of:

input → model → output

This system follows:

signals → state → evaluation → decision → update

This allows:

Context retention
Continuous updates
Local decision-making

Architecture Overview

From the current implementation , the system is structured into layers:

1. Interface Layer

Converts raw inputs into structured signals

2. Knowledge Layer

Lightweight rules / domain knowledge
Helps interpret signals

3. Edge Intelligence Layer (SBC Engine)

Maintains system state
Updates state based on signals
Drives decisions

4. Coordination Layer

Logging
Policy checks
Session handling

5. Optional Aggregation (FILA concept)

Structured outputs can be shared
No raw data transfer required

Repository Structure

core/          → core system logic (SBC, coordination)
interfaces/    → input handling
knowledge/     → rules / structured knowledge
models/        → signal processing / edge models
deployment/    → configs and setup
tests/         → basic testing
docs/          → architecture notes

What Currently Works

At this stage, the repo includes:

Basic signal → state processing
Structured decision loop
Modular architecture for extension
Simulated input scenarios

Current Limitations

Important to be transparent:

No large-scale dataset validation
Limited real-world deployment
No performance benchmarking yet
Some modules are placeholders or evolving

How to Run (Basic Setup)

1. Clone the Repository

git clone https://github.com/peachbotAI/peachbot-core.git
cd peachbot-core

2. Create Virtual Environment

python -m venv venv
source venv/bin/activate   # Mac/Linux

# or

venv\Scripts\activate      # Windows

3. Install Dependencies

If requirements file exists:

pip install -r requirements.txt

If not (early-stage repo), install basics:

pip install numpy pandas

4. Run a Basic Module

Depending on structure (example):

python -m core.main

or:

python core/run.py

(Check /core or /deployment folder for actual entry point — this may evolve.)

5. Run Tests (Optional)

pytest

Example Flow (What Happens When You Run It)

Input signals are generated (or simulated)
Signals are structured
Knowledge layer enriches context
State is updated
Decision logic is triggered
Output/log is generated

Where This Could Be Applied (Exploratory)

This prototype is being explored for:

Environmental monitoring
Edge-based analytics
Low-connectivity systems

These are experimental directions, not production deployments.

Engineering Direction

The system is being developed with focus on:

Edge-first execution
Modular architecture
State-based reasoning
Compatibility with constrained hardware

Future Work

Planned improvements include:

Clear execution entry points
Better documentation and examples
Real-world datasets
Benchmarking vs existing approaches
Integration with graph-based models (Edge-GNN direction)

Contributing

If you're interested in:

Edge AI systems
Distributed architectures
Real-time processing

Feel free to explore and contribute.

👉 https://github.com/peachbotAI/peachbot-core

Final Note

This is not a finished system.

It is an engineering exploration into how AI systems can operate reliably outside ideal conditions.

Feedback is welcome.

PeachBot: Building a Distributed Edge Intelligence System (Beyond Models)

Swapin Vidya — Fri, 03 Apr 2026 20:03:08 +0000

⚠️ Scope & Positioning

PeachBot is an early-stage, research-driven hybrid edge AI system designed for real-world, safety-constrained environments.

Not a single model
Not a standalone application
Not a fully autonomous system

It is a multi-layer intelligence architecture where:

Deterministic systems + controlled AI → reliable, auditable decision support

What PeachBot Is

PeachBot is a distributed edge intelligence system designed for domains like:

Healthcare (primary focus)
Environmental monitoring (field validation)
Agriculture
Biological systems

It processes signals directly on-device, maintains system state, and provides structured, explainable outputs.

Think of it as an autopilot for real-world systems—with strict safety constraints and human oversight.

The Problem

Modern AI systems are:

Probabilistic
Hard to audit
Cloud-dependent
Difficult to deploy in real-world environments

In domains like healthcare, this creates a reliability gap.

The Approach

PeachBot introduces a hybrid system:

Signals → Structured State → Deterministic Reasoning → Validated Output

Where:

AI models support perception
Deterministic logic controls decisions
Safety layers enforce constraints

System Architecture (Layered)

PeachBot is built as a modular, multi-repository system:

1. Input Understanding Layer

👉 peachbot-models-medi

Converts raw input → structured clinical state
Handles noise, ambiguity, and normalization
Deterministic preprocessing

2. Knowledge Layer

👉 peachbot-medical-kg

Encodes domain knowledge as structured rules
Explainable and versioned
Acts as system grounding

3. Core Reasoning Layer

👉 peachbot-core

State-Based Computation (SBC)
Deterministic orchestration
Decision logic under constraints

4. Execution Layer

👉 peachbot-edge

Runs system on edge devices
Maintains state
Executes workflows

5. Deployment Layer

👉 peachbot-deploy

Environment setup
Runtime control
CLI + monitoring

6. Coordination Layer

👉 peachbot-fila

Distributed intelligence coordination
Metadata-only communication
No raw data sharing

🔁 System Flow (End-to-End)

Real-world signals
        ↓
Input Structuring (Models Medi)
        ↓
Knowledge Integration (KG)
        ↓
State-Based Reasoning (Core)
        ↓
Edge Execution (Edge Runtime)
        ↓
Validated Output (with safety constraints)
        ↓
Federated Coordination (FILA)

⚙️ Key Design Principles

Deterministic Core

No uncontrolled outputs
Repeatable behavior

Edge-First Execution

Runs locally
Works without constant cloud access

Hybrid AI

AI supports, does not control
Logic remains auditable

Safety-Constrained

Outputs validated before use
Human-in-the-loop

Modular Architecture

Each layer independent
System evolves incrementally

What Exists Today

From current repositories and prototypes :

Working edge runtime (CLI + execution logs)
Structured input pipeline (clinical NLP)
Knowledge graph framework
Deployment scripts
Distributed coordination protocol (FILA)

Current Limitations

Early-stage system
Limited real-world deployment scale
Partial domain coverage
Ongoing optimization

Primary Use Case (Healthcare)

PeachBot is currently focused on:

Real-time clinical monitoring in constrained environments

Capabilities include:

Continuous signal monitoring
Early anomaly detection
Structured summaries for clinicians
Edge-based operation (low latency)

How This Differs from Typical AI

Traditional AI	PeachBot
Model-centric	System-centric
Cloud-dependent	Edge-first
Probabilistic	Deterministic + hybrid
Black-box	Explainable
Stateless	Stateful

Safety & Responsibility

PeachBot is:

A decision-support system
Not an autonomous decision-maker

All outputs:

Are constrained by safety logic
Require human validation
Are auditable and traceable

Research & Direction

PeachBot builds on:

Edge AI
Distributed systems
Biological intelligence models
Federated learning concepts

It is evolving toward:

Distributed cognition systems
Hardware-integrated intelligence
Domain-specific adaptive systems

Contributing

PeachBot is designed as a modular, extensible system.

Areas for contribution:

Edge system optimization
Knowledge structuring
Signal processing
Distributed coordination

Repository Ecosystem

👉 https://github.com/peachbotAI

Final Thought

PeachBot is not trying to build a better model.

It is exploring:

How to build reliable intelligence systems that work in the real world.

Closing Line

Intelligence is not just prediction.
It is structured, constrained, and reliable interaction with reality.

Can Biological AI Run on Edge Devices? Lessons from Protein Networks and Real-World Systems

Swapin Vidya — Sun, 08 Feb 2026 03:42:57 +0000

Most biological AI runs on cloud GPUs.

But biology doesn’t always happen in data centers.

What if advanced biological models could run directly on edge devices?

Why This Question Matters

Modern biology is increasingly computational. From CRISPR to protein–protein interaction networks, researchers rely on machine learning to understand complex biological systems.

The challenge is not just model accuracy — it’s deployment.

Most biological AI pipelines assume:

Centralized cloud GPUs
Stable, high-bandwidth connectivity
Large infrastructure budgets

These assumptions limit real-world adoption, especially in clinical, distributed, or resource-constrained environments.

This motivated my work at the intersection of AI, biology, and edge computing.

Research Insight: Running GNNs at the Edge

In my research paper:

Edge-Based Execution of Graph Neural Networks for Protein Interaction Network Analysis in Clinical Oncology

https://doi.org/10.21203/rs.3.rs-8645211/v1

I explored whether Graph Neural Networks (GNNs) — commonly used for protein interaction analysis — can run efficiently on GPU-enabled single-board computers (SBCs).

Key findings

Stable convergence and inference on edge hardware
Low inference latency (~15 ms)
No dependency on cloud GPUs during execution

This demonstrates that biological graph models are viable at the edge — not just in theory, but in practice.

Why Graph Neural Networks for Biology?

Protein–protein interaction (PPI) data is naturally graph-structured:

Proteins → nodes
Interactions → edges

GNNs allow us to model relationships, not just isolated features — which is critical in systems biology and oncology research.

Code Walkthrough: GNN Inference on an Edge Device

Below is a simplified, representative example showing how a protein-interaction GNN can be executed on an edge device.

This example illustrates deployment patterns, not the full research implementation.

Model Definition (PyTorch + PyG)

import torch
import torch.nn.functional as F
from torch_geometric.nn import GCNConv

class ProteinGNN(torch.nn.Module):
    def __init__(self, in_channels, hidden_channels, out_channels):
        super().__init__()
        self.conv1 = GCNConv(in_channels, hidden_channels)
        self.conv2 = GCNConv(hidden_channels, out_channels)

    def forward(self, x, edge_index):
        x = self.conv1(x, edge_index)
        x = F.relu(x)
        x = self.conv2(x, edge_index)
        return x
Here you go — **clean, properly formatted Markdown** for *only this section*, ready to paste into your Dev.to / Medium article 👇

---

`markdown
This architecture captures interaction patterns between proteins rather than treating each protein independently.

Edge-Aware Model Initialization

`python
device = torch.device("cuda" if torch.cuda.is_available() else "cpu")

model = ProteinGNN(
in_channels=128,
hidden_channels=64,
out_channels=2
).to(device)

model.eval()

This setup:

Runs on GPU-enabled single-board computers (SBCs)
Falls back gracefully to CPU
Removes dependency on cloud infrastructure

On-Device Inference

`python with torch.no_grad(): output = model(node_features.to(device), edge_index.to(device)) predictions = torch.argmax(output, dim=1) `

This inference step:

Executes locally
Produces results in milliseconds
Keeps sensitive biological data on-device

Why Edge Computing Changes Biological AI

From a systems engineering perspective, edge execution offers:

Low latency for real-time biological insights
Privacy preservation by avoiding raw data transfer
Scalability without centralized GPU bottlenecks
Accessibility for smaller labs and clinics

This shifts biological AI from infrastructure-heavy to deployment-ready.

Typical Edge Deployment Architecture

`text [Biological Data] ↓ [Graph Construction] ↓ [GNN Inference on Edge GPU] ↓ [Local Decision / Visualization] ↓ (Optional Cloud Sync) `

Applied Perspective: AI in Biology Beyond Research

Beyond academic work, this direction aligns with applied systems such as AI in Biology at PeachBot:
https://peachbot.in/ai-in-biology

The core idea is simple:
Treat biology as an interconnected system and design AI that runs efficiently on real hardware.

This bridges machine learning, bioinformatics, and embedded systems.

What This Means for Developers

If you’re working in ML, systems, or edge computing, biology is an underrated but powerful application domain.

Key takeaways:

Graph ML is not just for social networks
Edge devices are more capable than we assume
Real impact happens when AI meets physical systems

Closing Thoughts

The future of biological AI is not only about larger models or more data.

It’s about:

Where intelligence runs
How fast insights are delivered
How accessible advanced computation becomes

Biology + AI + Edge computing is not a niche — it’s an emerging frontier.

References

Research paper: https://doi.org/10.21203/rs.3.rs-8645211/v1
AI in Biology: https://peachbot.in/ai-in-biology

Edge AI in Agriculture: A Practical Perspective for Real-World Farming

Swapin Vidya — Sun, 28 Dec 2025 12:42:24 +0000

Artificial intelligence is increasingly being applied in agriculture to improve efficiency, decision-making, and sustainability. While many solutions rely on centralized cloud infrastructure, agricultural environments often present constraints such as limited connectivity, variable conditions, and cost sensitivity.

In this context, Edge AI has gained attention as a practical approach for deploying intelligence closer to where agricultural data is generated.

What Is Edge AI?

Edge AI refers to the processing of data and execution of machine learning models on systems located near the data source, rather than relying entirely on remote servers. In agriculture, this may involve computing systems installed on-site or near fields, greenhouses, or storage facilities.

By handling data locally, these systems can operate independently of continuous internet connectivity.

Why Deployment Context Matters in Agriculture

Agricultural operations differ significantly from controlled industrial or urban environments. Factors such as rural locations, intermittent power, and changing environmental conditions influence how technology can be deployed.

Edge-based processing can help address these constraints by allowing systems to continue functioning during network interruptions and by reducing dependence on constant data transmission.

Typical Applications of Edge AI in Farming

From a general standpoint, Edge AI can support agricultural activities such as:

Local analysis of sensor measurements

Monitoring environmental conditions over time

Generating alerts based on predefined thresholds

Supporting operational decisions at the field level

These applications focus on proximity and responsiveness rather than centralized computation.

Data Handling and Operational Considerations

Processing data closer to its source can reduce the amount of raw information transmitted outside the agricultural environment. This may be relevant for data governance, operational control, and system efficiency.

Local processing also enables selective data sharing, where only summarized or relevant information is transmitted for further analysis or reporting.

Edge and Cloud as Complementary Approaches

Edge AI does not replace cloud computing. Instead, both approaches can work together. Cloud systems may still be used for historical analysis, model updates, or cross-site comparisons, while edge systems handle immediate, location-specific processing.

This division of roles can support both responsiveness and long-term planning.

Broader Trends in Agricultural Technology

As agricultural technology continues to evolve, there is growing interest in solutions that prioritize reliability, adaptability, and scalability. Edge AI is one of several approaches being explored to meet these goals, particularly in environments with infrastructure constraints.

Adoption decisions are typically influenced by local conditions, economic factors, and operational requirements.

Conclusion

Edge AI represents a method of deploying intelligence closer to agricultural operations, offering potential advantages in reliability and responsiveness. While its applications and implementations vary, understanding the general principles behind Edge AI can help stakeholders assess its suitability for different agricultural contexts.