DEV Community: Pubudu Tharanga Abewarna

Decoding Sri Lanka's NIC Numbers: Building NIC Info, a Zero-Dependency, Privacy-First Web App

Pubudu Tharanga Abewarna — Mon, 17 Aug 2026 08:46:22 +0000

Have you ever wondered how much personal data is quietly baked into the string of digits on your National Identity Card?

In Sri Lanka, an Identity Card (NIC) number isn't an arbitrary sequence generated by a database — it's a deterministic, compact demographic hash containing your exact birth year, day of birth, legal gender, and historical electoral eligibility.

For decades, converting an NIC number to a date of birth — or just verifying an ID card — meant manual calendar arithmetic, or handing your sensitive personal data to an ad-filled site that shipped it straight to some remote server.

I decided to fix that by building NIC Info, a high-performance, air-gapped, zero-dependency NIC decoder and conversion suite, built entirely with modern web standards.

Here's what I'll cover:

The math and engineering behind Sri Lanka's NIC formats (old vs. new)
The female +500 day offset and leap-year calendar quirks
Architecting an air-gapped, zero-knowledge client engine
Designing a bespoke "Registry Office" editorial UI system
Key takeaways for building high-performance web apps in 2026

🏛️ 1. The Anatomy of Sri Lankan Identity Numbers

Sri Lanka has two distinct NIC numbering eras, administered by the Department for Registration of Persons (DRP):

┌────────────────────────────────────────────────────────────────┐
│ 1. Legacy Format (1972-2015): 9 Digits + Letter                │
│                                                                │
│    Example: 941234567V                                         │
│    [94]  [123]  [4567]  [V]                                    │
│    Birth Year | Day Code | Serial No. | Voter Status           │
├────────────────────────────────────────────────────────────────┤
│ 2. Modern Smart NIC (2016-present): 12 Digits                  │
│                                                                │
│    Example: 199412345678                                       │
│    [1994]  [123]  [4567]  [8]                                  │
│    Century Year | Day Code | Serial No. | Checksum             │
└────────────────────────────────────────────────────────────────┘

Let's break down the individual segments.

The Birth Year Encoding

Legacy (9-character): a 2-digit year prefix (94 → 1994)
Modern (12-digit): the full 4-digit Gregorian year (1994 or 2003), which eliminates Y2K-style ambiguity entirely ### The 3-Digit Day Code and the Gender Offset

Instead of storing month and day separately, the DRP packs both date of birth and gender into a single 3-digit ordinal day value, 001 to 866:

Males: ordinal day assigned directly — 001 (Jan 1) through 366 (Dec 31)
Females: a constant offset of 500 is added — 501 (Jan 1) through 866 (Dec 31)

const FEMALE_OFFSET = 500;

function getGenderAndDay(rawDayCode) {
  if (rawDayCode > FEMALE_OFFSET) {
    return {
      gender: 'Female',
      dayOfYear: rawDayCode - FEMALE_OFFSET
    };
  }
  return {
    gender: 'Male',
    dayOfYear: rawDayCode
  };
}

This single-field design was an elegant space optimization for 1970s mainframe databases — it recovers both gender and birth date without needing an extra database column.

The Leap Year and "Day 60" Quirk

This is where most hobbyist NIC decoders fall apart.

The DRP's encoding is based on a uniform 366-day calendar baseline, so March 1st is always treated as day 061. In non-leap years:

Day 60 (February 29th) is simply skipped in issuance
A day code of 061 in a non-leap year still means March 1st
Converting a non-leap day number back into a calendar date means any index >= 60 needs a -1 adjustment to line up with the real 365-day Gregorian calendar

function nicDayToCalendarDate(dayOfYear, year) {
  const leap = (year % 4 === 0 && year % 100 !== 0) || (year % 400 === 0);
  let adjustedDay = dayOfYear;

  // Handle the skipped Day 60 convention on non-leap years
  if (!leap && adjustedDay >= 60) {
    adjustedDay -= 1;
  }

  const cumulativeDays = leap
    ? [0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366]
    : [0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 365];

  let month = 1;
  while (month <= 12 && adjustedDay > cumulativeDays[month]) {
    month++;
  }

  const day = adjustedDay - cumulativeDays[month - 1];
  return { month, day };
}

