CitizenssApp: A Platform for Digital Rights and Empowerment Through Table-First Software Design

White paper like: https://doi.org/10.5281/zenodo.16259916

CitizenssApp: A Platform for Digital Rights and Empowerment Through Table-First Software Design

Introduction: Table–Column–Row (TCR) as a Digital Right
CitizenssApp is a platform built entirely on the Table–Column–Row (TCR) model – the same intuitive format found in everything from paper ledgers to spreadsheets. The idea is simple but powerful: if a person can draw a table with rows and columns, they should be able to create and use software. In the analog world, every citizen could record information with pen and paper; in the digital world, that same simplicity should exist[1]. CitizenssApp treats basic data operations (CRUD – Create, Read, Update, Delete) as a fundamental digital right rather than a complex programming task. “Digital empowerment is no longer a privilege—it is a fundamental need for every citizen. CRUD is the new pen and paper.”[2] The platform’s vision is to democratize software creation by removing cost, complexity, and dependency, much like how universal literacy made reading/writing accessible to all[3][4]. Lack of access to simple app functionality today creates digital exclusion[5], so CitizenssApp frames basic software literacy as a necessity, empowering individuals and communities to build their own solutions.
Under the hood, everything in CitizenssApp – data models, user interface, logic, and workflows – is represented in structured tables. There is no hidden code or proprietary file format; the entire system is declarative, inspectable, and editable – just like a spreadsheet[6]. By using the universally understood tabular format, CitizenssApp ensures a zero abstraction barrier between users and their software: what you see (in the tables) is what the application does, with no opaque layers[7][8]. This design aligns with how real users think and work. In fact, most users already understand that tables = interfaces, columns = fields, and rows = records in everyday tools[9]. By speaking the native language of tables (the lingua franca of programs like Excel), CitizenssApp leverages familiar concepts so that anyone who understands spreadsheets can build software[10]. Academic research underscores the wisdom of this approach: spreadsheets have long been “the tool of choice for ad-hoc tabular data management… especially by non-programmers” due to their direct manipulation and intuitive UI. There are an estimated 750 million to 1.2 billion Excel users worldwide, with Google’s G Suite (including Sheets) reaching ~2 billion monthly users. This ubiquity confirms that tabular data representation is universally understood, making it an ideal foundation for a citizen-centric platform. CitizenssApp elevates the humble TCR model from a data format to a vehicle of digital autonomy – giving individuals agency over their data and applications. In essence, it treats software creation and data control as a Minimum Digital Right (MDR) for everyone, analogous to how open-source and self-sovereign data movements emphasize user control.
 
Vision Overview:
CitizenssApp’s design is guided by an ambitious multi-point vision that can be grouped into several core themes. Together, these features enable full-stack application creation within the TCR paradigm, from data definition to UI to sharing. Below we discuss these pillars of the platform’s vision:

1. Full SQL Support – DDL, DML, DQL, DCL, TCL: In CitizenssApp, users interact primarily through a visual table interface, based on the universal TCR (Table–Column–Row) structure. This is the only UI users need — not forms, not code — and it resembles an Excel-like experience where both data and structure evolve together. There is a metadata editor available for power users, but it is never mandatory. The preferred interface is the data-first, Excel-like table that lets users start entering data immediately and evolve structure naturally. This flexibility allows any user to move between structure and content seamlessly—just like they would in a spreadsheet—but with the power of metadata and modular app design behind the scenes. CitizenssApp supports full SQL capability (DDL, DML, DQL, DCL, TCL), but not for traditional database operations. Instead, these command families operate over metadata to define structure, logic, and behavior. DDL-Creates or modifies metadata definitions, do not create physical tables, DML-Captures row edits through the UI and updates stored records, DQL-Enables dynamic filters, lookups, joins, unions on metadata-defined tables, DCL-Controls who can view, edit, or share TCRs, and TCL-Supports undo/redo, checkpoints, and safe changes. All data and metadata are saved to the user’s preferred storage — flat files, JSON, SQLite, cloud sync — without enforcing a relational database backend.
   User-first design: Like Excel, users can begin with rows and columns, then shape structure as needed.
   Metadata lives behind the table: Users don’t have to think about schema—but it’s always there and editable.
   Advanced logic possible: Lookups, joins, prompts, and AI-generated enhancements operate cleanly on metadata.
   No database lock-in: Everything works without requiring SQL Server, PostgreSQL, etc.
   Role-based control: Organizations can govern what each user can see, edit, or connect via permissions.
   In CitizenssApp, the table is the app. SQL is the logic. Metadata is the contract.

2. Table-First UI with Templates, Charts, and Formulas: Every aspect of application functionality in CitizenssApp is represented and managed through tables and their associated metadata. This table-first philosophy applies not just to data, but also to configuration, presentation, and logic. Even business rules and interface definitions are captured as rows within metadata tables — much like how a spreadsheet defines a layout through cell properties. There is no separate visual GUI builder. Instead, everything that might traditionally be called a “UI” is represented as a set of editable tables. The platform simply renders these metadata tables as interactive views. This approach is a practical example of a metadata-driven table experience, offering adaptability, scalability, and maintainability — without the rigidity or overhead of hand-coded interfaces.
   As one industry guide puts it:
   “When UIs are in constant flux and hardcoding becomes impractical, metadata-driven approaches step in. They leverage metadata to enhance adaptability and flexibility.”
   In CitizenssApp, what might otherwise be described as forms or screens are instead just structured tables.
   Users — or the AI — can adjust these tables directly or via prompts, and the app behavior updates accordingly. Formatting (e.g. colors, layouts) and formulas (e.g. calculated fields or validations) are also handled tabularly. This mirrors the Excel paradigm, where styling and formulas live visibly in cells — not hidden in code. Because formulas and logic are stored as structured metadata, they remain transparent, editable, and free of “black box” behavior. Users add or modify rows to build visualizations — just as they would in Excel or Google Sheets. By combining template-driven table definitions, spreadsheet-like logic, and declarative visualizations, CitizenssApp delivers much of the analytical power of modern spreadsheets — but in a governed, modular, and multi-table environment. Unlike monolithic spreadsheets that slow down with large data volumes or complex cross-referencing, CitizenssApp supports multi-table schemas, relational joins, and scalable metadata execution — leveraging its structured architecture to handle millions of records efficiently. The result is a platform that feels as familiar as Excel — but far more powerful, scalable, and shareable. Anyone who understands a spreadsheet can build and evolve apps using tables.

