By Malay Baral, Founder & CTO, AdiOS Platform Private Limited
"Sovereignty is not where your data lives. It is whether your intelligence runs on your own premises, under your own rules, answerable to no external party."
The Sovereignty Misconception
Most conversations about data sovereignty get stuck on geography. Where is the server? Which country hosts the data centre? Is the IP address Indian?
These are necessary questions. They are not sufficient ones.
A hospital in Amsterdam that moves its patient records from AWS Dublin to a Dutch data centre has achieved data residency. It has not achieved sovereignty. The operating system running on that Dutch server was built in Redmond. The AI model processing clinical notes was trained in San Francisco. The audit framework validating compliance was defined in California. The institution has no meaningful control over any of those layers.
Sovereignty means the intelligence runs on your premises. It runs under your architectural rules. You enforce every policy. You own every audit record. No external party can revoke, inspect, or modify the stack without your consent.
AdiOS is designed around that definition. Not around a post code.
This matters for an Indian BFSI enterprise subject to the DPDP Act 2023. It matters equally for a Dutch public sector agency subject to GDPR and the NIS2 Directive. The regulatory context differs. The architectural requirement is identical: run your intelligence on your own premises, under your own rules, with cryptographic proof that you did so.
Part One: The Identity Foundation
Before you can measure any entity, you must know who it is. Before you can audit any action, you must know who took it. At AdiOS, identity is not a username in a SaaS dashboard. It is a W3C Decentralized Identifier anchored in the platform node.
Every Entity Gets a DID
The DID scheme follows this pattern:
Applied to entity types in the organization:
Table 1. DID class scheme: every entity type in the mesh
A DID is not a name. It resolves to a DID Document containing:
- Public key material for signature verification
- Service endpoints (Zoho, Slack, Linear, GitHub)
- Controller assertion (who manages this identity)
- Capability delegation anchors
The same scheme works for a 50-person Indian NBFC, a 5,000-person Dutch municipality, or a 50-sensor agricultural IoT mesh in Telangana. The identity architecture is jurisdiction-agnostic. The compliance rules loaded into the policy engine are jurisdiction-specific.
Every Role Gets a Verifiable Credential
A DID says who you are. A Verifiable Credential (VC) says what you are authorized to do. Every entity carries a VC issued by adios-identity and validated by adios-sentinel before any action is permitted.
A VC for a marketing agent encodes:
The proof field is an Ed25519 cryptographic signature produced by the on-premises node. The key never leaves the node. No cloud KMS. No external signing authority. If the node is in Hyderabad, the key is in Hyderabad. If the node is in Amsterdam, the key is in Amsterdam. The architecture is the same. The jurisdiction is chosen by the deploying organization.
No valid VC: no action. No valid signature on the VC: no action.
adios-sentinel verifies both on every operation.
Part Two: The Accountability Architecture
Three-Tier Autonomy Model
Action risk determines required authorization. Every entity, human or agent, operates in exactly one tier:
Figure 1: Three-tier autonomy model
The Cryptographic Audit Trail
Every action by every entity writes an immutable record to the audit log managed by adios-sentinel:
The node field records which physical premises produced the signing key. This is the cryptographic proof of on-premises execution. The record is append-only. It is the source of truth for performance metrics, compliance audits, and dispute resolution.
Part Three: The Operational Stack
Why India-Hosted Tools for an Indian Company
AdiOS Platform Private Limited uses Zoho One as its complete operational backbone. Zoho is headquartered in Chennai and operates India data centres. We configure every Zoho One application to use India data centres wherever Zoho exposes that choice, so our primary operational data is hosted in India. Our internal policy prohibits intentionally sending business-critical data to services hosted outside India.
The tools we do not use for our own day-to-day operations as of April 2026: Notion, HubSpot, Slack, QuickBooks, Google Workspace. Each of those routes primary business data through servers outside India. For a company whose product thesis is that your intelligence must run on your own premises under your own rules, using those tools is a structural contradiction.
This is not a claim that Zoho's tools are superior in every dimension. It is a claim that architectural consistency between what we build and how we operate is not optional. Enterprises evaluating AdiOS for DPDP Act compliance will look at how we run ourselves.
The Operational Function Map
Figure 2: Operational tool map with data residency column
The API Authorization Flow
When any agent invokes a Zoho API, the call passes through five gates:
Figure 3: API call authorization: gates before execution
The region-kit gate is where jurisdiction-specific rules are enforced.
For India: DPDP Act 2023.
For a Netherlands deployment: GDPR Article 25 (data protection by design) and NIS2.
For a Saudi Arabia deployment: PDPL. The gate is always present.
The rule set loaded into it is configured at deployment time by the organization that owns the node.
Part Four: The Shared Sprint: One Plan for Humans and Agents
Every entity, human or agent, works from the same sprint board in Zoho Projects. There is no separate AI task queue. Story points are assigned identically regardless of entity type. Velocity is tracked weekly. Burndown is visible to every entity on the team.
Figure 4: Unified sprint board: one plan, two entity types
A story point measures scope and complexity. It does not adjust for entity type. This is intentional. The difference between humans and agents appears in the velocity data over time, not in the measurement unit. Agents deliver higher volume on repetitive tasks. Humans deliver higher quality on judgment-intensive ones. The sprint board does not prescribe this. It reveals it.
Part Five: Gamification as Accountability Infrastructure
Accountability without a feedback loop is surveillance. To make accountability drive behavior, every entity needs a reward signal that is visible, fair, and tied to the same outcomes the organization cares about.
The Five-Dimension Metric
Every entity is scored on five dimensions, updated daily:
Figure 5: Unified performance metric framework
The Compliance Score carries the most behavioral weight. An agent that routes data through an unauthorized surface, bypasses the veto window, or fails a sentinel policy check sees an immediate score drop. Every entity on the team can see it. This is not punitive. It is a system that makes invisible failures visible before they become organizational liabilities.
The XP and Level System
Entities accumulate Experience Points (XP) from completed tasks, quality reviews, compliance streaks, and collaboration events:
Figure 6: XP Level system with autonomy gates
The critical design choice: level gates are enforced by the VC, not by a configuration field in a SaaS tool. An entity at Operator level cannot self-promote to Architect. It earns the XP. The platform issues a revised VC. The new VC is what unlocks the action class. The cryptographic chain is unbroken.
Part Six: Form Factors and the Transaction Stamp
Sovereignty is not only about where data lives. It is about which physical context an action originates from and whether that context is strong enough to authorize the action being requested.
AdiOS supports ten form factors from a 256 MB IoT sensor to an 8 TB GPU cluster. Every form factor has a defined transaction stamp strength:
Figure 7: Transaction stamp requirements by form factor
Part Seven: Human-Agent Augmentation
The gamification system is infrastructure. So are the DID-VC identity layer and the unified sprint plan. Together, they support a deeper model. Humans and agents make each other more capable. They do not substitute for each other.
Where Humans Lead
Strategic judgment on ambiguous situations. Relationship-critical communications with investors and enterprise pilots. Architecture decisions (ADRs require human authorship). Ethical edge cases. OKR setting and organizational direction.
Where Agents Lead
Consistent high-volume execution: content series, compliance monitoring, report generation. Cross-system integration. First-draft production across all output types. Data synthesis across large audit trails.
Where They Work Together
Every significant output at AdiOS Platform Pvt Ltd is a joint product. The agent produces at speed. The human provides judgment at key gates. The platform records both contributions, under their respective DIDs, in the same audit trail.
Closing: The Lesson for Every Sovereign Deployment
AdiOS Platform Pvt Ltd is an Indian company solving an Indian regulatory problem. But the accountability architecture described in this post is not Indian. It is architectural.
A Dutch PSU department faces the same question. It may deploy AI agents on public sector infrastructure. It still has to ask: who authorized this action? From which physical context? Under which rule set? With what cryptographic proof? GDPR Article 5 requires accountability. NIS2 requires auditability. The DID-VC architecture answers both. The sentinel audit trail records both.
Sovereignty is not where your server lives. It is whether you can answer for every action your intelligence takes. The answer must be cryptographic. It must be complete. It must come from your premises. It must follow your rules. No external party should be able to revoke it.
That is what we are building. As of April 2026, it runs in Hyderabad. It is designed to run anywhere.
Malay Baral is the Founder and CTO of AdiOS Platform Private Limited (CIN: U58201TS2026PTC211867), a deep tech startup based in Hyderabad, India.
Originally published on LinkedIn on April 25, 2026.