🔒 2. Privacy-First Architecture: Zero-Knowledge by Design

National Identity Cards are sensitive PII under privacy frameworks like Sri Lanka's Personal Data Protection Act (PDPA) No. 9 of 2022, and the GDPR.

Most "free" decoding utilities quietly send your input to /api/decode, or log it in an analytics payload. For NIC Info, I built an air-gapped client runtime instead:

┌──────────────────────────────────────────────────────────┐
│ Browser process memory (100% client-side)                │
│                                                          │
│ [User input] --> [Regex validator] --> [Parser engine]   │
│                                              |           │
│ [Result card] <-- [Chronology diff] <-------+            │
└──────────────────────────────────────────────────────────┘
                            |
                    NO NETWORK TRANSMISSION
                            |
┌──────────────────────────────────────────────────────────┐
│ External edge (Vercel)                                   │
│   - Static HTML/CSS/JS delivery only                     │
│   - Zero logging, zero PII ingestion                     │
└──────────────────────────────────────────────────────────┘

🔒 Zero-knowledge guarantee — nothing typed into NIC Info ever leaves the browser. There's no API endpoint to hit, no analytics event to fire, and no server-side log where a stray NIC number could end up.

Key security implementations:

Zero external API calls — the decoding engine runs entirely in synchronous browser memory
Zero form submissions — everything is wired to reactive DOM listeners (input, keydown)
Hardened HTTP headers, configured at the edge:

{
  "headers": [
    { "key": "X-Frame-Options", "value": "DENY" },
    { "key": "X-Content-Type-Options", "value": "nosniff" },
    { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
    { "key": "Permissions-Policy", "value": "camera=(), microphone=(), geolocation=()" }
  ]
}

⚡ 3. The Pure Vanilla Stack: Zero Bundlers, Zero Frameworks

It's tempting to reach for React, Next.js, or Vue even for a single-purpose utility. But for a tool people open on a patchy mobile connection, every kilobyte of JavaScript is a tax on load time.

NIC Info is built with plain semantic HTML5, vanilla CSS3, and ES6+ — no bundler, no framework, no build step.

Metric	Framework app (e.g. Next.js)	NIC Info (vanilla)
JavaScript payload	~180 KB – 450 KB (gzipped)	< 6 KB (unminified)
First Contentful Paint (FCP)	0.8s – 1.4s	0.2s
Interaction to Next Paint (INP)	40ms – 120ms	< 8ms (instant)
Lighthouse score	85 – 92	100 / 100

Real-Time Chronological Age Calculation

Alongside the date of birth, the tool computes a precise, human-readable age breakdown — years, months, and days — using proper month-borrowing arithmetic:

function calculatePreciseAge(birthYear, birthMonth, birthDay) {
  const now = new Date();
  let years = now.getFullYear() - birthYear;
  let months = (now.getMonth() + 1) - birthMonth;
  let days = now.getDate() - birthDay;

  const daysInMonth = [0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31];
  const isLeap = (y) => (y % 4 === 0 && y % 100 !== 0) || (y % 400 === 0);

  if (days < 0) {
    months--;
    let prevMonth = now.getMonth(); // 0-indexed previous month
    let prevYear = now.getFullYear();
    if (prevMonth === 0) {
      prevMonth = 12;
      prevYear--;
    }
    const daysInPrev = (prevMonth === 2 && isLeap(prevYear)) ? 29 : daysInMonth[prevMonth];
    days += daysInPrev;
  }

  if (months < 0) {
    years--;
    months += 12;
  }

  return { years, months, days };
}

🎨 4. Editorial "Registry Office" Design System

Utility apps don't have to look like a generic Bootstrap table. I wanted NIC Info to feel like an authentic archival registry ledger, filtered through a modern Cupertino-style aesthetic.

Typography & Colors

Serif headings: Fraunces, a variable font, brings a warm, authoritative "government ledger" feel
Monospace elements: IBM Plex Mono keeps numeric identification codes tabular and aligned
Palette: deep archival navy (#0B1118), warm parchment gold (#C9A15C), and slate borders

:root {
  --bg-primary: #0F172A;
  --surface-card: #1E293B;
  --accent-gold: #C9A15C;
  --accent-teal: #4F8B82;
  --text-main: #F8FAFC;
  --font-serif: 'Fraunces', Georgia, serif;
  --font-mono: 'IBM Plex Mono', monospace;
}

.result-card {
  background: var(--surface-card);
  border: 1px solid rgba(201, 161, 92, 0.2);
  box-shadow: 0 20px 40px -15px rgba(0, 0, 0, 0.5);
  backdrop-filter: blur(12px);
  border-radius: 16px;
}

Micro-Interactions & Usability

Auto-decoding as you type — the input detects a completed 10-character (941234567V) or 12-digit (199412345678) string and decodes it instantly, no submit button required
Interactive sample chips for one-tap testing of edge cases (leap years, voter flags, female day offsets)
Web Share API for one-tap sharing to WhatsApp, X, or the native OS share sheet

- PWA-ready via `manifest.json`, installable on desktop and mobile

🚀 5. Try It Out & Contribute

The full codebase is open-source under the MIT license:

🌐 Live app: nicinfo.vercel.app
📚 Format guidelines & spec: nicinfo.vercel.app/guidelines.html
pubudutharanga / NIC-Info

A free browser tool for decoding Sri Lankan National Identity Card numbers.
🇱🇰 NIC Info

High-Performance, Privacy-First Sri Lankan National Identity Card Decoder

Instant demographic extraction, precise age breakdown, and dual-format conversion for Sri Lankan National Identity Cards.
Built with pure modern web standards, zero third-party dependencies, and an air-gapped zero-knowledge client architecture

Explore Web App • Format Guidelines • Privacy Notice • Operating Policy • LLMs Specification

📖 Executive Summary

NIC Info is a client-side utility engineered to decode, parse, and validate Sri Lankan National Identity Card (NIC) numbers in real time. Designed with a bespoke "Registry Office" visual aesthetic, it provides instantaneous conversion of legacy (9-character) and modern (12-digit) identity card numbers into structured demographic profiles—extracting birth dates, exact age hierarchies, gender classifications, and administrative voter designations.

🌟 Why NIC Info?
- 🔒 Zero-Knowledge Privacy: 100% of data processing occurs exclusively within the local browser runtime. No identity identifiers are ever transmitted across a network, logged, or cached externally.
- ⚡…
View on GitHub

What's next on the roadmap

[ ] Multilingual localization (Sinhala සිංහල, Tamil தமிழ்)
[ ] Educational CSV batch-verification mode for administrative workloads (still 100% client-side)
[ ] Printable / downloadable demographic ID cards in vector SVG/PDF format

💡 Key Takeaway for Developers

You don't need an 80MB node_modules folder or a distributed backend cluster to build something valuable and fast.

Understand your domain deeply, respect user privacy by default, and write clean, standards-compliant code — and you can ship something that boots in sub-milliseconds and never puts your users' data at risk.

Did you find this breakdown helpful? I'd love to hear your own edge cases or decoding war stories in the comments below. 👇

Generative Engine Optimization (GEO): A Developer's Guide to Getting Cited by AI

Pubudu Tharanga Abewarna — Mon, 17 Aug 2026 08:21:40 +0000

Open Google today and the first thing on the page usually isn't a blue link — it's a paragraph the AI wrote, with a handful of small citations tucked underneath. Ask ChatGPT, Claude, or Perplexity the same question and there's no results page at all. You just get the answer.

That shift has created a discipline sitting next to SEO, not replacing it: Generative Engine Optimization, or GEO.

TL;DR

SEO competes for a spot among ~10 blue links. GEO competes for one of the ~2–7 sources an AI actually cites.

AI systems usually lift a single paragraph or sentence from a page, not the whole thing — structure matters more than ever.

Ranking #1 on Google no longer guarantees an AI will mention you.

The fixes aren't exotic: answer-first writing, real numbers, less hype, extractable formatting, fresh dates, off-site reputation — plus a couple of developer-specific moves like fixing your robots.txt.

What Is GEO, Exactly? 🎯

Generative Engine Optimization is the practice of structuring content so AI systems — ChatGPT, Claude, Gemini, Perplexity, Google's AI Overviews — can find it, trust it, and cite it while generating an answer. Princeton researchers coined the term in 2023, and the industry has spent the years since arguing about what to call it. You'll also see AEO (Answer/AI Engine Optimization), AI SEO, and LLMO (large language model optimization) used more or less interchangeably. Nobody's fully settled on one name. Everyone's chasing the same goal: get cited by the system now standing between you and your reader.

The mental model that matters: SEO optimizes for a click. GEO optimizes for a mention.

SEO vs. GEO: What Actually Changed

	SEO	GEO
Competing for	A spot among ~10 blue links	One of ~2–7 sources an AI cites
Unit that gets judged	The whole page	A single paragraph or sentence
Success looks like	A click to your site	A citation — the click is optional
What earns it	Keywords, backlinks, technical SEO, page experience	Clear answers, real data, structure, off-site trust
Being #1 guarantees	Strong visibility	Nothing. The model decides independently

Why This Is Suddenly Everyone's Problem 📉

The numbers back this up. Depending on whose research you trust, somewhere between 58% and 68% of Google searches in the US now end without a click to an outside site — and when an AI Overview shows up on the page, that number climbs past 80%. Pew Research found that people click through on a source cited inside an AI Overview only about 1% of the time.

That's not the whole story, though. Seer Interactive's research found that brands who do get cited inside AI Overviews still pull in roughly 35% more organic clicks than brands who don't appear at all. The traffic didn't vanish — it consolidated around whoever gets mentioned.

This is spreading past consumer search, too. By some industry estimates, somewhere between a third and half of B2B research queries now start inside an LLM chat window instead of a search bar.

How AI Engines Actually Decide What to Cite 🔍

Here's the part that trips up a lot of developers: an AI engine doesn't just paste your question into a search box. Ask "what's the best VPN for streaming in Europe" and the model quietly breaks that into several smaller searches — something like "best VPN 2026," "VPN streaming speed comparison," and "VPN server locations Europe" — runs each one separately, then synthesizes an answer from whatever comes back across all of them. This is often called query fan-out, and if you've built a RAG (retrieval-augmented generation) pipeline yourself, it'll look familiar. It's the same pattern, just running one layer up, outside your control.

The practical consequence: your page doesn't need to rank #1 for one target keyword anymore. It needs to be the best-structured answer to any of the sub-questions the model might generate along the way. Trackers that measure the overlap between classic top-10 rankings and the sources AI engines actually cite report that overlap shrinking fast — some analyses put it dropping from roughly three-quarters down to under 40% over the past couple of years. Ranking well still helps. It's just no longer sufficient on its own.

The GEO Playbook: 8 Things You Can Do This Week 🛠️

1. Answer first, explain second

Put the actual answer in the first sentence or two, then back it up — classic inverted-pyramid structure, and exactly what a generative engine is trying to extract.

Buried: "Choosing the right database is one of the most consequential decisions a team makes, with many trade-offs to weigh — scalability, consistency, ecosystem maturity, long-term cost. In this piece we'll walk through several options before landing on a recommendation."

Answer-first: "For most new web apps, Postgres is the safest default — it covers relational and JSON workloads, has mature tooling, and scales further than most teams expect to need. Here's why, and when you'd reach for something else."

Both say roughly the same thing. Only one of them is quotable as a standalone answer.

2. Trade adjectives for numbers

"Extremely fast" gets filtered out. "40ms p95 latency across three regions" gets cited, because it's specific and checkable. Princeton's original GEO research found that adding concrete statistics, citing sources, and including direct quotes from credible people improved a page's odds of being cited by roughly 30–40% over unoptimized content. Specificity isn't just more persuasive to people — it's more retrievable by machines.

3. Kill the marketing voice

"World-class," "industry-leading," "revolutionary" — language that reads as a claim rather than a fact tends to get quietly discounted. Write the way you'd explain something to a smart colleague who has no reason to trust your adjectives: plainly, specifically, trade-offs included. The more neutral the tone, the more it reads as information instead of an ad — which, counterintuitively, makes it more persuasive.

4. Format for extraction, not for scrolling

AI systems typically lift one paragraph or one table row, not your whole page. Give them clean units to grab: short paragraphs, one idea per section, descriptive headers, comparison tables, and an FAQ block phrased the way people actually ask questions. If you wouldn't be comfortable pasting a single paragraph into a chat window as a standalone answer, it probably isn't extractable yet.

5. Timestamp everything

Generative engines weight freshness heavily, especially for anything volatile — pricing, statistics, version numbers, "best of" lists. Add a visible "Last updated" date, and actually update the numbers when you touch the page. An honest range from last month usually beats a precise-looking stat from two years ago.

6. Build a reputation the AI can find off your site

These systems don't only read your own copy — they weigh what Reddit threads, forums, review sites, and independent comparison articles say about you too. A page that claims "we're the best" carries little weight. A Reddit thread full of people independently agreeing carries a lot. Community reputation is now part of technical SEO, not a separate marketing workstream.

7. Check whether the bots can even reach you

This is the one developers skip and shouldn't. Most AI providers now run at least two kinds of crawler: one that harvests pages for model training, and one (sometimes two) that fetch pages live to answer a specific question and cite it. Blocking the wrong one quietly removes you from AI answers without you ever noticing.

Anthropic's current documentation, for example, splits Claude's crawling into three named bots: ClaudeBot (training data collection), Claude-SearchBot (indexing for Claude's search features), and Claude-User (fetching a page in real time because a person asked Claude a question that needed it). Anthropic states all three honor robots.txt — including Claude-User, which is a stronger commitment than some other providers make for their user-triggered fetchers. OpenAI runs a comparable split with GPTBot, OAI-SearchBot, and ChatGPT-User; Perplexity runs PerplexityBot for indexing and Perplexity-User for retrieval.

A reasonable starting point — allow retrieval and citation, opt out of training only if that's a deliberate policy choice:

# Traditional search — leave these open
User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /

# Live retrieval + citation bots — these fetch a page to
# answer a specific question and cite it. Block these and
# you disappear from AI-generated answers.
User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: Claude-User
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

# Model-training bots — harvest content for future training
# runs. A data-policy decision, not a GEO one: blocking
# these doesn't affect today's citations.
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Sitemap: https://yoursite.com/sitemap.xml

Bot names change — Anthropic, OpenAI, and Perplexity have all deprecated or added user-agents in the past two years (Claude-Web and anthropic-ai are both retired). Verify the current strings in each provider's official docs before you ship this, and check your server logs afterward to confirm you got it right.

8. Mark up the facts a machine can quote directly

Structured data (schema.org via JSON-LD) turns your key facts into something a machine can parse without guessing at meaning. It won't guarantee a citation, but it removes ambiguity about what your page is actually claiming — especially useful for FAQs, specs, and how-tos:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is Generative Engine Optimization?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "GEO is the practice of structuring content so AI systems like ChatGPT, Claude, and Perplexity can find, trust, and cite it when generating an answer."
      }
    }
  ]
}