3. Storage Independence and Integration Principles: One of the foundational design principles of CitizenssApp is that storage should never be a barrier to user adoption, flexibility, or empowerment. The system is intentionally designed to decouple data storage from data interaction, allowing users to define, manage, and evolve their applications without needing to understand or configure backend infrastructure.

Key Principles
Storage Should Not Be a Barrier
Users must be free to focus on what they want to capture — not how it’s stored. Storage is treated as a backend detail, not a constraint on creativity or access.

Storage-Agnostic Architecture
CitizenssApp operates with complete independence from storage type. Users can store data and metadata in any format, including:
Flat files (e.g. .json, .csv)
Binary formats
Relational databases (e.g. SQLite, PostgreSQL)
NoSQL databases
Excel files
Universal Data Import
Any compatible data source can be imported and rendered as a table, regardless of origin. Once imported, the data becomes part of the TCR environment — accessible through prompts, queries, and templates.

Flexible Data Export
Users can export data in multiple formats, including:
JSON
CSV
Excel
SQL-compatible dumps
Binary archive formats
This ensures portability, backup, and integration with external systems — without vendor lock-in.
Default Local Storage
By default, all user data is saved in structured file formats on the local device where CitizenssApp is installed. This default provides offline access and ensures ownership. However, users can configure alternative storage targets as needed — such as cloud sync folders, databases, or enterprise file systems.
This storage model empowers users to capture and manage information in a way that is secure, flexible, and entirely under their control.
The focus remains on simplicity at the point of entry and power at the point of integration.

1. Prompt-Driven AI Querying and Schema Generation: A standout feature of CitizenssApp is its integration of AI to make table interactions even more natural. Users can describe what they want in plain language – whether it’s a query to retrieve information or a specification for a new table – and the system’s prompt/AI engine will handle the technical translation. For example, a user might ask, “Show me all customers who signed up this month and their purchase totals,” and the platform’s AI can generate the appropriate SQL SELECT join query behind the scenes. This is essentially a text-to-SQL capability, an area of active research and growing real-world use. Large language models (LLMs) have demonstrated an impressive ability to serve as natural language interfaces to databases (NLIDBs), converting user questions into executable queries. Surveys find that integrating LLMs in text-to-SQL systems can “bring unique opportunities and improvements” to accessibility of data, helping bridge the gap for non-technical users. CitizenssApp builds on these advances to let users retrieve and manipulate data simply by asking, without needing to know the SQL language. But the AI integration goes further – it also assists in schema generation and data modeling. Users can literally prompt the system with a description of an application or data structure they need, and the AI will propose a table schema (or even a set of related tables) to match. This is a huge leap in approachability: instead of manually deciding tables, columns, and types (or using a separate ER diagramming tool), a user might say “I need to track students, with their name, age, and a list of courses”, and CitizenssApp will create the appropriate tables (e.g. a Students table and maybe an Enrollment table for courses) on the fly. Recent developments in multi-modal LLMs by industry leaders show exactly this workflow is feasible – for instance, Google researchers demonstrate passing inputs like text and even images of ER diagrams into an LLM (Gemini) to automatically “suggest or even generate schema layouts, simplifying the laborious process of implementing the data model”. CitizenssApp leverages such capabilities to make the Prompt-to-Schema pipeline seamless: the user describes requirements, the LLM outputs a Data Definition (in JSON or SQL), and the platform instantiates those tables.

Prompt-to-schema generation pipeline. In this pipeline, a user’s natural language request (e.g. “Create a student table with Name and Age”) is parsed by an AI co-pilot that generates the structured metadata for the new table (Key Value Pair). CitizenssApp then automatically creates the table and integrates it into the app. By iterating with further prompts (e.g. “Add an Enrollment table linked to Students”), users can progressively design a complex schema conversationally, with the AI handling the syntax. This dramatically lowers the barrier for robust database design; it’s like having a smart assistant who instantly converts your ideas into working app components. The prompt-driven approach also covers querying and reporting – users can ask questions in plain English and get answers or charts as if they were using a search engine, while under the hood the system ensures the accuracy by pulling live data (thus avoiding the hallucination problem by grounding answers in the database). The combination of natural language interfaces with the structured transparency of TCR is potent: the AI makes it easy to generate content, but all results become tangible tables that the user can inspect and tweak, thereby remaining in control. This aligns with the platform’s ethos of AI as a co-pilot, not a black box. For instance, if the AI creates a table schema, the user can review that schema in the metadata tables and adjust any columns if needed – effectively collaborating with the AI. This synergy of AI and tabular data is forward-looking: it suggests even non-programmers can perform sophisticated tasks like designing a new app database in minutes, something traditionally requiring an experienced engineer. Google’s work with BigQuery confirms this direction, noting that flexible, modular data models can be created by multimodal LLMs in a few steps. Likewise, text-to-SQL research indicates an NLIDB can empower “non-skilled users to access structured databases like professional DB engineers”, making data more democratic. CitizenssApp incorporates these advancements to truly let prompts drive the process – from schema creation to data analysis – amplifying user productivity and lowering the learning curve.

