# Akshat Kushwaha — Full Knowledge Base & Writings > building things that didn't get permission to exist. cto @ bits&bytes. Co-founder & Chief Technology Officer at bits&bytes, Advisory Board Member at Boardy, former Jr. Research Engineer at jhana, and previously founded Lexana. Last updated: 2026-09-23 Note: blog posts on this site are drafted with an LLM and reviewed and edited by Akshat before publishing. ## Biography & Entity Profile Akshat Kushwaha is an Indian AI engineer and builder based in Prayagraj, Uttar Pradesh 211001, India, and CTO of bits&bytes, a Section 8 foundation with 12+ active city forks across India. He specializes in latency engineering, LLMOps, FastAPI, on-device AI, semantic caching, and building permissionless community networks. ## Complete Timeline & Trajectory 1. **bits&bytes** (CTO & Co-founder, Nov 2025–Present): Distributed builder network with 12+ active city forks across India, cohort programs, and a registered Section 8 foundation. 2. **Boardy** (Advisory Board Member, Aug 2026–Present): Shaping Boardy Pro for builders. 3. **STEMist Education** (Chapter Lead & Tech Lead, Jan 2026–Apr 2026, Prayagraj): Built local builder chapter at Boys' High School, Prayagraj. 4. **jhana** (Jr. Research Engineer, Nov 2025–Jan 2026, Bengaluru): Built Steno's audio evaluation pipeline, a GPT-4o-mini harness that improved TTFT by 60%+ without meaningful accuracy loss, a selective long-context window manager, and a WhatsApp and voice-note AI IVRS staging pipeline. 5. **Shihaan Tech Global Inc.** (Blockchain / Hyperledger Intern, Jun 2025–Nov 2025). 6. **Lexana** (Founder & CEO/CTO, May 2025–Nov 2025): built a multi-agent legal research platform for Indian case law in one sprint at his nani's place, with no internet. He has since exited; it continued in Nepal under his co-founder. 7. **Hack Club** (Head of Sponsorship, Daydream Lucknow, Jul 2025–Aug 2025). 8. **Subohi Foundation** (Committee Secretary, Apr 2025–Jun 2025): WhatsApp automation API & delegate management. 9. **Sky_Fly Studios** (Cloud Infrastructure Associate, Feb 2024–Jul 2024). 10. **PixelShield** (Interim CTO, May 2023–Sep 2023): Automated dropshipping pipeline. 11. **Graphics Code** (Founder & CEO, Nov 2021–Nov 2022): Design studio founded at age 12 with 30 designers and 500+ orders. ## Verified Core Engineering Systems - **Qenlo**: Embedded vector-search library and durable database core in Rust. Features runtime-detected AVX2 SIMD kernels, portable wgpu GPU compute (DX12/Vulkan, IVF-Flat/SQ8), USearch HNSW integration, compound user/time filters, checksummed immutable WAL durability, and native C/JNI mobile shells. - **HybridMind**: Time-aware local hybrid retrieval engine combining FAISS HNSW, Okapi BM25s, NetworkX directed multigraph, and SQLite WAL with RRF (k=60) fusion and Python SDK. - **Luna Companion**: AI-native menstrual cycle companion with NLP chat logging, adaptive exponential smoothing with population priors, Supermemory v4 persistent memory, and OpenUI cards (Next.js 16, Drizzle ORM, Neon Postgres, Vercel AI SDK). ## Quick answers ### who is Akshat Kushwaha? Akshat Kushwaha (a3ro) is an Indian AI systems engineer from Prayagraj and the co-founder and CTO of bits&bytes. he sits on the advisory board at Boardy, worked as a Jr. Research Engineer at jhana, and founded Lexana. he started building at twelve and mostly works on low-latency AI backends and retrieval systems. ### what is bits&bytes? bits&bytes (gobitsnbytes.org) is a registered Section 8 foundation in India that runs a permissionless builder network. Akshat co-founded it in November 2025 and leads the technical side. it has 12+ active city forks, and each one runs its own hackathons, workshops, and hacker houses without waiting for an institution to sign off. ### what has Akshat Kushwaha built? his main builds are Qenlo, an embedded vector database in Rust; HybridMind, a local hybrid retrieval engine; and Luna, an AI menstrual cycle companion. at jhana he built the audio evaluation pipeline for Steno and a GPT-4o-mini harness that cut time-to-first-token by 60%+. ### what is Qenlo? Qenlo is an embedded vector-search library and durable database core written in Rust by Akshat Kushwaha. it uses runtime-detected AVX2 SIMD kernels, optional wgpu GPU compute, and USearch HNSW indexing with user and timestamp filters. writes go through a checksummed immutable WAL, and it ships C and JNI shells so it can run inside mobile apps. ### how do i contact Akshat Kushwaha? email akshatsingh14372@outlook.com, or akshat@gobitsnbytes.org for anything about bits&bytes. you can book a call at calendly.com/a3ro-dev/let-s-talk, or find him as a3ro-dev on GitHub, @a3rodev on X, and Akshat Singh Kushwaha on LinkedIn. he's based in Prayagraj, Uttar Pradesh, India, so replies land on IST. ## Builds compared | build | what it is | stack | status | key number | | --- | --- | --- | --- | --- | | Qenlo | embedded vector database | Rust, AVX2 SIMD, wgpu, USearch HNSW | active | checksummed immutable WAL + atomic snapshots | | HybridMind | local hybrid retrieval engine | Python, FAISS HNSW, BM25s, NetworkX, SQLite WAL | wip | RRF fusion at k=60 over dense, lexical, and graph ranks | | Luna | AI menstrual cycle companion | Next.js 16, Neon Postgres, Drizzle, Vercel AI SDK | active | adaptive smoothing with population priors, 2.5σ outlier clamp | ## Full Content of Published Notes & Essays --- Title: why i built qenlo URL: https://a3ro.dev/blog/why-i-built-qenlo Published: 2026-09-26T04:38:22.749Z Updated: 2026-09-26T04:44:26.774Z # why i built qenlo it started with a pretty normal question. i was talking to a friend and asked him what vector database he uses. "qdrant," he said. okay, but why exactly? "i mean, it's the best. it has good features, it works locally." and that was it. a perfectly fine answer. but i kept thinking about it after that conversation, because i've been around vector databases for a while now. i found out about them about two years ago and i've spent at least a year and a half working with them since. at this point they show up in almost everything i build. search, memory for agents, retrieval for whatever side project i'm on that week. for me a vector database sits in the same place a normal database does. it's just there, under everything. and for normal databases, i have a favourite. SQLite is the goat. i reach for it every single time i can. it's lightweight, it's one file, it runs inside your app instead of next to it, and it just feels like home. yes, i know sqlite-vec exists. i've seen it. it works. but it doesn't have the coolness in it. it doesn't have that vibe. and when you're going to spend your evenings on something, the vibe is not a small thing. so the question in my head became: why not build one? ## the idea died fast i went down the rabbit hole, and the rabbit hole was deep. a state of the art vector search engine isn't one clever data structure. the serious ones are years of work on approximate indexes, quantization, hand tuned kernels for every CPU instruction set, CUDA for NVIDIA, something else for AMD, something else again for Apple, and a whole zoo of drivers to keep it all running. some of the newer ideas even want you to train a neural network to learn the index, or load a pile of model weights just to decide where your vectors go. i was looking at ten different kernels and a hundred different driver targets, alone, and i thought: ye idea shuru hone se pehle khatam ho gaya. the idea was over before it even started. and honestly, that's usually where these things end. we all have that list of ideas we really wanted to work on and then quietly didn't. this was about to join it. i chose not to let it. ## webgpu the thing that saved it was webgpu. (webgpu is a newer standard for talking to the graphics card. it was designed for browsers, so a web page can run real compute on your GPU, but it isn't stuck in the browser. through `wgpu`, the Rust implementation, the same code runs on Vulkan on Linux and Android, DirectX 12 on Windows and Metal on Macs and iPhones. you write your GPU program once, in a shader language called WGSL, and the library deals with whichever GPU the user actually has.) that changed the math completely. i didn't need ten kernels and a hundred drivers. i needed one shader. the "support every GPU" problem, the one that had just killed the idea, was mostly somebody else's problem now. the second thing that made it possible was being honest about what i was building. i wasn't going to beat qdrant at being qdrant. i didn't need billion vector approximate search across a cluster. i needed the SQLite version of a vector store: embedded, local, one process owns the data, and the results are exact. the first commit went in on 27 august 2026. the same day i committed the first GPU experiment, a 124 line WGSL shader that does an exact, filtered search. ## what qenlo actually is qenlo is a local, embedded vector store. you open a collection from your app, add records, and search them. every record has an ID, a vector, a user ID and a timestamp, and qenlo applies those metadata filters before it ranks anything. so "find the closest notes, but only this user's, only from last week" doesn't search everything and throw most of it away afterwards. the design decision i care most about is that indexes are disposable and your data is not. there's one canonical store on disk with checksummed snapshots, a write-ahead log, and a generation number that says which version of the data is published. the CPU search, the GPU buffers, the optional USearch HNSW index and the optional PyTorch tensor path are all derived from that store. if any of them breaks or goes stale, you rebuild it, and the set of records that exist never changes. the default path is plain exact search on the CPU. the GPU path is optional. that ordering is deliberate, and it's where the story got interesting. ## the GPU didn't do what i expected the whole point of webgpu was speed, so i measured it. a lot. the first surprise was that a faster kernel doesn't give you a faster search. before the GPU can do anything you have to filter on the host, copy data over, dispatch the work and read the results back, and for small filtered sets those fixed costs eat the win. so qenlo reports the search call's latency and the GPU's device time separately, because if you only look at one of them you end up lying to yourself. then i tried to be clever. i fit a rule that would decide automatically, per query, whether to send it to the CPU or the GPU. before testing it i wrote down what counted as passing: on a held out set of runs it hadn't seen, the worst case couldn't be more than 25% slower than the best choice. it came out 235.7% slower. so i reverted it and shipped the simpler static routing instead. the failed run is still in the repo, with a script that checks the result, and the script exits nonzero on purpose. the second surprise turned into a paper. i had two GPU paths that return identical results. the light one only touches the rows that pass the filter. the heavy one scans everything. the light one should obviously win. sometimes it did, and sometimes the same query, on the same machine, took up to 4.2 times longer in a fresh process, and up to 4.6 times across cloud machines with the same GPU. the heavy path stayed within 1 to 7%. the reason turned out to be the GPU driver. the light path does so little work that the driver decides the card doesn't need to wake up properly, so it runs at low clocks. on my laptop's RTX 4050 that meant 585 MHz, when the heavy path held full boost. the efficient code was slow because it was efficient. i called the paper "the efficient kernel runs slow", ran it on the laptop, RTX 4090s on six cloud hosts and an H100, and released all the raw data with it. i didn't expect a vector database project to teach me how GPU power governors work. but that's kind of the point. you only find this stuff by building the thing and then refusing to believe your own benchmarks. ## where it is now qenlo is at 0.1.0-alpha.10. it has SDKs for Rust, Python and TypeScript on crates.io, PyPI and npm, preview SDKs for Go, Kotlin and Swift, and a terminal UI for poking at a collection. every evidence file in the research folder is hashed, 1,833 of them, and CI checks the hashes on every push so a number can't quietly change after i've quoted it. it's also alpha, and i want to be clear about the limits. no automatic CPU/GPU router has passed a held out test yet. my CPU numbers don't tell you anything about how optimized CPU libraries perform. GPU support depends on your driver. mobile packaging isn't finished. and a collection is a small folder rather than a single file, so it isn't quite SQLite yet, even if that's the feeling i'm after. it's not a qdrant replacement either. if you need replication, a hosted service, or billions of vectors, use qdrant. my friend's answer was correct. it's just that the next time someone asks me what vector database i use, i'd like to answer with one i understand all the way down to the clock speed. --- --- Title: architecting motherboard: polymorphic iam, forensic digital signatures, and operations at teen-builder scale URL: https://a3ro.dev/blog/architecting-motherboard Published: 2026-08-20T16:00:00.000Z Updated: 2026-08-20T16:47:18.814Z # architecting motherboard: polymorphic iam, forensic digital signatures, and operations at teen-builder scale when you run an independent builder network across a dozen Indian cities with hundreds of teenage hackers, off-the-shelf SaaS tools fall apart surprisingly fast. the official reason people buy twelve different enterprise subscriptions is “operational efficiency.” the more honest reason is that nobody wants to write the glue code. but when you are a registered Section 8 non-profit operating on a shoestring budget, paying $25 per user per month for identity, signature workflows, scheduling, and contract triage is financial suicide. worse than the cost is the fragmentation. your community lives on Discord, your city leads track events in Notion, your banking runs through RazorpayX, and your legal agreements need to hold up under Indian court admissibility. when those systems don't talk to each other, volunteers spend half their week copy-pasting UUIDs and chasing signatures instead of shipping code. so we built **Motherboard** (`bnb-motherboard`). it started as an internal operations hub for the bits&bytes network ([gobitsnbytes.org](https://gobitsnbytes.org)). over 56 development sessions and 190+ automated tests, it evolved into a full operational core: a hybrid monorepo coupling a Python FastAPI backend with a Next.js 15 cockpit dashboard, powering polymorphic IAM, Discord guild synchronization, Cal.com scheduling with native MIME calendar RSVPs, an automated contract review assistant, and an end-to-end digital signature engine built for statutory compliance under Indian law. ```ascii [ Discord OAuth / NextAuth v5 ] │ ▼ ┌──────────────────────────────────[ Next.js 15 Web Cockpit ]──────────────────────────────────┐ │ - Neobrutalist UI (@bnb/ui) - Interactive IAM Visualizer - Stats for Nerds (Latency) │ │ - Signature Canvas (Draw/Type/DSC) - Chrono v2 Availability Grid - Deep AI AgentOps Drawer │ └──────────────────────────────────────────┬───────────────────────────────────────────────────┘ │ REST / Bearer JWT / Signed HMAC ▼ ┌───────────────────────────────────[ FastAPI Backend (uv) ]───────────────────────────────────┐ │ │ │ ┌───────────────────────┐ ┌───────────────────────┐ ┌───────────────────────────────┐ │ │ │ Polymorphic IAM │ │ bnb-signatures │ │ Chrono v2 & Meetings │ │ │ │ - can() / batch_can │ │ - PyMuPDF 150 DPI │ │ - RFC-2446 Multipart Email │ │ │ │ - ix_grants_princ. │ │ - Class 3 DSC + OTP │ │ - Async SQL Batching (<50ms)│ │ │ │ - Non-committing Log│ │ - SHA-256 Audit Seal│ │ - Gemini Fallback Diarizer │ │ │ └───────────┬───────────┘ └───────────┬───────────┘ └───────────────┬───────────────┘ │ │ │ │ │ │ │ ┌───────────▼───────────┐ ┌───────────▼───────────┐ ┌───────────────▼───────────────┐ │ │ │ Contract Assistant │ │ Paper Finance Ledger│ │ Provisioning Worker │ │ │ │ - 35 OKF Rules │ │ - Integer Paise Math│ │ - Discord Role Mapping Sync │ │ │ │ - SparkCloud Diff │ │ - Double-Entry Log │ │ - APScheduler Periodic Sync │ │ │ └───────────────────────┘ └───────────────────────┘ └───────────────────────────────┘ │ └──────────────────────────────────────────┬───────────────────────────────────────────────────┘ │ SQLAlchemy 2.0 (asyncpg) ▼ [ PostgreSQL 16 (Docker) + Redis 7 ] ``` --- ## the hybrid monorepo: bun on the outside, uv on the inside most monorepos pick one language and force everything into it. if you pick TypeScript everywhere, you end up writing clumsy Python subprocesses for cryptographic PDF manipulation and AI diarization pipelines. if you pick Python everywhere, you give up modern React Server Components, streaming UI, and fluid animations. we structured Motherboard as a **hybrid monorepo**: - **Frontend (`apps/web`, `packages/ui`)**: Bun-managed Next.js 15 App Router with React 19, Tailwind CSS, Framer Motion, and custom neobrutalist components. - **Backend (`apps/api`)**: Python 3.12 managed with Astral's `uv`, running FastAPI, SQLAlchemy 2.0 with `asyncpg`, Alembic migrations, and Pydantic v2. - **Shared packages & plugins (`packages/ui`, `plugins/*`)**: dynamic plugin SDK allowing first-party and city-fork tools to register isolated routes and UI panels. > [!NOTE] > Turborepo orchestrates the workspace root, but we enforce strict boundary isolation: TypeScript never imports Python backend code directly, and the backend never depends on Node runtime quirks. the two communicate exclusively across a typed OpenAPI contract and authenticated REST/WebSocket boundaries. --- ## polymorphic IAM and sub-millisecond policy evaluation access control in distributed community organizations is messy. you have global executive leadership, city fork leads (e.g. Delhi, Bengaluru, Kolkata), technical track contributors, and temporary event volunteers. most access management libraries force you into one of two traps: 1. **rigid role-based access control (RBAC)**: you create dozens of hyper-specific roles like `delhi_tech_lead_reviewer`, which leads to role explosion. 2. **over-engineered graph ABAC**: you evaluate graph queries on every request, which destroys API latency. Motherboard uses **polymorphic grants with composite index lookups**. instead of duplicating foreign keys across separate `user_grants` and `group_grants` tables, the `grants` table links to principals polymorphically: ```python class Grant(Base): __tablename__ = "grants" __table_args__ = ( # Fast composite lookup: all grants for a specific principal Index("ix_grants_principal", "principal_type", "principal_id"), ) id: Mapped[uuid.UUID] = mapped_column(UUID(as_uuid=True), primary_key=True, default=uuid.uuid4) principal_type: Mapped[str] = mapped_column(String(20), nullable=False) # 'user' | 'group' principal_id: Mapped[uuid.UUID] = mapped_column(UUID(as_uuid=True), nullable=False) permission_key: Mapped[str] = mapped_column(String(150), ForeignKey("permissions.key", ondelete="CASCADE"), index=True) resource_scope: Mapped[str | None] = mapped_column(String(255), nullable=True) # e.g. 'fork:delhi', null = global expires_at: Mapped[datetime | None] = mapped_column(DateTime(timezone=True), nullable=True) ``` ### 1. Principal Resolution & Policy Evaluation when a request arrives, the `resolve_principal` dependency resolves the user's active group memberships in a single query: ```python async def resolve_principal(db: AsyncSession, user_id: uuid.UUID) -> ResolvedPrincipal: user = await db.get(User, user_id) if not user or not user.is_active: raise HTTPException(status_code=401, detail="User deactivated or invalid") group_ids = ( await db.scalars( select(Membership.group_id).where( Membership.user_id == user_id, or_(Membership.expires_at.is_(None), Membership.expires_at > datetime.now(timezone.utc)) ) ) ).all() return ResolvedPrincipal(user_id=user.id, group_ids=list(group_ids), is_super_admin=user.is_super_admin) ``` ### 2. The `batch_can()` Optimization evaluating permissions on a list of 50 resources (like city forks or pending signature requests) usually causes an $N+1$ query loop. we built `batch_can` to resolve permissions across arbitrary resource lists in a single SQL execution: ```python async def batch_can( db: AsyncSession, principal: ResolvedPrincipal, checks: list[tuple[str, str | None]] # [(permission_key, resource_scope), ...] ) -> dict[tuple[str, str | None], bool]: if principal.is_super_admin: return {check: True for check in checks} now = datetime.now(timezone.utc) keys = {c[0] for c in checks} principal_filter = or_( and_(Grant.principal_type == "user", Grant.principal_id == principal.user_id), and_(Grant.principal_type == "group", Grant.principal_id.in_(principal.group_ids)) if principal.group_ids else False ) stmt = select(Grant).where( principal_filter, Grant.permission_key.in_(keys), or_(Grant.expires_at.is_(None), Grant.expires_at > now) ) grants = (await db.scalars(stmt)).all() # Match in-memory: exact resource match OR global wildcard (resource_scope is None) results = {} for perm_key, scope in checks: allowed = any( g.permission_key == perm_key and (g.resource_scope is None or g.resource_scope == scope) for g in grants ) results[(perm_key, scope)] = allowed return results ``` --- ## bnb-signatures: legally binding digital signatures under Indian law one of the most critical systems in Motherboard is `bnb-signatures`—our custom digital contract execution and verification engine. as a Section 8 non-profit company in India, our agreements with college chapters, venue sponsors, hackathon partners, and city leads cannot be casual checkboxes. they have to satisfy the **Information Technology Act, 2000** and the **Bharatiya Sakshya Adhiniyam, 2023 (BSA)** / Section 65B of the Indian Evidence Act. ```ascii [ Upload Document (PDF/DOCX) ] ──> [ PyMuPDF Rasterizer (150 DPI Canvas Preview) ] │ ▼ [ Interactive Drag & Drop Field Placement ] │ ▼ [ Multi-Stage Recipient Signing ] ┌─────────────────┴─────────────────┐ ▼ ▼ [ 6-Digit Email OTP Challenge ] [ Class 3 Hardware DSC / PFX Seal ] └─────────────────┬─────────────────┘ │ ▼ [ PyMuPDF Vector Overlay + ReportLab Certificate ] │ ▼ [ Immutable SHA-256 Tamper-Evident Digest Sealing ] │ ▼ [ Public Drag-and-Drop Verification Portal ] ``` ### statutory validity requirements we implemented: 1. **Section 10A IT Act, 2000 (Electronic Formation of Agreements)**: contracts formed electronically via offer, acceptance, and digital intent are legally valid and enforceable in Indian courts. 2. **Section 65B Evidence Act / Section 63 BSA 2023 (Forensic Tamper-Evidence)**: every executed contract generates an append-only cryptographic audit trail recording exact UTC timestamps, verified email addresses, signatory IP addresses, browser user-agents, and intermediate document digests. 3. **Class 1, 2, 3 Digital Signature Certificate (DSC) Support**: support for hardware cryptographic USB tokens (ePass2003, mToken, HYP2003 via PKCS#11) and software `.pfx` / `.p12` certificates validated against X.509 certificate chains using Python's `cryptography` library. 4. **Two-Stage Email OTP Challenge**: automated 6-digit verification codes sent to signatory mailboxes with a 2-minute time-decay window, rate-limiting, and masked challenge display (e.g. `ak*******@g****.com`). ### cryptographic document sealing when all parties execute the document, the backend combines the signature layers, attaches a tamper-evident audit certificate, and computes a SHA-256 digest: ```python def seal_document(original_pdf_bytes: bytes, overlays: list[FieldPlacement], audit_trail: list[AuditEntry]) -> tuple[bytes, str]: doc = fitz.open(stream=original_pdf_bytes, filetype="pdf") # 1. Overlay signatures, typed script text, and timestamps at precise canvas coords for field in overlays: page = doc[field.page_number - 1] rect = fitz.Rect(field.x0, field.y0, field.x1, field.y1) if field.type == "signature_image": page.insert_image(rect, stream=field.image_bytes) elif field.type == "text": page.insert_text(rect.tl, field.value, fontsize=10, fontname="helv") # 2. Append 1-page forensic Audit Certificate generated via ReportLab cert_pdf = generate_audit_certificate_pdf(audit_trail) cert_doc = fitz.open(stream=cert_pdf, filetype="pdf") doc.insert_pdf(cert_doc) # 3. Serialize and calculate immutable SHA-256 digest final_bytes = doc.tobytes(deflate=True, garbage=3) document_hash = hashlib.sha256(final_bytes).hexdigest() return final_bytes, document_hash ``` > [!IMPORTANT] > The public verification portal (`/verify`) lets any external counterparty, university administration, or court officer drag-and-drop a PDF. the client computes the SHA-256 hash locally in WebCrypto and verifies it against the registered database seal without exposing unexecuted drafts. --- ## contract assistant: deterministic rules before LLM judgment before a legal partnership agreement or university MOU gets dispatched for signatures, it passes through the **Contract Assistant**. throwing an raw LLM at an entire contract is an easy way to hallucinate terms or miss dangerous indemnification clauses. we structured the analysis pipeline as a **two-tier evaluation engine**: | Evaluation Layer | Mechanism | Purpose | | :--- | :--- | :--- | | **Tier 1: Deterministic OKF Rules** | 35 regex patterns & structural AST matchers | Checks mandatory Section 8 non-profit clauses (e.g. zero personal liability for student organizers, non-commercial IP retention, jurisdiction pinned to Uttar Pradesh courts). | | **Tier 2: SparkCloud LLM Risk Pass** | Bounded context prompt with clause classification | Analyzes fuzzy ambiguity, non-standard penalty clauses, and unilateral termination traps. | ```python class ContractAssistantFinding(Base): __tablename__ = "ca_findings" id: Mapped[uuid.UUID] = mapped_column(UUID(as_uuid=True), primary_key=True, default=uuid.uuid4) contract_id: Mapped[uuid.UUID] = mapped_column(UUID(as_uuid=True), ForeignKey("ca_contracts.id", ondelete="CASCADE")) clause_ref: Mapped[str] = mapped_column(String(50)) # e.g., "§4.2" source: Mapped[str] = mapped_column(String(50)) # "rule_engine" | "llm_judgment" severity: Mapped[str] = mapped_column(String(50)) # "high" | "medium" | "low" risk_type: Mapped[str] = mapped_column(String(100)) plain_english: Mapped[str] = mapped_column(Text) suggested_action: Mapped[str] = mapped_column(Text) tier: Mapped[int] = mapped_column(Integer, default=1) # 1 = Template swap, 2 = LLM redline status: Mapped[str] = mapped_column(String(50), default="open") ``` if any `high` severity findings remain unresolved (like an uncapped indemnification clause), the dashboard disables the "Dispatch for Signature" trigger until an executive admin either applies the suggested template fix or logs a formal justification reason. --- ## chrono v2 & meetings: eliminating the $N+1$ query bottleneck Motherboard consolidates community scheduling, Cal.com sync, and Discord voice channel recordings into a unified system called **Chrono v2**. in earlier iterations, loading the meetings index page was shockingly slow. a user with 40 scheduled meetings was taking upwards of **10.5 seconds** to load. when we profiled the SQLAlchemy query logs, we found the classic ORM disaster: for every single meeting, the system executed separate queries to fetch attendees, reschedule history records, and transcript metadata ($40 \times 3 + 1 = 121$ sequential database roundtrips). ### the batch loading fix we rewrote the `/api/meetings` index router to batch-fetch all child relationships across three indexed `IN` queries: ```python # 1. Fetch root meetings meetings = (await db.scalars(select(BotMeeting).order_by(BotMeeting.scheduled_time.desc()).limit(limit).offset(offset))).all() meeting_ids = [m.id for m in meetings] if meeting_ids: # 2. Batch fetch child records in exactly 3 queries attendees_res = await db.scalars(select(MeetingAttendee).where(MeetingAttendee.meeting_id.in_(meeting_ids))) history_res = await db.scalars(select(MeetingRescheduleHistory).where(MeetingRescheduleHistory.meeting_id.in_(meeting_ids))) transcripts_res = await db.scalars(select(MeetingTranscript).where(MeetingTranscript.meeting_id.in_(meeting_ids))) # 3. Map into memory dictionaries attendee_map = defaultdict(list) for a in attendees_res: attendee_map[a.meeting_id].append(a) history_map = defaultdict(list) for h in history_res: history_map[h.meeting_id].append(h) transcript_map = {t.meeting_id: t for t in transcripts_res} ``` > [!TIP] > This single batching refactor collapsed database roundtrips from **120+ queries down to 4 queries**, dropping p95 response times from **10,400ms down to 42ms**—a **99.6% latency reduction**. | Metric | Legacy ORM Fetch | Chrono v2 Batch Fetch | Improvement | | :--- | :--- | :--- | :--- | | **SQL Queries / Page** | $3N + 1$ (121 queries for $N=40$) | **4 fixed queries** | **96.7% fewer queries** | | **p95 API Latency** | 10,420ms | **42ms** | **99.6% faster** | | **DB CPU Load** | 78% during meeting spikes | **< 3%** | **Massive compute savings** | ### native RFC-2446 email calendar RSVPs when scheduling a community sync or council review, sending a plain text email means users forget to manually create a calendar event. we updated Motherboard's mailer to construct **multipart/mixed MIME messages** containing an inline `text/calendar; method=REQUEST` payload with deduplicated `ORGANIZER` and `ATTENDEE` tags. when Gmail, Apple Mail, or Outlook receives the email, it renders the interactive "Yes / Maybe / No" RSVP buttons natively inside the inbox header. ```text Content-Type: multipart/alternative; boundary="boundary-alternative" --boundary-alternative Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit

Your bits&bytes sync has been scheduled

... --boundary-alternative Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR VERSION:2.0 PRODID:-//bits&bytes//Motherboard Chrono//EN METHOD:REQUEST BEGIN:VEVENT UID:meet-9f8e7d6c5b4a@gobitsnbytes.org DTSTART:20260825T140000Z DTEND:20260825T144500Z SUMMARY:Delhi City Fork Tech Sync ORGANIZER;CN=Akshat Kushwaha:mailto:akshat@gobitsnbytes.org ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:guest@example.com END:VEVENT END:VCALENDAR --boundary-alternative-- ``` --- ## paper finance: integer paise and floating-point discipline managing hackathon logistics and reimbursement requests across cities requires paper ledger tracking before routing through bank current accounts. a common trap is using floating-point types (`Float` or `Double`) for financial balances. in IEEE 754 floating-point representation: $$0.1 + 0.2 = 0.30000000000000004$$ over thousands of micro-transactions, floating-point rounding errors accumulate and create reconciliation mismatches. Motherboard stores all financial values strictly in **integer paise** ($\text{INR } ₹1.00 = 100\text{ paise}$): ```python class VirtualAccount(Base): __tablename__ = "virtual_accounts" id: Mapped[uuid.UUID] = mapped_column(UUID(as_uuid=True), primary_key=True, default=uuid.uuid4) owner_id: Mapped[uuid.UUID] = mapped_column(UUID(as_uuid=True), ForeignKey("users.id", ondelete="CASCADE"), index=True) name: Mapped[str] = mapped_column(String(100), nullable=False) balance_paise: Mapped[int] = mapped_column(Integer, default=0, nullable=False) account_number: Mapped[str] = mapped_column(String(20), unique=True, index=True) ifsc: Mapped[str] = mapped_column(String(11), default="GOBN0001001", nullable=False) ``` every transaction creates a balanced, immutable `VirtualTransaction` entry linking debits and credits, allowing instantaneous mathematical auditing. --- ## lived scar tissue: when the managed database ran out of compute writing about architecture is easy when you only describe the happy path. the reality of building Motherboard involved real operational emergencies. in early August 2026, during a peak onboarding surge for new city chapters, our server logs suddenly lit up with `HTTP 500` errors on `POST /api/auth/upsert`. when we inspected `journalctl` on the VPS, we found: ```text asyncpg.exceptions.InsufficientResourcesError: remaining connection slots are reserved for non-replication superuser connections ``` our managed cloud PostgreSQL tier (Neon) had exceeded its active compute and connection quotas during background Discord member synchronization. because the API depended synchronously on this external database, authentication and dashboard navigation ground to a halt. ### the recovery we didn't wait for cloud support tickets: 1. provisioned a local, persistent Docker container `bnb-postgres` running `postgres:16-alpine` on our primary VPS with dedicated SSD volume mounts. 2. updated the API connection pool configs (`pool_size=20`, `max_overflow=10`, `pool_pre_ping=True`). 3. executed Alembic migrations (`alembic upgrade head`) and ran the seed scripts to restore all 15 system groups, 23 core permissions, and city fork mappings. 4. added an automated database backup cron generating encrypted daily `.sql.gz` snapshots to external object storage. within 45 minutes, services were restored to 100% green health. > [!WARNING] > Relying on external managed database tiers with opaque connection limits for core internal operational tools is a risk. if your authentication path cannot survive a network blip or quota spike, your operations platform is fragile. self-hosting the database engine on dedicated infrastructure with proper WAL replication gave us predictability. --- ## knowing when to build vs when to integrate a major trap for software builders is the urge to reinvent everything. in Session 53, as our community scaled, we asked ourselves an honest question: should we spend the next six months building our own webmail client, document collaboration editor, and video calling infra inside Motherboard? the answer was an emphatic **no**. we integrated a self-hosted **Nextcloud Hub workspace** (`workspace.gobitsnbytes.org`) backed by 5TB of high-speed NVMe storage, Nextcloud Talk for video calls, and an automated background mail provisioner (`bnb_auto_mail_provisioner.py`) that provisions `@gobitsnbytes.org` mailboxes on our Indian mail servers when contributors complete their team profile. Motherboard retained the things it does better than generic software: - our custom **Polymorphic IAM and Discord Guild Role Mapper** - our statutory **Digital Signatures Engine (`bnb-signatures`)** - our **Contract Assistant** and **Section 8 Governance Rules** - our **Chrono v2 Meeting Scheduler** ```ascii ┌────────────────────────────────────────────────────────────────────────┐ │ bits&bytes Operational Core │ └───────────────────────────────────┬────────────────────────────────────┘ │ ┌───────────────────────┴───────────────────────┐ ▼ ▼ [ Specialized Engines: Motherboard ] [ Unified Workspace: Nextcloud ] - Forensic Digital Signatures (IT Act 10A) - 5TB Drive File Storage - Contract Assistant & OKF Rule Passes - Nextcloud Talk Video Syncs - Polymorphic IAM & Discord Role Sync - CalDAV Calendar & Webmail - Integer Paise Paper Accounting Ledger - Deck Kanban Boards for Sprints ``` systems shouldn't be built to satisfy architectural vanity. they should be built to remove friction from the people doing the work. --- ## what holds up building Motherboard taught me that operational platforms aren't defined by how clean their initial schema looks on a whiteboard. they are defined by how they behave when: - an external API changes its schema at 2 AM - an urgent contract needs to be executed on mobile by a signatory with spotty 4G - forty people try to schedule meetings at the same minute - a volunteer needs to verify that an agreement hasn't been tampered with you don't need a team of twenty engineers to build reliable, production-grade infrastructure. you just need to respect data consistency, measure your query latencies, handle failure modes explicitly, and write software that treats its users' time with respect. Motherboard is running in production today across the bits&bytes network at [gobitsnbytes.org](https://gobitsnbytes.org). --- --- Title: why luna needs to exist: adaptive math, memory, and the problem with pink calendar apps URL: https://a3ro.dev/blog/why-luna-needs-to-exist Published: 2026-08-18T12:00:00.000Z Updated: 2026-08-18T16:10:19.444Z # why luna needs to exist: adaptive math, memory, and the problem with pink calendar apps most cycle tracking apps on your phone are insulting. they fall into two categories, and both of them are built on deeply patronizing assumptions about women's bodies. the first category is the pastel calendar. it asks for the first day of your last period, slaps a pink floral theme across the screen, assumes every human body runs on a mechanical 28-day conveyor belt with ovulation on day 14, and calls it a day. if your cycle happens to be 34 days, or irregular, or shifted by stress, travel, or exams, the app just gasps and marks you as "late" with an alarmist red badge. the second category is the clinical surveillance machine. it asks you to fill out twenty dropdown menus every morning—cervical mucus consistency, basal body temperature to two decimal places, mood ratings from one to ten, sleep duration in minutes. it treats you like an unruly lab experiment. you have to do all the cognitive labor of categorizing your own body before the app will give you a generic linear regression. neither of these feels like software built for a real person. > [!IMPORTANT] > Cycle tracking is fundamentally an **adaptive time-series inference problem** paired with a high-friction logging interface. If you fix the math and fix the conversational interface, you don't need the pink sparkles or the clinical questionnaires. i built [Luna](https://github.com/a3ro-dev/luna) because the way technology has historically approached female biology isn't just bad engineering—it is fundamentally misogynistic. ```ascii [ Natural Voice / Freeform Text ] │ ▼ [ Vercel AI SDK Parsing ] ──────> [ Supermemory v4 Persistent Graph ] │ │ ▼ ▼ [ Adaptive Smoother (ACOG + MAD) ] <─── [ Historical Biometrics ] │ ▼ [ Dynamic OpenUI Structured Cards & Honest Prediction Intervals ] ``` ## the systemic misogyny of the 28-day myth for decades, medical science treated the female endocrine system as an inconvenient complication. clinical trials routinely excluded women because hormonal fluctuations were deemed "noisy data" that ruined neat experimental baselines. the entire medical baseline was constructed around a male default, with female biology retrofitted into an idealized, sterile 28-day clock. this is structural gaslighting codified as software. in real-world clinical datasets (like the ACOG population studies), **fewer than 15% of women have a 28-day cycle**. cycle length naturally varies across individuals, across seasons, and across life phases. yet when software forces a static 28-day average, it sends a toxic implicit message: *if your body does not behave like a predictable Swiss watch, you are broken.* legacy apps monetize this anxiety. they flag natural biological variance as "abnormal," induce unnecessary panic, and then mask their mathematical incompetence behind infantilizing pastel gradients and cutesy floral badges. > [!WARNING] > Reducing a complex, multi-phase neuroendocrine rhythm to a rigid arithmetic mean ($N=3$) pathologizes natural biological variance. When software can't model non-linear systems, it blames the user's body instead of fixing its own math. when an app uses a naive arithmetic average, two critical statistical failures occur: 1. **cold starts are useless.** with only one or two logged cycles, sample variance is massive. an unweighted average over two erratic points makes wildly confident predictions that are mathematically indefensible. 2. **outliers corrupt history.** if someone gets sick, travels across four time zones, or has a 50-day cycle due to stress, a naive arithmetic mean gets dragged out for the next six months. ## the mathematical solution: adaptive smoothing + empirical priors Luna replaces rigid patriarchal averages with adaptive exponential smoothing blended dynamically with empirical population priors: $$S_t = \alpha_t Y_t + (1 - \alpha_t) S_{t-1}$$ for cold starts ($n \le 5$), predictions blend the user's few data points with empirical population priors derived from large-scale ACOG distributions: $$\hat{Y}_{t+1} = w_n \cdot S_t + (1 - w_n) \cdot \mu_{\text{ACOG}}, \quad \text{where } w_n = \min\left(1, \frac{n}{5}\right)$$ as more cycles are logged, the weight shifts dynamically and respectfully to the user's personal baseline. > [!TIP] > The smoothing parameter $\alpha_t$ isn't static. It adapts continuously based on the residual Mean Absolute Deviation (MAD): > > $$\text{MAD}_t = \beta |Y_t - \hat{Y}_t| + (1 - \beta)\text{MAD}_{t-1}$$ > > If recent cycles have high variance, $\alpha$ decreases to avoid overreacting to temporary stress or travel. If cycles are stable, $\alpha$ increases to stay responsive. to stop an anomalous 52-day cycle from corrupting the engine, Luna applies **$2.5\sigma$ soft outlier clamping**. values past two and a half standard deviations from the moving median are gently pulled back toward the bound before entering the smoothing state. and when six or more cycles exist, we use jackknife resampling to generate honest confidence intervals ($p_{10}$ to $p_{90}$) instead of pretending software knows the exact minute a period will arrive. | Feature | Legacy Pink Calendars | Clinical Surveillance Apps | Luna Companion | | :--- | :--- | :--- | :--- | | **Philosophical Stance** | Infantilizing / Aesthetic | Surveillance / Extraction | **Feminist / Autonomous / Rigorous** | | **Prediction Engine** | Static 28-day clock | Unweighted 3-mo mean | **Adaptive Exp Smoothing + ACOG Priors** | | **Variance Handling** | Pathologizes as "late" | Manual form exclusion | **Automatic $2.5\sigma$ soft clamping** | | **Data Ingestion** | Rigid date picker | 20+ dropdown forms | **Natural NLP conversational logging** | | **Cross-Session Memory** | None (stateless) | Relational rows only | **Supermemory v4 semantic graph** | | **UI Output** | Static pink calendar | Dense clinical charts | **Dynamic OpenUI generative cards** | ## conversational logging without dropdown fatigue nobody wants to open an app while dealing with cramps, nausea, or a busy workday and navigate through four nested screens to log that their period started a day early and they have a headache. you should be able to type or say: > "my period started yesterday afternoon, heavy flow and bad lower back pain." that's it. Luna parses natural language inputs through the Vercel AI SDK directly into typed cycle events. but the critical piece isn't just one-shot entity extraction; it's persistent contextual memory. > [!NOTE] > Most chat apps wipe their context the moment you close the browser. Luna uses the **Supermemory v4 API** to maintain persistent memory embeddings across sessions. If you mentioned three weeks ago that your luteal phase usually comes with severe migraines, Luna remembers that context when you log mild nausea today. It doesn't force you to re-explain your medical history every time you check in. ## structured UI over chat walls one of the biggest mistakes in modern "AI wrapper" apps is assuming that everything should be a raw markdown chat bubble. a wall of LLM text is an exhausting way to view a calendar, a cycle phase breakdown, or symptom correlations. Luna uses dynamic OpenUI structured components. when the AI reasons about cycle predictions, it emits structured UI schemas that render directly as interactive prediction cards, cycle wheel visualizations, and calendar timeline widgets inside the chat stream. the tech stack is straightforward and fast: - **Next.js 15 (App Router)** for streaming server components. - **Neon PostgreSQL + Drizzle ORM** with 8 normalized tables for cycle logs, symptoms, predictions, and user preferences. - **Tailwind CSS v4 + Framer Motion** for fluid, calm micro-interactions. - **Auth.js v5** with JWT sessions. ## why this matters technology for women's health shouldn't be patronizing. it shouldn't treat cycle tracking as either a nursery game or a hospital triage form. women's bodies are not defective machines that need to be scolded by a pink calendar. they are dynamic, intelligent biological systems deserving of mathematical rigor, radical privacy, and empathetic software that actually listens. Luna is an attempt to build software that is mathematically rigorous on the inside, completely frictionless on the outside, and respectful of the person using it. --- --- Title: architecting lexana at my nani's house: 4-agent swarms, 60% semantic cache hits, and sub-200ms p95 latency URL: https://a3ro.dev/blog/architecting-lexana-at-nanis-house Published: 2026-08-18T10:00:00.000Z Updated: 2026-08-18T16:10:19.997Z # architecting lexana at my nani's house: 4-agent swarms, 60% semantic cache hits, and sub-200ms p95 latency in the summer of 2025, i spent nearly two months at my nani's place in Prayagraj. there was no broadband connection. there was no ergonomic desk or dual-monitor setup. the power cut out twice a day, and the only reliable internet was a 4g mobile with hotspot turned on, kept on the second-floor window. that was where i wrote the backend for Lexana. when you are writing a multi-agent legal platform on a throttled mobile connection where every API call costs money you don't have, you learn very quickly that architectural discipline isn't an aesthetic choice. it's the difference between shipping something that works and running out of money before your first user runs a query. > [!IMPORTANT] > When physical bandwidth and API budgets are constrained, naive monolithic RAG pipelines are completely unviable. Efficiency, caching hierarchy, and asynchronous micro-swarms become mandatory survival mechanisms. ## the constraint: Indian law is massive, slow, and expensive the Indian legal corpus is enormous. millions of judgments, overlapping state and central statutes, inconsistent citation formats, and scanned PDF petitions running 80 to 200 pages. if you throw a naive RAG pipeline at Indian case law using GPT-4, three things happen immediately: 1. **your latency explodes.** retrieving 50 chunks, re-ranking them, and stuffing 30k tokens into a reasoning model takes 12 to 18 seconds. no practicing advocate or law clerk is going to wait 15 seconds per question. 2. **your API bills kill you.** running multi-turn legal research across hundreds of active cases will burn thousands of dollars in token costs within days. 3. **the model hallucinates citations.** Indian case law relies on exact citations (AIR, SCC, SCR). a generic model will confidently cite a non-existent 2018 Supreme Court bench. to solve this, Lexana had to be built around three non-negotiables: asynchronous concurrency, multi-tier semantic caching, and a distributed 4-agent swarm. ## the 4-agent swarm architecture instead of one monolithic agent with twenty tools, Lexana divides cognitive responsibility across four specialized micro-services communicating over an asynchronous coroutine mesh: ```ascii Incoming Advocate Query │ ▼ [ QueryClassificationService (Gemini 2.0 Flash Lite) ] │ < 40ms intent classification ├────────────────────────────┐ ▼ ▼ [ Procedural Lookup ] [ Complex Legal Query ] │ │ ▼ ▼ [ Deterministic DB ] ┌───────────────────────┐ │ L1 Redis LRU (TTL 300)│ └───────────┬───────────┘ │ Cache Miss ▼ ┌───────────────────────┐ │ L2 Semantic (τ=0.92) │ └───────────┬───────────┘ │ Cache Miss ▼ ┌────────────────────────────┼────────────────────────────┐ ▼ ▼ ▼ [ SearchAgent ] [ ReviewAgent ] [ VibeDrafting ] (Kanoon + Vector + Exa) (Parallel F1 = 0.94) (OT Engine / CRDTs) ``` 1. **QueryClassificationService**: Every incoming query hits Gemini 2.0 Flash Lite first. within 40ms, it classifies intent, complexity, statutory jurisdiction, and extracts search entities. if the query is a simple procedural lookup, it routes directly to deterministic vector search without waking up expensive reasoning models. 2. **SearchAgent**: Orchestrates parallelized retrieval across Indian Kanoon APIs, vector databases (ChromaDB), and live statutory web sources via Exa. it implements MapReduce-style aggregation with cosine deduplication (similarity threshold > 0.85) to strip redundant headnotes before passing context downstream. 3. **ReviewAgent**: Built specifically for long-form document analysis. it chunks 100-page petitions, runs parallel issue classification (F1 = 0.94), evaluates evidentiary strength against statutory precedents, and generates structured risk scores. 4. **VibeDraftingAgent**: A real-time collaborative document editor. instead of generating static blocks of text, it uses an Operational Transformation (OT) engine compatible with conflict-free replicated data types (CRDTs). lawyers can edit clauses in real time while the AI suggests revisions as non-blocking diffs. ## the L1/L2 caching hierarchy: shaving 60% off LLM spend the biggest win in Lexana's economics came from our two-tier caching architecture: - **L1 In-Memory Cache (Redis LRU)**: exact hash matches on normalized query tokens with a 300-second TTL for hot conversational sessions. - **L2 Semantic Cache**: for queries that aren't identical string matches but ask the same legal question (e.g., "quashing of FIR under Section 482 CrPC for matrimonial dispute" vs. "can 482 CrPC be invoked to quash 498A FIR after settlement"), we compute query embeddings $\mathbf{q}$ and compare them against an indexed set of prior verified synthesized queries $\{\mathbf{k}_i\}$: $$\text{sim}(\mathbf{q}, \mathbf{k}_i) = \frac{\mathbf{q} \cdot \mathbf{k}_i}{\|\mathbf{q}\|_2 \cdot \|\mathbf{k}_i\|_2} \ge \tau = 0.92$$ if the cosine similarity threshold exceeds $0.92$, we return the validated cached synthesis with instant metadata hydration. > [!TIP] > This single L2 semantic layer reduced our external LLM token expenditure by over **60%**, while dropping p95 latency for recurrent legal queries from **4.2s down to under 180ms**. | Metric | Monolithic RAG | Lexana 4-Agent Swarm | Performance Impact | | :--- | :--- | :--- | :--- | | **p95 Recurrent Latency** | 4,200ms | **180ms** | **95.7% latency reduction** | | **Token Cost / Query** | $0.038 | **$0.012** | **68.4% cost savings** | | **Citation Precision** | 78.4% (hallucinations) | **99.2%** (verified SCC/AIR) | **Zero ungrounded citations** | | **Concurrent Throughput** | 12 req/sec | **280 req/sec** | **23x concurrency scale** | ## fault tolerance and WebSocket multiplexing when legal teams collaborate on an urgent bail application or injunction petition at midnight, dropped connections are fatal. we built the backend in async FastAPI with strict concurrency guards: - **Async batching with bounded semaphores**: preventing external rate-limit locks when 50 search coroutines execute concurrently. - **Hystrix-style circuit breakers**: with exponential backoff (1s base, 2x multiplier) across all third-party legal API endpoints. - **WebSocket multiplexing**: SockJS fallback with 30-second heartbeat pings, preserving state even over shaky tier-3 broadband or mobile connections. - **Git-inspired DAG version history**: every suggested draft change lives on a version graph with automated 3-way merge resolution, so an AI suggestion never overwrites an attorney's manual edit. ## building without permission people often think you need a massive team, a venture round, and an office in Bangalore to build production-grade AI infrastructure. the reality is that constraints force good engineering. sitting in a warm room in Prayagraj with a fan whirring overhead, every millisecond of latency and every redundant dollar spent on token calls felt real. Lexana was pitched to angels, backed, and is now operating across borders in Nepal. you don't need ideal conditions to ship serious systems. you just need to care enough about the architecture to make every line of code earn its place. --- --- Title: why we need hybridmind: vector search is blind, graphs are brittle, and AI memory needs local ground truth URL: https://a3ro.dev/blog/why-we-need-hybridmind Published: 2026-08-18T08:00:00.000Z Updated: 2026-08-18T16:10:20.253Z # why we need hybridmind: vector search is blind, graphs are brittle, and AI memory needs local ground truth if you ask most engineers how they handle long-term memory for an AI agent, they will tell you: > "we embed the conversation history into OpenAI text-embedding-3, store it in Pinecone, and retrieve top-k chunks." this works for simple demo chatbots. the moment you try to run an autonomous agent over a multi-month workflow—tracking entities, state changes, temporal updates, and exact identifier lookups—this approach falls apart completely. i am actively building [HybridMind](https://github.com/a3ro-dev/hybridmind) as an open WIP research engine because agentic memory is not just a vector search problem. it is a hybrid retrieval problem that belongs locally on the developer's machine, not locked inside an opaque cloud API. ```ascii Query: "Section 482 quashing petition timeline and counsel notes" │ ┌──────────────────┼──────────────────┐ ▼ ▼ ▼ [ Dense FAISS ] [ Okapi BM25s ] [ NetworkX Graph ] (4096-dim HNSW) (Exact Lexical) (Entity Topology) │ │ │ └──────────────────┼──────────────────┘ ▼ [ Reciprocal Rank Fusion (k=60) ] │ ▼ [ Time-Decay Half-Life Clamping ] │ ▼ [ Sub-millisecond Local Ground Truth ] ``` ## the blindness of pure vector search dense vector embeddings are great at fuzzy semantic similarity. if you search for "automobile maintenance," a dense vector will easily match "car engine repair." but vector search has three fatal blindspots: 1. **it has no sense of explicit topology.** if node A is connected to node B, and node B is connected to node C, vector search cannot traverse that multi-hop path. it treats every chunk as an isolated point in high-dimensional space. 2. **it is terrible at exact keyword precision.** if an agent needs to retrieve an exact UUID, variable name, invoice number, or legal statute ("Section 482"), semantic vectors will happily return another random alphanumeric string with a high cosine similarity. 3. **it is temporally illiterate.** vector similarity does not know whether an event happened ten minutes ago or three years ago. if a user says "i moved from Delhi to Bengaluru last week," vector search will continue retrieving "lives in Delhi" with identical semantic confidence. ## the brittleness of pure knowledge graphs when people realize vector search fails at structure, the usual knee-jerk reaction is to replace it entirely with a Knowledge Graph (Neo4j, GraphRAG). graph search has its own failure modes: - it requires strict entity extraction and schema alignment on ingestion. if an edge wasn't explicitly extracted during ingestion, the path is broken. - when edge densities are sparse or noisy, graph traversals either terminate early or explode into combinatorial graph walks that blow up latency. - it struggles with natural, messy colloquial queries that don't match exact entity node keys. ## the hybrid solution: 4-way fusion over local indexes HybridMind solves this by fusing dense vectors, sparse lexical ranks, typed graph proximity, and time-decay curves into a single deterministic retrieval pipeline: ### 1. Reciprocal Rank Fusion ($k=60$) instead of trying to normalize raw cosine similarity scores with BM25 frequencies (which have completely different score distributions), HybridMind uses **Reciprocal Rank Fusion (RRF)**: $$\text{RRF}(d) = \sum_{m \in M} \frac{w_m}{k + r_m(d)}$$ where $M = \{\text{vector}, \text{bm25}, \text{graph}\}$, $r_m(d)$ is the 1-indexed rank of document $d$ in retrieval mode $m$, $w_m$ is the modality weight ($\sum w_m = 1$), and $k = 60$ is the smoothing constant. > [!IMPORTANT] > RRF ensures that an item ranking consistently well across multiple independent retrieval modalities floats to the top, even if its raw score in any single modality wasn't an absolute outlier. ### 2. Strict 4096-Dimensional Embedding Invariant most vector libraries silently accept whatever dimension your local model outputs, or pad vectors with zeros. HybridMind enforces a strict **4096-dimensional embedding invariant** at startup, ingestion, and search. whether you are running remote TEI or a local embedding model, any dimensional mismatch causes an immediate hard failure. there are no lower-dimensional fallbacks or projected pads. either the vector space is mathematically consistent, or the system does not ingest. ### 3. Safe .mind.zip snapshots without pickle vulnerabilities storing local AI memory often leads developers to use Python's pickle serialization. this is a major security vulnerability—loading an untrusted pickle file allows arbitrary remote code execution. > [!WARNING] > Python's `pickle` serialization allows arbitrary opcode execution during unpickling. HybridMind strictly forbids pickle files. HybridMind saves all state into a verified `.mind.zip` archive containing: - `store.db`: SQLite database running in WAL mode for ACID-compliant metadata, nodes, edges, and session history. - `vectors.json`, `graph.jsonl`, and `bm25.jsonl`: human-readable derived-index data. - `manifest.json`: containing SHA256 checksums of every component and backup rotation metadata. at boot, runtime FAISS, NetworkX, and BM25 indexes are rebuilt from validated local data in sub-second time. | Dimension | Cloud Vector DBs (Pinecone/Weaviate) | GraphRAG (Neo4j) | HybridMind (Local WIP) | | :--- | :--- | :--- | :--- | | **Exact Token Matching** | Weak (Fuzzy semantic only) | Weak (Schema dependent) | **High (Okapi BM25s + PyStemmer)** | | **Multi-Hop Traversal** | None | High (Heavy compute) | **Fast Local NetworkX Subgraphs** | | **Data Privacy** | Cloud Exfiltrated | Cloud / Self-Hosted Server | **100% Local Air-Gapped Machine** | | **Snapshot Security** | Vendor Locked | Dump SQL / Cypher | **Signed .mind.zip (SHA256 Manifest)** | | **Deployment Footprint** | Cloud API ($$$) | JVM / Server Cluster | **Single Python SDK + SQLite WAL** | ## local first, observable always agents shouldn't depend on proprietary cloud black boxes to remember what they did yesterday. HybridMind is packaged with a lightweight Python SDK (`sdk/memory.py`), a search CLI for interactive debugging, and strict preflight validation scripts that prevent unexpected token spend. long-term memory is too important to be treated as a magical vector prompt. it deserves sound data structures, deterministic snapshots, and local ground truth. --- --- Title: Inside an Autonomous Hackathon Screening Agent: Architecture, Scoring, and Failure Modes URL: https://a3ro.dev/blog/autonomous-ai-eval-cli Published: 2026-07-07T19:07:58.224Z Updated: 2026-08-18T16:10:20.679Z # inside an autonomous hackathon screening agent India Innovates 2026 had roughly 3,000 submissions, each usually a PDF or PPTX link, and a shortlist deadline. the system needed to classify the file, render it, infer the relevant problem statement, assess the work, verify the claims it could verify, and leave a record of the decision. ## the pipeline ``` submission URL → dedupe → render slides → extract context → map problem statement → evaluate evidence → verify GitHub where present → score + audit trail ``` the score separated deck quality, alignment to the actual prompt, prototype credibility, and supporting media. the hard gate mattered most: no credible prototype evidence and no real repository activity meant an automatic rejection, even if the slides were polished. at hackathon scale, presentation and proof are not the same thing. ## failure modes were product requirements duplicate rows and repeated links were skipped before work began. transient errors retried with backoff. a hard quota failure stopped the run rather than letting thousands of later requests write bad results. model output was validated before any score became permanent. workers coordinated so the same submission could not be evaluated twice. for large batches, an asynchronous queue can lower cost, but it makes monitoring even more important. before a run, the diagnostics check keys, database access, expected tables, duplicates, and recent failures. catching a bad configuration before submission one is much cheaper than discovering it after submission 1,400. the system sustained around 7.5 submissions a minute, so approximately 3,000 entries took about 400 minutes and about $20 in API credit. i do not think the lesson is “use an LLM to judge everything.” the lesson is narrower: if you automate a decision that affects people, build the evidence checks, stopping conditions, and audit trail before you celebrate the throughput. --- --- Title: beautiful enough to build URL: https://a3ro.dev/blog/beautiful-enough-to-build Published: 2026-06-13T18:26:31.798Z Updated: 2026-08-18T16:10:22.451Z # beautiful enough to build some ideas make you keep returning to them after the excitement has worn off. not because they are guaranteed to work, but because the world feels a little more complete if they do. that is what i think beauty can mean in a dream. not decoration. not a quote on a wall. a picture of something worth carrying through the boring parts: the failed version, the unanswered email, the year where nobody can see why you keep going. imagination matters because every made thing had to become specific in somebody's mind before it could become real. but belief alone is cheap. the work starts when the dream turns into a calendar, a prototype, a difficult conversation, or a second attempt after the first one did not work. there is no virtue in refusing to change course. some dreams fail because the facts do not support them. some need to become smaller and more honest before they can become real. holding a vision should not mean ignoring the world; it should mean being willing to learn enough from the world to build it properly. i still think there is value in choosing work that feels beautiful to you. it gives you a reason to care when external validation disappears. just make sure the feeling becomes a practice. the dream gets you to the desk. the work is what makes it visible to anyone else. --- --- Title: context engineering, or: how i got consistent art out of a diffusion model without training anything URL: https://a3ro.dev/blog/context-engineering-consistent-art-without-training Published: 2026-06-10T13:20:49.535Z Updated: 2026-08-18T16:10:21.272Z # context engineering, or: how i got consistent art without training a model the first few generated panels were good enough to make me optimistic and inconsistent enough to make that optimism useless. the character changed shape. the style drifted. details that looked stable in one image quietly disappeared in the next. this is the normal failure mode when you ask a model to remember an aesthetic system it was never trained to hold. so i stopped treating each prompt as a fresh request and wrote a production bible instead. it defined the character's silhouette, palette, proportions, setting, emotional range, and the specific things the model should not improvise. then i used reference images and a repeatable prompt structure for every panel. the result was a 75-panel graphic novel with a recognisable visual language. that result matters, but the boundary matters more: it worked because Nybble was designed around simple geometry and a silhouette the model could reproduce. a character with a specific human face, complex lighting, and lots of subtle expressions is a different problem. ## specification came before generation the useful lesson is not “prompting replaces training.” it does not. it is that consistency starts with deciding what must remain consistent. a production bible makes the decisions visible before a model starts inventing them for you. it tells you which details are structural, which ones may vary, and how you will recognise a panel that belongs. without that, you are mostly collecting attractive accidents. context engineering is a real tool. it has sharp edges. in a constrained visual system, detailed references and procedural rules can take you further than people expect. outside that boundary, fine-tuning, editing, or a human artist may be the right answer. the point is to know the boundary before you promise consistency. design for what the tool can reliably do, not for what the demo made you hope it could do. --- bits&bytes is at [gobitsnbytes.org](https://gobitsnbytes.org). We're India's independent teen-led builder network. Come ship something. --- --- Title: the machine that thinks but doesn't feel URL: https://a3ro.dev/blog/the-machine-that-thinks-but-doesn't-feel Published: 2026-06-02T18:11:54.540Z Updated: 2026-08-18T16:10:22.059Z # the machine that thinks but doesn't feel i spend a lot of time building with systems that can write, reason through a bug, and occasionally surprise me. the surprising part is not that they sound human. it is that they can be useful without there being any obvious person on the other side of the words. consciousness is still an unsolved question. David Chalmers called the gap between information processing and subjective experience the “hard problem.” A system can take in signals and produce complex behaviour; that does not tell us whether anything is being experienced. there are serious theories, and they disagree. Integrated Information Theory asks how much a system irreducibly integrates information. Global Workspace Theory describes conscious access as information becoming widely available across a system. Experiments have tested predictions from both, but no consensus has settled the matter. A major adversarial study found results that challenged parts of each account rather than handing either one a win. [Cogitate Consortium, *Nature*](https://www.nature.com/articles/s41586-025-08888-1) ## intelligence and experience may come apart this matters for AI because capable behaviour is not proof of inner life. an LLM can manipulate language well enough to look like it understands. whether that is understanding, or a very powerful form of pattern completion, depends partly on what we think understanding requires. the honest current answer is that we do not know whether present systems are conscious, and we should not market them as though we do. Researchers have proposed theory-based indicators for assessing AI consciousness; their conclusion is not that current models are clearly conscious, but that future systems could be built with more of the relevant properties. [Butlin et al.](https://arxiv.org/abs/2308.08708) ## the practical risk is here already i do not need a model to feel pain before i care about its impact. systems that can take actions, persuade people, or make high-stakes recommendations need boundaries because humans are affected by the result either way. maybe consciousness turns out to be central. maybe it does not. in the meantime, the thing i keep coming back to is simpler: intelligence without stakes can still cause damage. a system does not need to want something in order to optimise the wrong thing very effectively. we should keep researching the question. we should also build products as if uncertainty is real: clear limits, human accountability, records of what happened, and no fake claims of personhood just because a demo is fluent. --- --- Title: how to know if you're delusional (no, really) URL: https://a3ro.dev/blog/reality-vs-delusion Published: 2026-05-31T20:47:14.725Z Updated: 2026-08-18T16:10:22.868Z # how to pressure-test a belief certainty has a similar feeling whether it is earned or not. that is the uncomfortable bit. feeling sure is not evidence that you are right. this is not a guide to diagnosing yourself or anyone else. if a belief is causing distress, making daily life unsafe, or separating someone from people they trust, a qualified mental-health professional is the right person to involve. this is about the ordinary beliefs we become too attached to: a career plan, a political theory, a story about what another person thinks of us. ## make the belief pay rent write down what would change your mind. not “more evidence,” but a particular observation, result, or conversation. if nothing could count against the belief, you are not testing it. you are protecting it. then try to state the strongest opposing view in a way its supporters would recognise. if you can only explain disagreement through stupidity, malice, or a conspiracy, your model has probably become too convenient. also ask where the belief came from. did the evidence lead you there, or did the belief solve a need first and then recruit evidence around it? most of us do both. the point is to notice the direction of travel. finally, check the predictions. a useful belief should help you anticipate something in the world, make a better decision, or coordinate with other people. if it repeatedly makes reality more surprising, it deserves another look. the best sign is not that you enjoy being challenged. nobody does, consistently. it is that you can stay in the conversation long enough for the challenge to teach you something. conviction can say, “here is what i know, here is what i don't, and here is what would move me.” that is a harder kind of confidence to build. it is also the kind worth having. --- --- Title: on b.tech, fake dreams, and the life nobody asked for URL: https://a3ro.dev/blog/btech-fake-dreams-life Published: 2026-04-16T14:56:44.788Z Updated: 2026-09-26T04:44:59.735Z # on b.tech, safety, and choosing a life you can own engineering is a good path for some people. the problem starts when it becomes the answer before anyone has had time to ask the question. in a lot of families, a b.tech degree carries a promise: stability, respect, a job that will make the risk feel justified. that promise is understandable. it comes from real pressure. but a safe option chosen without curiosity can still leave someone lost four years later, holding a credential they do not know how to use or whether they even want to. college can teach tools. it does not reliably teach decision-making. so people borrow direction from parents, placement statistics, creators selling “freedom by 25,” or whoever sounds most certain that week. the internet makes this worse because urgency sells. if you are nineteen and confused, a loud roadmap can feel like proof. it is not. most serious work takes years before you can tell whether you are good at it, and even longer before it becomes stable. the answer is not to reject engineering or safety as a performance of independence. it is to ask better questions while there is still room to change: what kind of work can i stay curious about? what am i optimizing for? what would i try if nobody could turn it into a family verdict? you cannot outsource those answers. people can advise you, fund you, worry about you. they cannot live the consequences in your place. --- --- Title: on adulting in india — loneliness, guilt, choices nobody trained us for URL: https://a3ro.dev/blog/adulting-in-india Published: 2025-12-05T10:51:36.597Z Updated: 2026-08-18T16:10:23.450Z # on adulting in india the strange part of growing up in india is that you can be given a very detailed script for twenty years and then be expected to improvise the rest. study hard. choose the safe option. respect your family. make them proud. none of that is bad advice on its own. it just leaves a gap when you want something that does not fit the script, like living alone, changing direction, or choosing a life that looks less legible to relatives. wanting independence is not the same as wanting distance. you can love your family and still need a room where your decisions are not a group project. the problem is that many of us were never taught the language for saying that without making it sound like rejection. there is privilege in this too. not everyone gets to experiment with career, city, or relationships without carrying financial consequences for an entire family. pretending every choice is equally available would be dishonest. but responsibility eventually arrives anyway. it looks like paperwork, budgeting, difficult conversations, and finding out that no adult is about to tell you the correct next move. maybe adulthood is not becoming certain. maybe it is learning to make a decision with incomplete information, own the cost, and keep your people close without handing them the steering wheel. --- --- Title: agentic ai — the wave i didn’t ask for (but can’t ignore) URL: https://a3ro.dev/blog/agentic-ai-wave Published: 2025-10-03T18:46:56.993Z Updated: 2026-08-18T16:10:29.367Z # agentic ai is getting useful. that makes the boundaries matter more. the word “agentic” is now attached to almost every AI product. sometimes it means a model can use tools and retry a task. sometimes it mostly means there is a chat box with a louder landing page. the useful distinction is simpler: can the system see relevant context, take a bounded action, check what happened, and hand the result back to a person who can own it? if it cannot, the label is doing more work than the product. ## capability is not oversight an agent that can read files, send messages, or change records needs more than a good prompt. it needs constrained permissions, logs that survive the run, clear approval points, and a way to stop it when it goes wrong. a system that can act should be easier to inspect than a system that only talks. this is not an argument against agents. they can remove a lot of copy-paste work and make small teams more capable. it is an argument against treating autonomy as the same thing as trust. ## emotional dependence is a different failure mode AI companions deserve extra care. a system designed to keep somebody engaged has incentives that can collide with that person's real relationships and mental health. it should not pretend to be a substitute for a friend, therapist, or partner. it should be clear about what it is and make it easy to step away. i think the next few years will make agents normal infrastructure. the question is whether we build the boring parts too: permission boundaries, audit trails, honest failure states, and products that leave people more capable than they found them. speed is useful. a system that can explain what it did, and let you stop it, is useful for longer. --- --- Title: love, after it stops feeling safe URL: https://a3ro.dev/blog/love-a-feeling-i-wish-to-never-experience-ever-again Published: 2025-09-18T16:15:28.722Z Updated: 2026-08-18T16:10:45.866Z # love, after it stops feeling safe i wrote before about finding someone who feels like home. i meant it when i wrote it. i also know now that a sentence can be true for one version of you and impossible for the next. loss has a way of making every soft thing look irresponsible. when someone leaves, changes, or stops choosing you, the cleanest response can seem like becoming untouchable: make money, make plans, build a life no person can shake. i understand that instinct. some of it is useful. financial security matters. having work, friends, routines, and a sense of self outside one relationship matters. no one should be your entire architecture. but i don't want to confuse being protected with being closed. shutting every door does not make the house stronger. it just means no one gets in, including the people who might have treated the place carefully. right now, i want to put my energy into work i can stand behind and a life i can hold on my own. that is not revenge. it is repair. i don't know what i will believe about love later. i am not going to make a permanent philosophy from a temporary injury. for now, the honest answer is smaller: i am hurt, i am still here, and i have things to build that do not require me to pretend i am fine. --- --- Title: on having a good partner URL: https://a3ro.dev/blog/finding-someone-who-feels-like-home Published: 2025-04-29T04:21:23.934Z Updated: 2026-08-18T16:10:42.209Z # on having a good partner after a day that has taken more than it gave, a good relationship can be surprisingly ordinary: a call, a stupid meme, a message asking whether you ate. the important part is not that another person fixes your mood. nobody can carry that job forever. it is that you do not have to edit yourself into someone easier to love before you can be close to them. trust looks less cinematic than people make it sound. it is being able to say, “i'm not doing great,” without turning it into a case for why you are still worth keeping around. it is disagreeing without making the relationship feel threatened. it is knowing both people are allowed to have a difficult day. love does not remove the hard parts of life. it gives you one person with whom the hard parts can be named honestly. that is not dependence in the helpless sense. it is partnership. two people still responsible for their own lives, still choosing to make room for each other inside them. if you find that, take care of it. not through grand declarations every day, but through attention. listen properly. apologise without making it a performance. ask the small questions. home, i think, is often just the person beside whom you can stop bracing for a minute. --- --- Title: burnout, comparison, and doing work you can return to URL: https://a3ro.dev/blog/burnout-bullshit-being-human Published: 2025-04-17T15:14:05.822Z Updated: 2026-08-18T16:10:36.414Z # burnout, comparison, and doing work you can return to some days the code editor feels heavier than it should. not because the problem is impossible, but because you opened the internet first and now somebody else's launch, job offer, or twelve-hour build sprint is sitting on your chest. that feeling is real. it is also a terrible way to measure whether your own work is going anywhere. most timelines are made of finished screenshots and clean explanations. they do not show the half-built projects, the money behind the setup, the people helping off-camera, or the ordinary weeks where nothing works. comparing your Tuesday to that is not ambition. it is just bad data. ## don't turn learning into a spectator sport there are useful courses. there are also endless videos designed to make you feel productive without having to risk being bad at anything. if you are two hours into a tutorial and cannot say what you are trying to make with it, pause. build a smaller thing. let it be ugly. let it take longer than the thumbnail promised. the point is not to become impressive by Friday. the point is to acquire evidence that you can meet a problem, get confused, and keep moving. ## rest is part of the work burnout does not usually arrive as one dramatic collapse. sometimes it looks like opening the same project every day and feeling nothing. sometimes it looks like hating a subject you cared about last month. when that happens, sleep. go outside. talk to someone who does not need you to perform competence. then come back and choose a task small enough to finish. i still think curiosity is a better reason to learn than fear of being left behind. it lasts longer. and tomorrow's code will still be there. --- --- Title: so you're thinking of learning to code? URL: https://a3ro.dev/blog/learning-to-code-vibe-era Published: 2025-04-08T10:28:28.160Z Updated: 2026-08-18T16:10:34.076Z # so you're thinking of learning to code? the first useful thing i ever made with code was small enough to be embarrassing. it saved me from doing the same boring task by hand again. that was enough. i understood, for the first time, that a computer isn't only a thing you consume things through. you can ask it to do work differently. you don't need a startup idea to start learning. you don't need to turn every afternoon into a career plan. maybe you want to rename a pile of files, make your desktop less annoying, build a tiny game, or understand why a page breaks when one line of CSS changes. those are real reasons. ## start with a problem you can touch syntax matters, but it is not the beginning. the beginning is noticing a small piece of work and asking what steps a computer would need to take. if you want to rename files, what information does the script need? where are the files? what should their new names look like? what happens if two names collide? that is programming: turning a vague annoyance into instructions precise enough to run. pick one beginner-friendly tool and stay with it long enough to make something work. [Python](https://www.python.org/) is a good place to begin. so is a little HTML, CSS, and JavaScript if you want to see the result in a browser. [The Odin Project](https://www.theodinproject.com/) and [CS50](https://cs50.harvard.edu/x/) are useful when you want structure, but don't mistake watching for learning. ## let projects make the curriculum i'd rather see someone build a clumsy file organiser than finish another playlist of tutorials with nothing to show for it. projects give you the questions that lessons cannot: why did this fail? where does this data go? how do i make it less ugly? why is the program doing exactly what i told it to do instead of what i meant? that frustration is not a sign you picked the wrong thing. it is the part where the machine starts becoming legible. start small. make the weird little tool. break it, read the error, change one thing, run it again. you do not need permission to begin. you just need something you wish your computer could do. ## Canonical Links - Portfolio: https://a3ro.dev - Location: Prayagraj, Uttar Pradesh 211001, India - LinkedIn: https://www.linkedin.com/in/akshat-singh-kushwaha/ - GitHub: https://github.com/a3ro-dev - Twitter/X: https://twitter.com/a3rodev - Email: akshatsingh14372@outlook.com / akshat@gobitsnbytes.org