Where llms.txt Actually Fits 📄

You've probably seen /llms.txt described as "robots.txt, but for AI." It's a proposed convention — a markdown file at your site's root summarizing your most important pages in a format built for LLMs to skim instead of parsing full HTML.

The honest state of it: it's a community convention, not a ratified standard, and no major AI lab has publicly committed to reading it for search citations. Google's webmaster team has said outright that it doesn't use llms.txt, comparing it to the old meta-keywords tag. Large studies of live sites put adoption around one in ten, and traffic analysis shows major AI crawlers overwhelmingly skip the file and crawl HTML directly anyway.

So is it worth doing? Probably — for a different reason than "citations." It costs about an hour, and it's a genuinely useful entry point for AI coding agents and assistants that need to navigate documentation efficiently: a curated "here's what actually matters" map rather than a ranking lever. Treat it as cheap hygiene, not a growth strategy.

Measuring Whether Any of This Is Working 📊

Traditional analytics mostly can't see this activity — a citation inside an AI answer often generates zero referrer traffic. A newer category of "AI visibility" tools has emerged to track how often a brand gets mentioned across ChatGPT, Claude, Perplexity, and AI Overviews for a set of target queries, similar to how rank trackers work for classic SEO.

You don't need to buy one to start, though. Pick the 10–20 questions you most want to be the answer to, ask them yourself across a few AI assistants once a month, and note who gets cited. It's manual, but it's free — and for the first few months, it'll tell you more than a dashboard will.