1. Multilevel and Nested TCR Structures (Metadata Modeling): While simplicity is paramount, CitizenssApp also recognizes that real-world data can be hierarchical or linked in complex ways. The platform supports multilevel and nested structures of tables, all still within the TCR framework. This is achieved through a flexible metadata model (codenamed PayanarssType in the research prototype) that can describe not only flat tables but also relationships between tables – including parent-child hierarchies, many-to-many links, and even arbitrary graph structures of data entities[14]. In practice, this means users are not limited to a single spreadsheet or flat list; they can create, for example, a Department table with a nested sub-table of Employees, or a Projects table that links to Tasks and Subtasks, and so on, to any depth needed. The metadata model captures these relationships with fields like parent IDs, types, and attributes for each entity[15][16]. Because the entire schema is represented in tables, the notion of nesting simply becomes another set of rows linking one table to another. CitizenssApp’s UI will then allow navigation or display of these nested levels in an intuitive way (for instance, showing sub-records indented under a record, or enabling drill-down views – similar to how a tree or graph of data might appear in an outline). This capability is crucial for modeling real-world scenarios that are hierarchical (think organizational charts, file directories, categories and subcategories, etc.) or networked (like social graphs or linked datasets). Traditional spreadsheets struggle with this – they are essentially 2D grids. Traditional databases handle it via foreign keys and join tables, but that requires schema planning. CitizenssApp gives the best of both: the user can add a hierarchy or relationship on the fly (just by adding a reference in the metadata that one table is parent of another), and the system will enforce and present it accordingly. The PayanarssType structure ensures consistency and referential integrity beneath the surface. This approach echoes the concept of metadata-driven schema used in some enterprise tools: for example, Salesforce’s platform uses metadata to define object relationships, and low-code tools often allow “object” definitions that include fields and links. CitizenssApp’s innovation is making this both dynamic and user-facing – the user directly edits the metadata if they want, as opposed to filling forms in a closed designer. Academic context also supports the value of such dynamic modeling: metadata-driven systems can adapt to evolving data needs more easily than hardcoded schemas. By enabling multiple hierarchical relationships, CitizenssApp can represent complex data architectures (trees, graphs, cross-links) within a single coherent TCR universe[17]. This is part of treating “LCNC (low-code/no-code) as table-first” – rather than forcing visual ER diagrams or code, everything is a table that defines another table[18][19]. For the user, it feels like extending a spreadsheet with new tabs that reference each other, except with much more powerful linkages and without the spaghetti of cell references. All of this is done in plain sight: “all metadata can be stored, shared, and versioned easily” because it’s in a tabular format[20]. That opens up possibilities like exporting your entire app schema as a simple JSON or CSV, or applying version control to your app’s structure – things rarely possible with GUI-based app builders. In summary, CitizenssApp’s metadata-centric approach allows for modular, nested data design that grows in complexity only as needed, all while remaining transparent and editable by the user.
2. Metadata-Based Logic and Configurability: Not only data schemas and UIs, but also application logic is configured through metadata. This includes validation rules, conditional behaviors, automations, and workflows. For example, if you want a rule “when status = X and amount > Y, send an email notification,” you would not write code – instead you’d fill a column/row in a “Logic Rules” table or similar, capturing the condition and action. This philosophy is in line with many rules engines and low-code workflow tools, but again the difference is that here it’s all exposed as tables. The benefit is twofold: (a) Transparency – users and auditors can see all the business logic in one or few tables (nothing hidden in scripts or flowchart diagrams), and (b) Editability – updating a rule is as easy as editing a spreadsheet cell. In fact, CitizenssApp emphasizes that “all behavior is represented as visible tabular data, not opaque code,” making the system auditable and trustworthy[21]. If something goes wrong or an output is unexpected, the user can inspect the relevant metadata table to trace the logic, much like debugging a formula sheet. This approach turns application development into a configuration exercise where everything is driven by data, which resonates with the idea of declarative programming in a user-friendly form. It’s also inherently suited to AI assistance: since the logic is in tables, an AI can suggest new rules or optimize them (for instance, the AI could detect contradictory rules or unreachable conditions by analyzing the tables). This is part of the vision for AI-assisted co-creation, where the system might prompt “It looks like you’re trying to enforce a limit on attendees – here’s a suggested rule to add.” The synergy between AI and metadata is powerful because the AI’s suggestions can directly map to adding new rows in a config table (a straightforward task)[22]. In contrast, many current no-code tools use visual flowcharts for logic; those can be harder to modify in bulk or analyze automatically. Metadata tables, on the other hand, are machine-readable by design, enabling features like prompt-based logic generation (e.g., “If a task is past due, mark it red” could create a conditional formatting rule entry). This ties back to the earlier points: the entire system stays within the uniform metaphor of tables, ensuring every aspect of an app (data, UI, logic) is both accessible to the user and to computational helpers.
3. Secure, Permission-Based Sharing Across Individuals and Organizations: Empowerment goes hand-in-hand with control – especially when it comes to data security and sharing. CitizenssApp is built to allow secure, permissioned sharing of data and app components between users, whether they are individuals or part of organizations. Unlike a personal spreadsheet, which you might share via email or a broad link (often leading to version chaos or privacy risks), CitizenssApp provides a structured way to share exactly what you want and no more. Every table or even row can have permissions attached, much like robust databases support row-level security policies where access to specific rows can be restricted based on user roles or groups. In CitizenssApp, these permissions are also managed as metadata: there might be a “Permissions” table specifying that User X can read Table Y but not write, or that Org A can share only aggregated data with Org B, etc. The platform likely implements the full spectrum of Data Control (DCL) capabilities through a user-friendly interface – meaning you could, for example, create a share link for a dataset that only exposes certain columns or records, with encryption and integrity checks in place. Indeed, one of the project’s stated principles is “Metadata Sharing as a Digital Right with Integrity Protection”[23] – implying that when you share your app’s data or structure, the system ensures it cannot be tampered with in transit and that you retain ownership. This is crucial for building trust, especially if communities are to adopt the platform for civic or personal data: they need assurance that sharing doesn’t mean losing control.

Metadata-driven and permissioned data-sharing flow. In the diagram above, User A owns a table containing potentially sensitive data (all fields shown in yellow). Through CitizenssApp, they apply a permissions metadata policy (gray note) that, for example, allows only certain columns (X, Y) to be shared and restricts some rows based on criteria (say, only entries related to a specific project). When User A shares the table with User B via the platform, this metadata policy is enforced in the shared view. User B thus sees a filtered table (yellow, on the right) containing only the permitted data. The sharing happens securely through the CitizenssApp cloud or peer-to-peer mechanism, with the platform acting as a gatekeeper that checks permissions on every query. This ensures that even if User B tries to access more data (intentionally or by accident), the system will prevent it – much like a database with built-in row/column access control denies unauthorized queries. Such fine-grained sharing is far more advanced than typical spreadsheet sharing, which usually is all-or-nothing at the file or sheet level. It lets multiple individuals or orgs collaborate while each only sees what they should. For instance, a community-maintained dataset could allow each contributor to view and edit their own rows but only see aggregated results from others – enforcing privacy by design. Or a small business could maintain a shared inventory where suppliers can update quantity fields but not view financial columns. The permissions metadata approach makes these scenarios configurable without coding. Moreover, by treating permission configurations as data, they too can be audited and transferred. One can imagine standardized permission templates (like “public summary, private details”) that users can apply. The platform’s commitment to security as a core principle is evident – not as an afterthought, but baked into the data model (with tables for user roles, encryption keys, audit logs, etc.)[24][25]. Each action can be logged, and users can even query the logs (again using the familiar table interface). In summary, CitizenssApp acknowledges that true digital empowerment means users safely sharing their creations on their own terms, and it provides enterprise-grade controls in an accessible way. This makes it suitable not just for personal use, but also for decentralized organizational data sharing – supporting both “personal TCRs” (your private data) and “centralized organizational TCRs” (shared databases for a group) as first-class scenarios.

