Welcome to GovtInvoice Discussions!

[seetadev]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[zsklav]

Hi everyone, and thanks @seetadev for opening this up.

I came in via the DMP 2026 Agentic Invoice Co-Pilot issue (#37). The piece that pulled me in is the "Trust Boundary" between agent suggestions and finalized, paid records. In public-sector billing, a confidently hallucinated total that slips into an immutable, auto-settled invoice is a major liability.
Before applying, I put together a small POC, invoice-guard, that treats the LLM as an untrusted proposer and routes every draft through deterministic structural, arithmetic (decimal.Decimal with 0% float tolerance), and anomaly gates before anything is allowed to finalize: https://github.com/zsklav/invoice-guard
Reading the existing thread, I've seen great work already, Mikey's open PR #50 on save-time validation, Jinesh's VVC engine, and vibhutomer's LangGraph ideas. One angle I'd like to open up for discussion is the settlement-agnostic side: x402, MPP (Tempo), and ERC-8004 are all still spec-volatile, and the long-term maintainability of GovtInvoice likely depends on a clean payment-adapter boundary so the core flow doesn't break when a payment-rail spec shifts. Curious how the team is thinking about that decoupling and whether anyone here has already started sketching adapter contracts.
I'm also looking forward to the libp2p / IPFS meetup on Luma and plan to dive into py-ipfs-lite this week to share some feedback in that repo's discussions.

Glad to be here and to learn from everyone!
Vanshikha

[zsklav]

Hi @seetadev, @aspiringsecurity, @prithagupta and everyone in the thread:

Sharing my DMP 2026 proposal here, as requested in the Issue #37 thread comment. Full design doc + visuals attached below; this comment is the high-level summary.

Repo POC: github.com/zsklav/invoice-guard (working code, ~60-case property test pinned in CI)
Full design doc: https://docs.google.com/document/d/1HBdVYB4xcvpMR4QtKzD-wC5XY3FBS-vs

---

TL;DR

LLM-generated invoices in public-sector billing are useful only if every finalized record is provably correct. This proposal hardens GovtInvoice by inserting a deterministic validation gate between any agent suggestion and any irreversible state (IPFS pin, on-chain settlement), plus a payment-adapter interface so the core flow survives x402 / MPP / ERC-8004 spec churn. Both layers are already prototyped in invoice-guard.

The single verified safety property the design carries:

No real defect has ever been laundered into a finalized invoice — provable on every CI run.

---

What's different from a save-time check

The structural problem I'm trying to address: the same Local._saveFile in Storage/LocalStorage.ts is called from Menu.tsx, Files.tsx, NewFile.tsx, and the Firebase sync layer. A check at one call site doesn't protect the others.

My W1–W2 deliverable:

• Make Local._saveFile private
• Expose Local.validatedSave(file) as the only public entry
• Run the gate inside validatedSave() unconditionally
• Update all 4 call sites — single PR

Issue #48 closes by construction the moment this lands. Existing save-time validators continue to live underneath the gate as additional defenses.

---

Three architectural layers, strict directionality

Layer 1 — Agentic Drafting Zone (FastAPI + LangChain). Proposes drafts; architecturally prohibited from writing to finalized state.

Layer 2 — Deterministic Validation Gate (POC: invoice-guard). Three stages — Structural → Arithmetic (decimal.Decimal, 0% float tolerance, banker's rounding) → Anomaly (z-score rolling window). Returns ACCEPT | REJECT | REVIEW. The REVIEW state is the key bit — anomalies don't silently fail; they route to a human-in-the-loop queue with the anomaly signature attached.

Layer 3 — Immutable Finalization. First-class integration with py-ipfs-lite — ipfs_lite.block_service.BlockService for dual-CID emission (canonical dag-cbor for auditors, UnixFS dag-pb artifact for humans). Settlement runs through a PaymentAdapter Protocol.

---

The angle nobody's named yet — payment-adapter interface for spec volatility

The brief names three settlement standards: x402 (programmable HTTP payments), MPP / Tempo (multi-party / streaming), ERC-8004 (agent-driven payments). None are finalized; all three are likely to change shape over 12–18 months.

A naive implementation hardcodes whichever rail looks most stable today and breaks on the next spec revision. The defensible design is an adapter boundary:

class PaymentAdapter(Protocol):
    def can_settle(self, invoice: FinalizedInvoice) -> bool: ...
    def settle(self, invoice: FinalizedInvoice) -> SettlementReceipt: ...
    def supports_milestones(self) -> bool: ...
    def supports_multi_recipient(self) -> bool: ...

class X402Adapter(PaymentAdapter): ...
class MPPAdapter(PaymentAdapter): ...
class ERC8004Adapter(PaymentAdapter): ...
class MockAdapter(PaymentAdapter): ...   # for tests / demos

The core flow only ever calls PaymentAdapter.settle(). The validation gate, the CID layer, and the UI never need to know which rail is in play. Spec churn becomes a one-line dependency swap.

---

12-week plan (phase-gated, mentor-verifiable)

Weeks	Phase	Mentor-verifiable gate
0	Alignment (TS-port vs Python-sidecar, LLM API, testnet allowlist)	Design doc PR-ed into Govt-Billing-React/docs/
1–2	Integrity first — port invoice-guard gate, refactor save path	First merged PR; Issue #48 closed by construction
3–4	Agentic seam — FastAPI advisor, NL/file input in NewFile.tsx	Demo: advisor tries to submit a malformed invoice → gate rejects
5–6	Mid-point milestone — PWA staging build, end-to-end agent→gate→save	Mentors run a working Co-Pilot in their browser; no invalid invoice can be saved or pinned
7–8	CID finalization — py-ipfs-lite integrated, dual-CID emission	Finalized invoice reachable by CID, replays cleanly through the gate
9–10	Payment adapters — Protocol + 2 concrete impls, testnet demo	Same invoice settled via two rails without touching core flow
11–12	Anomaly + HITL + handoff — REVIEW queue, reproducibility docs	Full pipeline runs locally from a fresh clone

---

What this proposal does NOT claim

Honest scoping so the committee knows where the work ends:

• The advisor is a drafter, not an autonomous treasurer. Finalization always requires a deterministic gate-pass or human REVIEW approval.
• SocialCalc replacement is out of scope. The gate operates on parsed invoice JSON regardless of the editor.
• The Angular variant is out of scope; this proposal lands in Govt-Billing-React for the 12-week timeline.
• Mainnet ERC-8004 settlement is not promised within the DMP timeline — the adapter makes mainnet swap-in trivial post-handoff, but the demo uses testnet only.
• The anomaly REVIEW queue UI is sketched but the headline contribution is the gate boundary, not the queue UX.

---

Two wireframes — the operational dashboard this would ship with

---

One question for the maintainers (W0 alignment)

Would you prefer the validation gate as:

• (a) A TypeScript port that runs in the browser/PWA for zero-latency feedback in the save flow, or
• (b) A Python FastAPI sidecar that co-locates with the LLM advisor and reuses the existing invoice-guard test suite directly?

Both have scaffolding in invoice-guard. Either decision is fine; I'd just like to align early to avoid wasted W1–W2 churn.

---

Engagement already underway

• Read the live Govt-Billing-React source end-to-end (every save-path call site mapped).
• Engaged in py-ipfs-lite Discussion #1 on the dag-cbor vs UnixFS encoding question.
• Will be at the libp2p / IPFS meetup linked from the issue thread.

Thanks for reading looking forward to feedback from the committee and anyone else in the thread.

Vanshikha
github.com/zsklav · linkedin.com/in/vanshikha-sri-85010b29b
vanshikhashri@gmail.com

[nehayadav827]

Hey @seetadev @prithagupta @aspiringsecurity,

I’m Neha Yadav, a sophomore at IIIT Guwahati, and I’ve been actively exploring and contributing to GovtInvoice over the past few days, mainly around SocialCalc workflows, invoice generation UX, save/export flows, and Web3-related integrations.

Here’s a summary of my contributions so far:

Save Flow + UX Fixes

• PR #85 — fixed async save flow handling issues in the React app
• Issue #86 + PR #87 — fixed incorrect Save As dialog reopening caused by shared toast flows

While working on these, I spent time understanding the existing save lifecycle, workbook state handling, and how SocialCalc flows interact with the Ionic UI layer.

Web3 / Storage Integration

• PR #88 — added Lighthouse/IPFS integration for decentralized invoice storage

This adds a “Save to IPFS” workflow using Lighthouse along with CID + gateway URL generation for uploaded invoice data.

Export Workflow Improvements

• PR #90 — added CSV export support for SocialCalc invoice data

This involved parsing serialized spreadsheet content into structured CSV output while supporting formula/result handling and both PWA + hybrid/mobile export flows.

Structured Invoice Generation Workflow

• PR #93 — added structured invoice metadata header generation directly inside the spreadsheet workflow

This contribution focused on improving the current spreadsheet-first UX by introducing structured invoice input fields that automatically generate invoice headers and starter line-item sections directly into the SocialCalc sheet.

One thing I’ve genuinely found very interesting while exploring the project is how GovtInvoice is evolving beyond a simple spreadsheet interface into a broader workflow around structured invoice generation, AI-assisted flows, decentralized storage, and Web3-enabled payments. That direction honestly feels very exciting to contribute to and learn from.

I’m still actively exploring the codebase and would genuinely appreciate feedback on any of the PRs whenever maintainers get time to review them.

Also, if there are any specific modules, roadmap areas, or issues where contributors are especially needed, I’d really love to contribute there as well.

Looking forward to learning and contributing more with the community.

[HarK-github]

Proposal Discussion — Agentic Invoice Co-Pilot | Harshit Kandpal, IIT Bhilai

Hello @seetadev, @aspiringsecurity, and @prithagupta,

I'm Harshit Kandpal, a first-year CSE undergraduate at **IIT Bhilai **. I've submitted my proposal for the Agentic Invoice Co-Pilot under DMP 2026 a. I want to use this discussion to walk through my background, my codebase understanding, the architecture I've designed, and invite feedback from the mentors.

---

Background

My work sits at the intersection of AI systems, blockchain infrastructure, and production full-stack engineering. I've shipped real systems under real constraints across large open-source ecosystems and production environments.

Open Source — Large Production Ecosystems

• hyperledger-labs/fablo (Linux Foundation · Hyperledger): Designed and implemented an automated semantic version-bumping CI workflow — a pipeline that creates versioned PRs automatically on release triggers. Fablo is production CI/CD tooling used across the Hyperledger ecosystem globally. Contributing here required deeply understanding their branch strategy, release lifecycle, and CI environment before modifying anything.
• hiero-ledger/hiero-website (Linux Foundation · Hiero Project): Added unit tests for data-fetching and markdown parsing utilities in a production website serving the Hiero distributed ledger community.
• FOSSEE / Chemical-PFD-Web-Desktop (IIT Bombay): Built a comprehensive Vitest-based testing infrastructure during my internship at IIT Bombay — working directly with senior engineers on a production application used in engineering education across Indian universities.
• OpenLake / Campus-Marketplace: Two major contributions — completely overhauled the backend by migrating MongoDB → PostgreSQL with redesigned relational schemas and Google OAuth integration (this single PR laid the foundation for all subsequent feature development), and built a student interest-based recommendation system on top of the new backend.

Achievements

• FOSS Overflow 2025-26 Certificate of Excellence — recognized as Top Contributor
• 12th of 23 IITs at Adobe PS Inter-IIT Tech Meet 14, representing IIT Bhilai
• FOSSEE IIT Bombay Software Development Intern

---

Contributions to This Repository

Before writing a single line of my proposal, I made three targeted PRs to seetadev/GovtInvoice to understand the system from the inside:

1. Firestore-based rate limiting
Implemented brute-force protection by tracking failed login attempts per email in Firestore — automatic lockout after 5 failures within 15 minutes, 30-minute cooldown. Required tracing the Firebase auth flow and Firestore data model end-to-end.

2. Authentication enumeration hardening
Replaced specific Firebase error codes with generic responses to prevent user enumeration attacks. Added inline validation, loading states, and ensured the modal stays open on failure — a security detail that many developers overlook entirely.

3. Spreadsheet grid toggle
Added a grid lines toggle to the SocialCalc editor with dynamic icon switching via React useState and AppGeneral.toggleGridLinesCSS() — required understanding how the Capacitor shell, React layer, and SocialCalc CSS bridge interact with each other.

These weren't surface-level changes. Each one required tracing real execution paths through the app, which is why the architecture I'm proposing is grounded in how the codebase actually works.

---

System Understanding

After studying the repository thoroughly, I identified seven core subsystems:

• SocialCalc spreadsheet engine (bridge functions + public/SocialCalc.js)
• Template and editable-cell constraint model (app-data.ts)
• Local persistence via Capacitor Preferences
• Firebase Firestore cloud sync
• Firebase Authentication
• Action/export layer (save, print, email)
• Capacitor cross-platform shell (Android, iOS, PWA)

The critical architectural insight: All invoice operations route through the SocialCalc workbook bridge. This means an AI system cannot simply output flat JSON — it must produce or patch a coordinate-mapped workbook structure. My design handles this by separating concerns: AI outputs a clean normalized invoice schema, and a dedicated conversion utility handles all workbook patching, cloning the existing template and updating only editable cells while preserving every formula and formatting rule untouched.

---

Proposed Architecture

Overview

📌
(The 4-layer diagram: UI Modules → Service Layer → Existing SocialCalc Core Engine → External Web3 Networks)

The system is organized into four layers:

• UI Layer: Home.tsx, Menu.tsx (extended), ValidationBanner.tsx, AI Prompt Modal, PaymentModal, useDeepLink.ts
• Service Layer: InvoiceAgent.ts → workbook.ts → FilecoinStorage.ts + PaymentService.ts, alongside existing Firebase and LocalStorage
• Core Engine: Existing SocialCalc engine, app-data.ts templates, Capacitor plugins — untouched
• External Infrastructure: OpenAI API, Lighthouse/IPFS/Filecoin, Base Sepolia, WalletConnect

This layered separation means existing workflows — editing, saving, syncing, exporting — are never at risk of regression.

---

Layer 1 — AI Invoice Generation & Validation

The user opens the AI Prompt Modal and describes the invoice in natural language or fills a structured form. The request goes to InvoiceAgent.ts, which calls OpenAI with low-temperature structured JSON output to ensure deterministic, parseable responses.

The AI outputs a normalized invoice schema — not SocialCalc workbook data directly. This schema contains:

• Vendor details (name, address, GSTIN)
• Invoice metadata (ID, date, due date)
• Line items (description, quantity, unit price)
• Tax rates and computed totals

A parallel validation pipeline then checks:

• Missing required fields
• Inconsistent totals (line items don't add up to stated total)
• Implausible quantities or negative values
• Incomplete vendor information

Validation warnings surface as dismissible chips in ValidationBanner.tsx above the editor — the user sees the issue before anything is saved or archived.

---

Layer 2 — Workbook Conversion & Filecoin Archival

workbook.ts receives the normalized schema and bridges it into SocialCalc's coordinate-mapped workbook format. Instead of generating workbook JSON from scratch (which risks corrupting formulas), it:

1. Reads the serialized structure of the existing invoice template
2. Identifies editable cell coordinates (vendor fields, invoice ID, dates, line-item rows)
3. Clones the template in memory
4. Updates only those editable cells
5. Leaves all formulas, formatting rules, and structural data untouched

Firebase continues storing editable working documents. Filecoin stores tamper-evident archival snapshots. These are two separate concerns — operational storage vs audit storage — kept cleanly separated.

📌
(The storage dataflow: User taps "Save to Filecoin" → FilecoinStorage.save(workbookJSON) → Lighthouse SDK upload() → CID returned → displayed in app, with async local backup via @capacitor/filesystem running in parallel)

FilecoinStorage.ts serializes the finalized workbook and uploads it via the Lighthouse SDK, returning a content-addressed CID. For Capacitor WebView environments where browser uploads can fail, a lightweight serverless fallback handles Filecoin persistence without changing any frontend behavior.

---

Layer 3 — Payment & Audit

📌 ]
(The payment flow: User taps "Pay Invoice" → PaymentModal shows amount + CID → WalletConnect handshake → sendTransaction on Base Sepolia with PPT token → tx hash returned → AuditRecord{CID, txHash, amount} stored and displayed as proof)

The payment flow is intentionally straightforward and verifiable:

User taps "Pay Invoice"
     ↓
PaymentModal — shows invoice amount + Filecoin CID
     ↓
WalletConnect / injected wallet handshake
     ↓
sendTransaction (PPT token, Base Sepolia testnet)
     ↓
Transaction hash returned
     ↓
AuditRecord { cid, txHash, amount } — stored and displayed

This creates a permanent, verifiable link between the archived invoice (CID on Filecoin) and its payment (txHash on-chain). Both are displayed together as proof in the UI, with links to the decentralized gateway and block explorer.

Native apps register custom URL schemes; the PWA uses query-parameter routing — so deep links resolve correctly across all three deployment targets.

---

Relevant Past Projects

AuthrNet — Decentralized Publishing Platform
Built the smart contract access control layer in Solidity and integrated IPFS storage via Wagmi/Viem. Direct technical precedent for the Filecoin archival layer in this proposal.

IIT Bhilai RAG Agent
Designed a hub-and-spoke agent architecture with a custom two-layer semantic cache, reducing LLM API costs by 60%. Built the full document ingestion pipeline with semantic chunking and Chroma DB vector storage. Maps directly to the InvoiceAgent design.

Inter IIT Adobe Hackathon — AI Image Segmentation (12th / 23 IITs)
Engineered a CPU-optimized MobileSAM+LaMa inference pipeline with FastAPI REST APIs targeting mobile-first environments with limited compute. The constraint-aware optimization mindset applies directly to building efficient AI workflows inside Ionic/Capacitor.

FOSSEE Internship — IIT Bombay
Built a scalable React.js interface using Django REST APIs under senior IIT Bombay engineers, on a production application with real institutional users.

---

Implementation Timeline

Month 1 — AI Layer (Mid-point milestone deliverable)

• InvoiceAgent.ts service with OpenAI structured output
• Normalized invoice schema design
• Validation pipeline (missing fields, total consistency, quantity checks)
• ValidationBanner.tsx UI component
• AI Prompt Modal integration

Month 2 — Workbook Conversion + Filecoin Archival

• workbook.ts template cloning and editable-cell patching utility
• FilecoinStorage.ts with Lighthouse SDK
• CID generation, display, and gateway linking
• Serverless fallback for Capacitor WebView upload limitations
• Firebase + Filecoin coexistence (operational vs audit storage separation)

Month 3 — Payments, Deep Linking, Testing, Deployment

• PaymentService.ts + PaymentModal with WalletConnect on Base Sepolia
• AuditRecord generation linking CID + txHash
• Deep linking (custom URL schemes for native, query params for PWA)
• Capacitor plugin integration: Email Composer, Filesystem, Share
• Full end-to-end testing: browser, Android, iOS
• Complete create → validate → store → export → pay workflow

Stretch goals (time permitting):
ERC-4337 smart accounts for gasless payments, zero-knowledge archival proofs, milestone-based escrow, multi-agent compliance workflows.

---

I'm happy to discuss any part of the architecture, technical tradeoffs, or implementation choices. Looking forward to feedback from the mentors.

— Harshit Kandpal
IIT Bhilai CSE | kandpalhar@gmail.com
GitHub: [HarK-github](https://github.com/HarK-github) | LinkedIn: [harshit-k-a746a1310](https://www.linkedin.com/in/harshit-k-a746a1310/)