The Bottom Line 🧭

None of this replaces SEO. You still need a technically sound, well-linked, genuinely useful site, because AI engines still lean heavily on the same trust signals search engines always have. What's changed is the target. You're no longer optimizing a page to outrank nine competitors for a spot on a results page — you're optimizing an answer, competing to be the source an AI trusts enough to quote when nobody's looking at a results page at all.

Have you checked whether AI crawlers can actually reach your site? Point 7 is the highest-leverage five minutes on this whole list — I'd genuinely be curious what you find in your logs.

Coding is Dying? No, It’s Evolving into "Agentic Architecture" (2026 career shift)

Pubudu Tharanga Abewarna — Sat, 31 Jan 2026 07:39:29 +0000

Author's Note: I originally posted this analysis on LinkedIn, where it sparked a massive debate (100k+ views in 4 days) about the future of Junior Devs. I’m sharing the technical breakdown here, but the real discussion with senior engineers is happening on the original thread.

We are moving past the "GitHub Copilot era" (which just suggests the next line) into something much more disruptive: The Agentic Era.

As an Information Systems undergraduate, I've been analyzing tools like Google Antigravity (Gemini 3) and Claude Opus 4.5
The pattern is clear: we are no longer just writing code; we are managing agents that write it for us.

Here is why the "Junior Developer" role is about to change completely.