1. Personal and Organizational Modes: The platform is designed to serve both individual users and collaborative groups or organizations. In personal mode, CitizenssApp can function like your private digital notebook/database – everything runs locally or in your personal cloud, and you have sole control. In organizational mode, multiple users’ TCRs can be linked or federated with controlled sharing as described above. One can think of each user or org as having their own “workspace” of tables, which they can choose to keep separate or integrate. This structure is reminiscent of how tools like Notion or Airtable allow personal vs team spaces, or how version control (Git) allows private vs shared repositories. CitizenssApp likely implements this via separate schema namespaces for each user/org, and then explicit bridges (sharing links or combined views) when collaboration is needed. An important aspect is scalability across these contexts – personal TCRs might run on a lightweight local database on a phone or laptop, while organizational TCRs could be hosted on a cloud server for reliability and multi-user access. The user’s experience remains the same; it’s the deployment that differs. By supporting both modes, the platform encourages a form of “think global, act local” for data: you manage your own data autonomy, but can join it with others’ when desired. This underpins the concept of Minimum Digital Rights (MDR) – you own your core digital tools (like you own personal pen & paper), and you voluntarily connect with larger systems as an equal peer, not as a dependent. It echoes the vision of data sovereignty and personal data stores where individuals keep their data and only share slices for specific purposes. For example, imagine a network of community clinics each using CitizenssApp for patient records; each clinic keeps their local TCR, but they could share anonymized summary tables to a central health board TCR to track regional trends. The system’s design would allow such partial sharing without each clinic giving up custody of their full database. This federated yet connectable architecture differentiates CitizenssApp from typical cloud SaaS offerings which often centralize everything. Instead, it’s closer to the ethos of the web itself – distributed, with standards for interoperability. The mention of using LLMs to resolve schema mismatches comes into play here: when personal or organizational databases need to work together, their schemas might differ (one person’s “Full Name” is another’s “Customer Name”). Normally, integrating these requires manual mapping. CitizenssApp envisions leveraging AI to automate this schema mapping so data from different TCRs can interoperate smoothly. For instance, when two organizations decide to share data, an AI agent could analyze their table definitions and suggest how to align them (perhaps one has separate First/Last name columns, another has one Name field – the AI can suggest a transformation). This idea is backed by emerging AI solutions in data integration: “every organization structures their CRM differently… making integrations time-consuming. An AI-powered solution can automate schema mapping, significantly reducing integration time while improving accuracy.” Researchers have developed LLM-based schema matchers that consider semantics, not just column names, to find correspondences between different databases. By incorporating such technology, CitizenssApp aims to let users merge or federate their TCRs with minimal fuss – fulfilling the promise that empowering individuals doesn’t mean creating data silos, because interoperability is maintained. In practical terms, if you import an Excel sheet or connect another Citizen’s shared table, the system could use AI to automatically join on matching fields or convert types as needed, asking for confirmation via a prompt. This dramatically lowers a key barrier in collaborative data projects: agreeing on schema upfront. With CitizenssApp, everyone can structure their own data as they see fit, and the platform will mediate the differences when collaboration happens, guided by LLM intelligence.
2. Practical Use Cases and MVP Building: CitizenssApp is not a theoretical toolkit; it is geared towards practical empowerment through quick solution building. An immediate use case is enabling anyone to create a Minimum Viable Product (MVP) app for their needs without hiring developers. Whether it’s a simple inventory tracker for a small shop, a habit tracker for personal use, or even a mini CRM for a community NGO, the platform provides all the building blocks to go from idea to working app in a short time. Thanks to features like AI-generated schema and templates, users can start from a base and iterate. For example, the system might offer AI-suggested MVP templates for common scenarios (CRM, finance, attendance, etc.)[26] – much like templates in Microsoft Access or modern no-code platforms, but enhanced by AI. The user can pick a template and then customize it to fit their exact needs (add a field, remove a module) using the table-based config, thus combining the speed of templates with the flexibility of custom development. The white paper describes an approach of “User-Defined MVP Builder” where users select what entities and features they want, and “Snapshot & Sharing” which allows packaging an MVP configuration to share or reuse[26]. The idea is to treat MVP creation itself as a right – users should be able to spin up the minimal software they need at will, rather than waiting on IT. Indeed, “Why MVP Control Should Go to the User” is explicitly discussed, highlighting reasons like personal relevance, rapid prototyping, and autonomy from gatekeepers[27][28]. In CitizenssApp, you don’t have to justify your need to a developer – you just build it. This also encourages experimentation: you can create throwaway MVPs, test them, iterate, or discard, with little cost. For more complex projects, the platform’s template registry and community contributions kick in – allowing you to leverage others’ work and not reinvent the wheel (more on that in the next section). Another major practical angle is Excel/Sheets migration. Many individuals and businesses run critical processes on spreadsheets (which are error-prone and don’t scale). CitizenssApp provides a pathway to migrate those spreadsheets into a more robust app form. A user can import their spreadsheet data into CitizenssApp tables (thereby immediately getting multi-user access, better performance, and data integrity features), and the platform can auto-generate an application around it. Think of it as “uplifting” a spreadsheet to an app: formulas come in as CitizenssApp formulas, sheets become proper relational tables, and so on. This addresses a common pitfall where people use spreadsheets as databases and suffer issues – e.g., the UK COVID tracking fiasco where Excel’s row limit truncated thousands of records. By moving to CitizenssApp, those limits disappear (Excel’s ~1 million row cap vs a database’s billions) and one gets concurrent editing with fine-grained permissions rather than emailing files. Essentially, CitizenssApp can serve as the “next step” for spreadsheet users who outgrow the spreadsheet but don’t want to write a custom application. Academic projects like DataSpread have explored unifying spreadsheets with databases to allow big data analysis with a spreadsheet front-end – CitizenssApp follows a similar spirit but goes beyond analysis to full application logic. The ability to reuse templates also shines here: if someone has already migrated a common Excel solution (say a budget planner) into CitizenssApp, others can just grab that template instead of starting from scratch. Over time, this fosters a rich library of “knowledge templates” that encapsulate best practices (like a good inventory schema or a solid project tracker). The platform’s design encourages such reuse, which not only saves effort but also creates a community of practice around digital empowerment.
3. Open Standards and Extensibility: Finally, underpinning all these features is a commitment to openness – in data formats, standards, and extensibility. CitizenssApp leverages well-known standards (SQL, JSON, etc.) to ensure that the knowledge and data within it aren’t locked away. For instance, all tables and metadata could be exportable as CSV/JSON, meaning your data remains yours and can be moved to other systems if needed. This aligns with “Open Serviceability: fixes and enhancements without lock-in”[29] – one of the core principles. The platform is intended to be open-source or at least open-plugin; users can call any developer or use any tool to extend it, analogous to owning a bicycle that any mechanic can fix rather than a proprietary car that only the dealer can service[30][31]. In the context of software autonomy, this is huge: it breaks the dependency on a single vendor or on expensive consultants for every little change. If CitizenssApp is open-source, the community can improve it collectively, much like successful projects in the civic tech space. And even if a user never looks under the hood, they benefit from a worldwide community of contributors adding features and plugins. Plugin Ecosystem and Template Sharing One of the most compelling aspects of CitizenssApp is its vision of a plugin-based ecosystem modeled after successful platforms like VS Code and WordPress, but oriented toward non-programmer “citizen developers.” The platform is not a monolithic app builder; it’s a foundation on which an open library of plugins, templates, and modules can grow – all adhering to the TCR paradigm.

Plugin-based TCR ecosystem model. Diagram: At the core is the CitizenssApp TCR Platform (blue oval), and surrounding it are various plugin categories (white boxes) that extend its functionality. These include Charts & Visualization (for adding new chart types or dashboards), AI Query/Prompt interfaces (e.g. plugins that enhance AI interactions or add domain-specific prompt capabilities), Formula/Calculation engines (perhaps custom formula functions or advanced analytics libraries), Custom UI Components (pre-built widgets or layouts that users can drop in), Integration Connectors (to link with external services/APIs), a Template Library (collections of ready-made app templates), Security & Permissions modules (e.g. support for OAuth, special encryption features), Collaboration Tools (chat or real-time co-editing enhancements), and indeed Other Plugins for anything not covered. Each plugin in this ecosystem operates through the TCR model – meaning it reads or writes data via the table structures, and adds its UI/logic in a way that is reflected in metadata (rather than bypassing it)[32]. This is crucial: it ensures that even plugins from third-parties maintain the platform’s transparency and modifiability. For example, if someone develops a plugin for Kanban boards, under the hood it might add a “Status” column to a table and use a board-style view – but that status data is still just a column in a table that the user can access directly as well. There’s no magic hidden structure, no plugin that owns its data separately. This design echoes WordPress’s: any plugin that, say, adds a custom post type or metadata still uses the WordPress database and can be exported or manipulated by other tools. It provides “transparency, modularity, and vendor independence”[33] – users aren’t locked to a single plugin’s worldview and can mix-and-match.
The scale of this ecosystem ambition is worth noting. WordPress, for instance, has over 70,000 plugins available in its repository, offering every imaginable feature and integration[34][35]. That vast library is a major reason for WordPress’s dominance (powering ~40% of websites). Similarly, Visual Studio Code’s extension marketplace has tens of thousands of extensions, making it a flexible toolbox for developers. CitizenssApp wants to bring that same extensibility to everyday software creation. By allowing community contributors to build and share plugins and templates, the platform’s utility can expand exponentially. One could foresee a template store where users share apps for common needs (ERP, school management, inventory, personal finance, etc.), and a plugin store for connectivity (e.g. a plugin to sync a table with a Google Calendar, or to integrate a payment gateway, or to add mapping capabilities using an open data standard). Because everything is table-centric, many plugins might actually just be templates plus a bit of scripting – easily created by power users. And since the core system is open and declarative, even relatively complex extensions can be understood and forked by others.
A key category of extensions is the Reusable Template. CitizenssApp explicitly lists “Templates (Invoice, CRM, Travel, Student Attendance, etc.)” as a form of plugin asset[36]. Templates are essentially packaged sets of tables + metadata that solve a particular problem. The platform likely includes a registry for these, so users can discover and import a template, which will instantiate the necessary tables/columns and UI for them. Once imported, a template becomes the user’s own app instance which they can further tweak (truly owning it). This is empowering – it’s like getting a head-start based on others’ expertise. For example, an “Invoice Management” template might come with tables for Invoices, Clients, Items and with formulas for tax and totals, plus a pre-built invoice PDF report. Rather than start from scratch, a small business could install this and immediately use or adapt it.