1. What is "Antigravity"? (The Agentic Shift)

Most of us are used to Autocomplete: you type function sum, and it suggests (a,b).

Agentic Development is different. You don't type code; you assign a ticket. You act as an Engineering Manager.

The Workflow: You tell the agent, "Refactor the login auth to use NextAuth v5."
The Agent's Job: It plans the steps, edits 10+ files across the repo, runs the terminal commands to install packages, and tests the output.
Your Job: You spend 40% of your time reviewing its work, not typing.

2. The New Skill Set: "Architects" vs. "Typists"

If an AI agent can handle the syntax and the terminal, what is left for us?
The barrier to entry has lowered, but the barrier to mastery has skyrocketed.

To survive this shift by 2026, students and juniors need to pivot immediately:

🛑 Stop Memorizing Syntax

Knowing how to write a generic for loop from memory is becoming irrelevant.

✅ Start Learning Architecture

You need to decide how the data flows.

Why use a Relational DB here instead of NoSQL?
Should this be a Server Component or Client Component? The AI can build the house, but if you give it a bad blueprint, the house will collapse.

✅ Master Security Auditing

Agentic AI is powerful but prone to hallucinations. It might write working code that is completely insecure (e.g., leaving an SQL injection vulnerability).
You must be the auditor. If you don't understand the underlying security principles, you won't spot the invisible doors the AI left open.

3. The "10x Developer" Opportunity

This isn't doom and gloom. This is leverage.
A single developer can now act as a full team.

Frontend: Handled by Agent A.
Backend: Scaffolded by Agent B.
Deployment: Managed by Agent C.

The future belongs to AI Orchestrators—developers who can chain these agents together to build massive systems that used to require a team of five.

💬 Join the Debate

I'm seeing this shift start to happen in experimental workflows, but I'm curious about the industry reality.

Senior Devs: Are you trusting AI agents with "write access" to your repositories yet? Or are we still strictly in the "read-only" assistance phase?

The comment section here is open, but the most active discussion is happening over on the LinkedIn thread.

👉 Click here to read the Senior Dev comments on LinkedIn