Template registry lifecycle. The diagram illustrates the life-cycle of a template in the CitizenssApp ecosystem. It starts with a template created by a user or developer (top oval) who designs a useful app configuration. They publish it to the Template Registry (right oval) along with version info and documentation. Now other users (left oval) can browse and install the template via the registry. Upon installation, a user gets a copy and can use the template for their needs (bottom left oval). They will inevitably customize it (bottom middle) – maybe adding a field or changing a formula to better suit their context. Now, here’s where the community aspect shines: if the user makes a useful improvement, they can publish back either an improvement suggestion or a new variant of the template (bottom right), contributing it to the registry (perhaps after review). This creates a feedback loop (curved arrow back to the registry) where templates evolve and diversify over time. It is analogous to open-source software development but for app configurations. In this way, CitizenssApp can harness collective intelligence: one person’s enhancement can benefit all. Because the templates are composed of metadata (and possibly some scripting), changes are easy to merge or compare. The platform might maintain multiple versions or flavors of templates to cater to different needs (just as WordPress has many plugins for, say, SEO with varying approaches).
It’s worth noting the inclusion of Themes and Layouts as plugin types[36]. This implies the platform supports theming (color schemes, style presets) and layout variations, enabling the community to contribute not just functional plugins but also aesthetic or usability improvements. A non-profit might share a “community edition” theme that simplifies the interface for less tech-savvy users, etc.
Perhaps most importantly, the plugin ecosystem ensures that CitizenssApp is not an enterprise-only tool or static product; it’s a living, community-driven platform. Anyone with domain knowledge can encode it into a template and share it, helping others in the community. This is vital for the mission of civic technology and NGO use: local solutions can be built by local people and then shared globally for adaptation. The platform’s tone is semi-academic and community-friendly, making it inviting for open-source contributors and researchers. Indeed, the white paper author likens CitizenssApp to “the VS Code for software users”[37] – meaning it empowers end-users in the way VS Code empowered developers, through openness and plugins. Just as VS Code has a huge community building extensions, CitizenssApp hopes to galvanize civic technologists and enthusiasts to extend its capabilities. All the while, it keeps things code-free for the user: “CitizenssApp is not a no-code platform that hides code. It is a code-free platform where everything is visible and ownable – in table format.”[38] This philosophy ensures that even as plugins add functionality, users retain clear ownership of their app’s workings. Every plugin must operate via the TCR interfaces, preventing any “black box” behavior[32].
Benchmarking CitizenssApp Against Existing Platforms
How does CitizenssApp compare to other tools and paradigms out there? We consider three main categories of alternatives: (a) traditional spreadsheets (Excel/Google Sheets and their add-ons), (b) modern low-code/no-code development platforms (like Appsmith, Budibase, Microsoft Power Apps, etc.), and (c) plugin-based software ecosystems (like VS Code and WordPress). Each of these addresses some aspects of the problem space, but CitizenssApp differentiates itself by unifying the strengths of all three while adhering to its unique TCR-first philosophy. The following comparison table summarizes key differences:
Aspect CitizenssApp (TCR-First) Low-Code/No-Code Platforms
(Appsmith, Budibase, PowerApps) Spreadsheets
(Excel, Google Sheets & add-ons)
Data Model & Schema All data and logic in Table–Column–Row format. Fully relational schemas supported, defined via metadata tables. Easy to evolve schema on the fly (no code migration needed). Often use a form-driven or object model. Some require external databases (e.g. Appsmith needs you to connect your own DB)[39], others have built-in simple DBs (Budibase includes a low-code DB with relationships)[40]. Schemas are usually defined through GUI wizards; less transparent. Implicit schema in each sheet (header row = fields). Relations usually not explicit (users may use VLOOKUP/index to pseudo-link data). Difficult to maintain across multiple sheets; prone to schema inconsistencies.
Skill Requirement No coding required. Users leverage familiar table operations and natural language prompts. Logic is configured via tables, not programming. Essentially spreadsheet skills + data literacy suffice[41].
Low-code claim, but often require some coding/scripting for advanced logic or integrations (e.g. Appsmith triggers can use JavaScript; PowerApps has its formula language). Citizen developers need some training in the platform’s specific paradigm[42][43].
No coding required for basic use. Users must learn spreadsheet formulas for advanced tasks (e.g. Excel formulas, which are effectively a form of programming). Many business users already possess these skills, but complex tasks (macros, scripts) require expertise.
User Interface Design Metadata-driven Data-First Table: auto-generated from table definitions. Users can configure layout via tables (or prompts). Consistent table-based editing. Themes and layouts can be applied as plugins. Typically a drag-and-drop GUI builder for forms and dashboards. Users place widgets on a canvas (e.g. grid in Appsmith). Good visual flexibility, but can be fiddly and often tied to developer mindset (aligning components, writing custom code for interactions). Templates exist for common screens, but customizing them may require diving into settings or code. The spreadsheet grid is the UI for data. Limited UI elements (charts, pivot tables, basic form inputs). No concept of multi-screen apps (aside from multiple sheets). User interface for end-users is poor – usually just the spreadsheet itself or manual report creation. Add-ons (e.g. Google Forms) needed for friendlier UIs, but those are separate from the data logic.
Logic & Automation Declarative logic via tables. E.g. a “Rules” table contains conditions and actions. No hidden code; rules are visible (controlled by permission/rules) as data[21]. Supports formulas similar to spreadsheet formulas for computed fields. Complex workflows can be configured with step-by-step tables (like flowcharts in tabular form). AI can assist in generating these logic rules from descriptions. Most provide visual workflow editors or scripting. E.g. PowerApps and Power Automate allow flow diagrams; Appsmith uses JavaScript for actions; Budibase has a visual flowchart for automations. Logic might be split between GUI settings and code, which can be hard to overview. Citizen devs may hit a wall and require pro developers for complex logic. Primarily uses formulas in cells for logic. This is declarative but limited in scope to cell values. Cross-sheet or event-driven automation (like sending an email on a condition) is not straightforward without macros or scripts. Excel macros (VBA) or Google Apps Script allow automation, but that introduces code (and security risks). Many spreadsheet users struggle with complex formula logic.
AI Integration Deeply integrated. Natural language querying and schema creation are built-in. Users can ask questions and issue commands in plain English; LLM converts to SQL or schema changes. AI assists with data cleaning, formula suggestions, and even matching schemas between different tables for interoperability. Essentially an AI co-pilot throughout the app creation lifecycle. Nascent stage. Some platforms starting to add AI assistants (e.g. “describe your app” features) but not core. Many rely on user to manually handle schema and logic. AI might be available for code completion or formula help (Microsoft Power Platform has begun adding GPT-based helpers in preview). Overall, AI not yet central to their workflow, and often limited to premium tiers. Minimal. Excel and Google Sheets have added formula suggestion tools and basic natural language query features (“Ask Sheets” using Google AI), but these are limited to generating chart insights or pivot tables. No capability to design an entire spreadsheet via prompt. Also, AI answers might not always trust underlying data in spreadsheets due to lack of structure.
Collaboration & Sharing Multi-level sharing: can share entire app or specific tables/views with different permissions. Row-level and column-level security possible (metadata rules) – e.g. share only aggregated data with a partner. Real-time collaboration supported (multiple users editing different parts of the data simultaneously, thanks to underlying DB transaction support). Each user/org can keep a personal workspace and selectively link with others (federation). Generally support multi-user collaboration but usually at app level. E.g. PowerApps apps can be shared with user groups with certain roles, but within the app, fine-grained data permissions depend on the connected database’s setup. Budibase has granular user-specific views and can autogenerate CRUD screens per role. Most low-code tools are geared to internal team use, with authentication and role management included. They may lack cross-organization sharing features out-of-the-box. Google Sheets allows real-time multi-user editing, but entire file is shared with either edit or view rights. No native row-level security (third-party workarounds or splitting data needed). Excel Online allows co-editing but enterprise use often falls back to one user at a time due to file locking. Sharing across org boundaries is possible via links, but risk of data leakage is high as there’s no built-in granular control (besides maybe Protected Ranges which are not foolproof). Version conflicts and data integrity issues are common in collaborative spreadsheets.
Extensibility & Plugins Plugin/Module architecture at core. New templates, logic blocks, connectors can be added by community. All extensions operate via TCR data model for consistency[32]. Open API likely available for developers to create plugins. In spirit, like a WordPress or VS Code for apps: a marketplace of community-driven extensions. This fosters rapid evolution and localization (people can create plugins for local needs, languages, sectors). Many low-code platforms have limited plugin ecosystems. Appsmith and Budibase being open-source have some community contributions, but not at WordPress scale. Typically, they allow custom widgets or integrations via code, but average users may not use them. PowerApps has a marketplace (Microsoft AppSource) but it’s more for professional devs/partners to publish connectors. Overall, low-code tools are improving in extensibility but still relatively gated (especially proprietary ones). Add-ins and scripts: Excel has add-ins (in Office Store or standalone XLA files) and Google Sheets has add-ons. These can extend functionality (e.g. pull stock prices, perform advanced analysis). However, using add-ons is less common for average users due to trust and complexity issues. The add-on ecosystem exists but is nowhere near as large or central as, say, WordPress plugins. Also, add-ons often break with updates, and their integration is not seamless with sheet logic (they’re more like external functions called from cells or menu actions). In short, extensibility in spreadsheets is available but not highly accessible to end-users.
Analysis: From the above, we see that CitizenssApp offers a unique blend: the familiarity and user-ownership of spreadsheets, the multi-user app capabilities of low-code platforms, and the openness/extensibility of plugin ecosystems. Traditional spreadsheets excel in ease of use and flexibility, but falter in scalability, collaboration control, and application structure – issues CitizenssApp resolves by adding a solid database backend and explicit metadata. Low-code platforms provide structure and scalability, but often impose learning curves and hide logic in ways that non-developers find intimidating – issues CitizenssApp addresses by keeping everything in a visible table format and leveraging AI to fill the gaps. And while plugin-rich ecosystems like WordPress prove the power of community, they historically targeted web content or developers; CitizenssApp is pioneering that approach for general-purpose apps by laypeople.
To give concrete comparative scenarios: A small business owner currently might use Google Sheets with scripts to track inventory, and separately use a tool like Zapier to automate email alerts, and perhaps consider PowerApps for a more polished solution. With CitizenssApp, that owner could have one integrated solution: they’d import their Sheet (keeping the table structure), use prompt-based rules to set up alerts (“Email me when stock < 5”), and perhaps install a community template for an Inventory Dashboard to visualize it. All in one place, without writing VBA or juggling multiple services – and crucially, they fully control the data and app. Unlike PowerApps which might require a subscription and is tied to Microsoft’s ecosystem, CitizenssApp being open means they can even self-host it or use a community instance. For an NGO worker who is not a coder, currently options to build a custom app are limited – maybe they use Airtable (with its costs and limits) or hire someone to tweak an open-source CRM. CitizenssApp would let them be more autonomous: describe their data needs and processes in natural language, get an app, refine it, and share it with global partners securely. The ability to easily share subsets of data (not entire base) is a game-changer for collaborations that involve sensitive information – a need often seen in healthcare, education, etc., and not well-served by off-the-shelf software. Low-code platforms often target enterprise internal use (with enterprise price tags), whereas CitizenssApp aims to empower individuals and grassroots organizations, aligning more with a civic tech and open-source ethos.
From a standards perspective, CitizenssApp stands on the shoulders of decades of database and software principles. It enforces schema and integrity like any RDBMS (so people’s data is safer than in free-form spreadsheets), it uses and extends SQL (benefiting from a huge ecosystem and familiarity), and it leverages emerging AI standards for prompts. Importantly, it treats data and metadata as portable assets – something spreadsheets do poorly (Excel files are binary or complicated XML, not easily diffable; by contrast, CitizenssApp’s metadata tables could be exported to JSON and tracked in Git, for example). It also aligns with the idea of data justice and digital rights by giving users control and visibility into their software, which is increasingly recognized as important as privacy rights. In summary, CitizenssApp is carving out a new niche that overlaps with but isn’t identical to any single existing tool category: it’s a personal-plus-collective, low-code-but-full-power, table-driven app ecosystem. By benchmarking it in this way, we can appreciate that it really tries to take the best of all worlds: the ease of sheets, the robustness of databases, the reach of community plugins, and the intelligence of AI – something not seen in one package until now.
Conclusion and Call to Action
CitizenssApp represents a paradigm shift in how we think about software creation and digital empowerment. It is not just an enterprise tool for IT departments – it is envisioned as a starting point for everyone, from students and teachers to small business owners and community organizers. It elevates basic digital abilities (like making a table or filtering data) into the realm of application development, arguing that Minimum Digital Rights in today’s world include the right to craft your own software solutions. By making the Table–Column–Row model universal and imbued with rich functionality, the platform strives to make software autonomy as commonplace as personal writing or personal finance. In doing so, it could help bridge digital divides: those with little resources or programming knowledge can still tailor software to their needs, rather than being mere consumers of apps made by others. This flips the script on the tech industry’s usual power dynamics – putting individuals and communities in control of technology, not vice versa.
The journey, however, is just beginning. As a semi-academic, open endeavor (the white paper itself being part of ongoing PhD research), CitizenssApp calls for a community of researchers, developers, and early adopters to realize its full potential. Researchers can engage with the platform as a living lab for studying human-computer interaction, NL to SQL interfaces, collaborative data governance, and more. There are open questions ripe for exploration: How effective are lay users at using AI prompts to build apps? What is the best way to visualize and manage complex table metadata intuitively? How does one prevent mistakes and ensure quality in community-shared templates? The platform could serve as a basis for academic experiments and user studies, contributing to scholarship in data literacy and civic tech. The team explicitly seeks academic collaboration, aiming to publish and iterate in the open, so interested scholars are encouraged to reach out or contribute.
For developers and open-source contributors, CitizenssApp offers an exciting new playground. It’s essentially creating a new ecosystem – one that needs plugin developers, template creators, integrators, and core contributors. If you are passionate about open-source, you can help build the features that matter most to everyday users: be it a local language translation, a plugin for SMS notifications, or improvements to the AI prompt handling. The architecture invites extension (much like WordPress’s early days), meaning even small contributions (like a useful formula or a handy template) can have outsized impact when shared on the platform. By contributing, developers also become part of a movement advocating software freedom for all – aligning with the ethos that open-source and open standards can unlock digital autonomy.
Early adopters – be they NGOs, educators, or forward-thinking individuals – are similarly invited to pilot CitizenssApp in real scenarios. Your feedback will be crucial in refining the platform. By using CitizenssApp to solve a problem in your community or organization, you become a co-creator of the solution, not just an end-user. The project’s community-friendly tone means there will be forums or channels where early users can share experiences, ask for help, and showcase what they built. This can inspire others and create a virtuous cycle of knowledge sharing. Perhaps you’ll design a template that ends up being used by hundreds of other community groups worldwide – creating a ripple effect of empowerment.
In closing, CitizenssApp is ambitious in scope but simple in premise: give people a table, and they can change the world. It reminds us that at a fundamental level, data is power, and that power should rest in the hands of citizens. By merging the time-tested familiarity of tables with cutting-edge AI and an open ecosystem, CitizenssApp seeks to make good on the promise that “CRUD is the new literacy”[44]. Our call to action is clear: join us in this endeavor. Whether you’re a researcher who wants to study it, a developer who wants to extend it, or an early user who wants to apply it, your perspective and participation are invaluable. Together, we can refine this into a platform that truly enables minimum digital rights for all – where anyone can create their own software as easily as they write a document, and share it as easily as they share a story.
Digital empowerment is a journey, and CitizenssApp is building the road – one table at a time. Let’s walk it together, and ensure no one is left behind in the new digital society. Citizens of the digital world, it’s time to seize your rights – the database is in your hands.

Unified Metadata Model: The Role of PayanarssType
At the core of CitizenssApp lies a unified metadata structure called PayanarssType, designed to represent every conceptual element — from tables and columns to value types, parent-child relationships, and attributes — using a single recursive model. Instead of creating separate definitions for tables, fields, types, and logic, CitizenssApp treats them all as instances of PayanarssType, enabling a multilevel, self-describing metadata hierarchy.

Each PayanarssType object includes:

Structure:
{
"Id": "",
"ParentId": "",
"Name": "",
"PayanarssTypeId": "",
"Attributes": []
}
Sample with data:
{
"Id": "5F2A48CB-F50E-4CDE-8A3E-B6F9D6761B2E",
"ParentId": "6878a138e904a",
"Name": "Assets",
"PayanarssTypeId": "100000000000000000000000000000001",
"Attributes": null
},
{
"Id": "6F2A48CB-F50E-4CDE-8A3E-B6F9D6761B2E",
"ParentId": "5F2A48CB-F50E-4CDE-8A3E-B6F9D6761B2E",
"Name": "AssetId",
"PayanarssTypeId": "100000000000000000000000000000013",
"Attributes": null
},
{
"Id": "7F2A48CB-F50E-4CDE-8A3E-B6F9D6761B2E",
"ParentId": "5F2A48CB-F50E-4CDE-8A3E-B6F9D6761B2E",
"Name": "AssetName",
"PayanarssTypeId": "100000000000000000000000000000006",
"Attributes": null
}

• Id: A unique identifier for the type
• ParentId: Linking this type to its parent (e.g., column to table, or table to module)
• Name: The label or identifier of the type (e.g., "Trip", "StartDate", "IsMandatory")
• PayanarssTypeId: A pointer to its own type definition, enabling meta-modeling
• Attributes: A flexible array for storing rules, validation logic, flags (e.g., IsUniqueId, IsReadOnly, IsLookup)

All metadata — whether describing UI behavior, data types, child tables, or system logic — is stored using this single, recursive JSON structure, and saved in one file. This makes the model:

• Extremely lightweight and portable
• Easy to parse and version
• Ideal for offline use, file-based systems, or storage abstraction

By adopting PayanarssType as a meta-unifier, CitizenssApp eliminates the need for rigid schema engines or fragmented form designers. It provides structure without complexity, allowing both users and AI agents to read, modify, or generate metadata in a consistent and predictable way — using the same table-first philosophy that governs the app itself.

 
Sample POC Screen: Proof of Concept: PayanarssType Designer

The screenshot above shows a working Proof of Concept (POC) implementation of the PayanarssType Designer — a core feature of CitizenssApp that visually demonstrates how every metadata element (tables, columns, child structures, attributes, etc.) is represented as an instance of the PayanarssType model.

On the left, users can navigate a multi-level metadata tree, where each node is simply a PayanarssType object. There are no rigid distinctions between tables, fields, or modules — they are all types connected via ParentId relationships and governed by metadata rules.

On the right, users can create and manage different type definitions like ValueType, TableType, ChildTableType, GroupType, and AttributeType. Each of these is defined using the same schema and stored in the same underlying file — enabling total flexibility and uniformity. Features like "Set Attributes", "Add Child Types", and "Edit/Delete" operations allow users to build and evolve nested TCR structures interactively.

Even though this is an early-stage prototype, it validates the power of the one-model-for-all approach, where even the metadata editor is just a TCR rendered from metadata. The final result is a fully self-referential system — one where the system's own logic is defined using the same TCR structure it provides to users.

This is not just a form builder — it is a type builder, logic builder, and structure designer — all using the same PayanarssType concept and saved in a single, portable metadata file.