Inaya is building a business software layer that makes decentralized infrastructure simple and invisible to Web2 users.
The underlying DePIN infrastructure remains the foundation. The SaaS layer on top is what businesses actually see and use.
Architecture
A secure workspace where businesses can organize teams, projects and documents while using Inaya's privacy-first storage infrastructure underneath.
Transform business documents from simple stored files into controlled business records with approval workflows and traceable history.
Give businesses granular control over who can access, edit, manage and share business information.
Ask questions about your business workspace using natural language. The AI operates only on information the authenticated user is already authorized to access.
AI permissions never exceed the user's permissions.
Implemented AI tools
list_documentslist_departmentslist_projectslist_taskslist_contactslist_dealslist_supplierslist_purchase_orderslist_purchase_requestslist_productslist_invoiceslist_expenseslist_employeeslist_leave_requestsfind_employee_documentget_activityget_document_accessget_business_insightsget_business_briefLive today in both the web and mobile Business Workspace, powered by the exact same permission-scoped tools on the backend. Read-only here — for the AI's ability to propose real changes (never execute them directly), see Stage 9.
The Business Workspace as a real installed application — its own icon, tray presence, native notifications and auto-updates, not just a browser tab.
Same Business Workspace, same permissions and encryption, running in its own window instead of a browser tab. macOS is not available yet. October 2026: found and fixed a real bug where the desktop app's security allowlist never actually granted the website permission to call most of its native features (chat notifications, tray unread count, pop-out module windows, DirectSync, Inaya Drive mount) — every installed copy needed a new signed build to pick up the fix, since that allowlist is compiled into the app, not loaded from the website. Also rotated the auto-update signing key after the original key's password turned out to be unrecoverable, and fixed the updater checking the wrong app's release.
Manage projects, tasks, customers, purchasing, and inventory from the same secure workspace as your documents.
Projects & Tasks
CRM
Procurement
Inventory
All four modules are real and shipped: task status workflows, a unified Lead/Customer CRM with a sales pipeline, purchase requests/orders with a real approval chain, and inventory with real stock movements — including purchase orders that actually move inventory when received. Every record is department-scoped and queryable by the AI assistant. See BUSINESS_OPERATIONS_TASKS.md, _CRM.md, _PROCUREMENT.md, and _INVENTORY.md for what's covered and what's explicitly not yet (e.g. warehouse-to-warehouse transfer UI, PO line-item editing after creation).
Secure financial and people-management capabilities built directly into the Business Workspace.
Finance
HR
Both modules are real and shipped: invoices with a cron-driven overdue status, expense approval workflows, payment recording/approval, and CSV financial reporting; employee lifecycle management, computed leave balances, leave approval, and Department Manager assignment. A testnet demonstration/validation layer, not regulated banking, tax filing, or payroll processing — every Finance/HR screen carries a visible "Testnet / Beta" badge. See BUSINESS_OPERATIONS_FINANCE.md and _HR.md for what's covered and what's explicitly not yet (e.g. no PDF invoice generation, no multi-currency conversion).
Inaya Business Insights & KPI Dashboard — business activity turned into live dashboards and AI-generated insight.
Real and shipped: KPI cards, period-over-period comparison, trend charts, and business alerts all compute from the same permission-scoped data every other Business Workspace module already reads — no separate, weaker-scoped path. The AI Business Assistant answers KPI/trend/alert questions directly via a dedicated get_business_insights tool. The Business Brief (new 2026-09-01) is a periodic recap on the same real data — deterministic highlight bullets plus a best-effort AI narrative paragraph on top, available as its own Workspace view and conversationally via get_business_brief. See BUSINESS_OPERATIONS_INSIGHTS.md for what's covered and what's explicitly not yet (no custom date-range picker, no trend charts on mobile yet).
The AI Business Assistant can propose real changes across 9 business domains — it never executes anything itself. A human with the exact same real authority the underlying action would require must approve; the server independently re-validates that authority; a mandatory 36-hour delay passes; only then does the change execute — and every step is recorded in a tamper-evident, cryptographically verifiable audit trail.
AI recommends. Humans authorize. The server validates. The system executes. The audit trail remembers.
Real and shipped across 9 domains, covered by 19 automated tests including 11 adversarial security scenarios (forged approval, cross-tenant access, replay, expired-proposal execution, prompt injection, and more — all fail safely). Explicitly not yet covered: AI-driven record creation (a new task/contact/etc.), task reassignment, transaction categorization, and drafting/sending customer communications — none of these exist anywhere in the app yet, gated or not, so there's nothing yet to guard. See docs/ai-controlled-actions.md for the full phase-by-phase breakdown.
Two vertical specializations of the Business Workspace — Health OS and Legal OS — for organizations handling patient or client/matter data, picked at company signup or changed later in Settings.
Patient and matter visibility is assignment-based, not department-based — being in the right department is never enough on its own.
Every domain module for both verticals now has a real, working screen in Business Workspace — not just Patients and Matters — live-verified end-to-end against the running app, including the trust ledger's server-side overdraft rejection. Mobile now has real screens for both verticals too (Health OS, Legal OS, and their patient/matter detail screens), built against the exact same vertical-locked API routes as web; these are written and syntax-verified but not yet exercised on a live device/simulator, which is the one thing still holding this at IN_PROGRESS rather than LIVE. FHIR/HL7/e-filing/e-signature/SSO and every other third-party integration are documented adapter interfaces with an honest not-configured stub, not live integrations. No HIPAA/ABA/eDiscovery compliance certification exists or is claimed.
A third and fourth vertical specialization of the Business Workspace — Financial Services OS (hedge funds/asset managers), Private Capital OS (PE/VC), and Regulated Enterprise OS (cross-industry compliance for banks, insurers, pharma, and other regulated organizations) — sharing one platform core with Health OS and Legal OS. All ten phases of the SOW are now built.
A framework or control mapping is never presented as a compliance certification — and a control with no test on file shows as "unknown," never as passing.
Live-verified end-to-end against the running app across every phase: control creation and activation, a failing test auto-opening a finding and walking its full state machine to closed, the dashboard's unknown/failing/passing distinction, the full policy lifecycle including the immutability guard and amend-creates-a-new-version behavior, an examiner magic-link's issue/exchange/one-time-use cycle, entity-scoped fund/deal visibility, and the board-report/export-package immutability guards. Not yet built: mobile screens for these verticals (Financial Services OS/Private Capital OS/Regulated Enterprise OS have zero mobile presence today — web only), and real third-party integrations (every adapter is a documented, honest not-configured stub). No compliance certification of any kind exists or is claimed.
A fifth vertical specialization of the Business Workspace, for government departments and agencies handling citizen, legal, financial, procurement, health, and operational data — sharing the same platform core as every other vertical above.
Citizen-record visibility is assignment-based, not department-based — being in the right department, or even holding staff-level government access, is never enough on its own to see a specific person's record.
Live-verified: the Government OS vertical option renders correctly in the org-creation flow, and every new API route is statically confirmed to lock to the government vertical. 51 new automated tests cover the two load-bearing properties (citizen-record access requires an actual assignment; a published policy knowledge base entry can never be mutated in place) plus case-workflow transition legality, dashboard honesty (unknown is never shown as passing), and AI tool need-to-know enforcement. Not yet built: mobile screens (Government OS has zero mobile presence today, same gap as Financial/Private Capital/Regulated Enterprise OS), a real pilot-agency onboarding, and any government-specific procurement rule beyond an explicitly informational, non-binding competitive-bid threshold flag. No government certification, accreditation, FedRAMP authorization, or jurisdiction-specific compliance claim exists or is claimed — that requires separate authorities entirely outside this codebase.
Makes Business Workspace storage consumable through the exact tools an enterprise IT team already has — real AWS S3, Azure Blob, and Google Cloud Storage protocol compatibility, a real mounted drive letter on Windows and Linux, and a local migration tool that moves existing cloud data in — without rebuilding or weakening the encryption/sharding/DePIN pipeline underneath any of it.
A signed URL or federated Google sign-in can never grant more access than the credential or membership it's built on already has — verified by adversarial test, not just by design intent.
Live-verified end-to-end: real SigV4/GOOG4/Shared-Key signature verification, a real signed-URL adversarial test suite (including waiting for genuine wall-clock expiration, not a simulated clock), real Terraform init/apply/plan/destroy and rclone upload/sync/download runs against the live endpoint, and Inaya Drive mounted for real on both a Windows machine and a Linux kernel (WSL2) with a full helper-process kill-and-restart persistence proof. macOS Drive support is written but not yet compiled or tested on real Mac hardware — explicitly not claimed until it is. The September 2026 storage feature expansion (tags, checksum, inventory, batch operations, analytics, policy analyzer) is covered by 9 additional automated tests, with zero regressions to the 57 pre-existing storage tests — a genuine, previously-unnoticed misconfiguration in the Pinata backup-provider credential was also found and fixed along the way. No official AWS/Microsoft/Google partnership, certification, or full protocol parity is claimed anywhere; only what's been directly tested.
Connects existing invoices, purchase orders, purchase requests, and AI-proposed actions into one traceable Business Event — with a plain-language "Why?" explanation, a portable cryptographic-proof passport, and a read-only "What If?" simulator — then extends that same simulation discipline into a broader Digital Twin that can answer "what would happen if a supplier became unavailable, an employee lost project access, a project was delayed, or a warehouse went offline" using the organization's own real, already-connected data.
A simulation can compute what a real change would affect, but it can never make that change happen — verified by tests that snapshot every touched record before and after, and confirm every one is left byte-for-byte identical.
Live-verified: 47 tests for the Evidence Graph layer and 9 tests for the Digital Twin layer, all passing against the real database, with zero regressions to any pre-existing test suite. The single strongest test in both layers is the same: run every simulation/scenario type, snapshot every record it reads before and after, and assert byte-for-byte equality — proving a simulation can never silently become a real action. Cross-organization Digital Twins (e.g., one company privately checking another's fulfilment capacity without seeing their internal data) were researched — zero-knowledge proofs, secure multiparty computation, and trusted-execution options were all evaluated — and deliberately deferred rather than built, since no validated customer need for it exists yet and building that cryptography speculatively isn't justified. Not yet built: a graph-visualization UI, versioned Twin snapshots for reproducibility, and natural-language scenario creation — the underlying model and API are complete and tested; the UI layer that would sit on top of them is a later pass.
Four self-contained features that make the existing platform materially easier for a real company to adopt without changing how it already works — automatic local-folder backup, ready-made secure data-room templates, a recurring cloud-to-Inaya backup scheduler, and a visual front-end over the existing Digital Twin simulation layer — all built strictly on top of existing storage, permissions, audit, migration, and simulation infrastructure rather than as four disconnected new products.
A local file's own delete action can never delete its backup, a rename can never create a duplicate remote copy, and a what-if simulation can never mutate a real record — each guarantee proven by a real, non-mocked automated test, not just asserted by design.
Live-verified: Data Room Templates covered by 8 automated tests (zero regressions to the pre-existing external-data-room suite); Cloud Backup Scheduler by 12 tests, including a genuine end-to-end run through the real migration engine and real storage write path via Node's module-mocking (only the external cloud source is substituted); What-If Studio extends the existing, already-tested Digital Twin test suite with 2 additional tests. DirectSync is covered by 7 unit tests plus 1 real, non-mocked end-to-end test — a real folder watched, real files uploaded, real duplicate-safety, real rename, and real delete-preserves-remote-copy behavior, all run on real Windows hardware. DirectSync's Windows support is real and tested; Linux is built on the same already-proven cross-platform components (the identical S3 client already verified working on Linux elsewhere in the platform) but has not yet been run on a real Linux machine, so it is stated as not yet verified rather than claimed. A real bug — a rename only updating local bookkeeping without actually relocating the object in storage — was found by the end-to-end test and fixed before this stage was marked live.
An IBM Cloud VPC Storage-inspired control plane for Inaya's own storage — a unified resource registry (volumes and file shares), a real point-in-time snapshot engine, consistency groups, cross-org snapshot sharing, and a tag-driven automated backup policy engine — plus a real Terraform provider so an IT team can declare all of it as code, the same way they already automate their other cloud infrastructure.
A capacity decrease is always rejected rather than silently ignored, a deleted backup policy stops being picked up by the automated cron sweep rather than continuing to run invisibly, and every automatic retention deletion is audited — none of it happens silently.
Live-verified: 35 automated tests across the storage resource, snapshot, backup policy, and Digital Twin integration layers, all passing against the real database and real S3-compatible storage write path, plus the Terraform provider's full create/read/update/delete cycle run against a real local Inaya deployment with real MongoDB-backed state — not a dry run. That testing caught and fixed a real bug (the provider's computed health/created_at fields were briefly blank immediately after creation, before the next refresh). Not built: fast/accelerated restore (no backend primitive exists to make one honestly faster than a normal restore), real physical block-volume attach or real multi-client NFS mounting (structurally impossible without a compute layer Inaya doesn't have), and live interop validation against real IBM Cloud Object Storage (blocked on IBM's own account sign-up, not on anything left to build). The Terraform provider is not yet published to the Terraform Registry — it runs from a local build today.
An IBM Cloud Docs-inspired official documentation portal at inayanetwork.com/docs — real product guides, a hand-verified API/SDK/CLI reference, a real keyword search, release notes, and a downloadable OpenAPI spec, all built directly from the actual shipped implementation rather than aspirational copy.
Every page's status badge (Live/Testnet/Beta/Planned/Deprecated) is enforced by the content loader itself — a page with a missing or invalid status fails to build rather than silently defaulting to a reassuring label.
Live-verified: 10 automated tests (frontmatter/slug/status validation, cross-reference integrity, and an OpenAPI-spec-matches-reference-data regression guard), a clean production build, and real browser verification including a genuine mobile-layout bug found and fixed (a search button overlapping its own placeholder text at narrow widths). Shipping this also surfaced and fixed an unrelated, pre-existing production issue: Vercel deployments had been silently failing for roughly 20 hours because a sibling local package's own dependencies were never installed in that environment — fixed with a postinstall hook, verified by simulating a clean install before shipping. Not built: a Tutorials/Solutions/FAQ-as-a-system content type, API/SDK/CLI drift checking against the live route files, a full CI validation/accessibility/SEO suite, an admin/governance interface, and an API playground — the SOW's own 15-phase plan spans well beyond this pass, and this stage covers Phases 0–3 plus slices of 4–7.
A Software AG CONNX-inspired live SQL virtualization layer: connect a data source, publish it as a versioned virtual schema, and query it in real time with standard SQL and standard client tooling — without moving the data or replacing the source system. A real connector framework, a real reference connector, and now a real RMS/OpenVMS connector proven against a genuine OpenVMS x86-64 instance.
A query can only touch a table that has actually been published as a virtual table for that data source — an unpublished or unauthorized table fails closed with a real 403, never a silent partial result — and write operations are rejected outright rather than silently no-opped, since the gateway is read-only this pass.
Live-verified: 11 automated tests for the connector/metadata/gateway layer, 7 automated JDBC integration tests, 19 automated ODBC direct-load tests, and 7 automated RMS/OpenVMS tests against a live OpenVMS instance. Real bugs found and fixed this pass, each confirmed against the real system: getting OpenVMS itself to boot under a hypervisor took five separate genuine firmware/controller/boot-order fixes; the RMS connector's SSH dependency broke Next.js's production bundling for every route that touches the connector registry; and getting the ODBC driver through the real Windows Driver Manager for the first time surfaced five more real bugs (a PowerShell script parameter colliding with a built-in variable, two connection-attribute handlers that hard-errored instead of no-opping, a DSN-resolution gap, and a missing mandatory ODBC Core function whose absence crashed the Driver Manager itself). ODBC registration and a real Driver-Manager-mediated connection are now proven; query execution through that same path still crashes, isolated via the Windows Event Log to a fault inside Microsoft's own odbc32.dll, not this driver — documented honestly as open. Not built: Adabas, VSAM and IMS connectors (Adabas's test environment — a real Docker container — is up and healthy, but the connector code isn't written; VSAM/IMS require a genuine z/OS environment, a much larger undertaking), write-back, and federated cross-source joins. See docs/mainframe-legacy-data-access-report.md for the full breakdown.
A control plane and appliance agent that turn a Linux machine into a managed on-premises file server: Windows, Mac and Linux computers use it like any office file server (SMB and NFS), while Inaya sets it up, controls who can open what, snapshots it, protects it from ransomware, backs it up and records every action in the tamper-evident audit trail. The office keeps working when the internet is down.
Access fails closed: a share grants only what the person's organization membership, NAS role and folder permissions allow, and a revoked member is locked out on the appliance itself. Immutable (WORM) content cannot be deleted or changed, even by an administrator or root, until its retention date; governance mode needs an owner override with a recorded reason, compliance mode has no override at all.
Implemented and tested end to end on ONE documented profile: a Linux VM appliance (Ubuntu 26.04, Samba, NFSv4.2, mdadm, Btrfs) with real disk failure, crash recovery and real Windows and Linux clients. NOT validated on physical hardware (SMART, temperature and UPS are reported UNKNOWN on virtual disks) — the largest remaining gap and the next step before selling hardware. NAS-to-NAS replication was tested on one host only; Active Directory/LDAP login, iSCSI, a local S3 gateway and Kubernetes CSI are not implemented; macOS is untested.
A single AI Security Gateway that sits in front of Inaya's AI assistants so the AI cannot be tricked by hidden instructions, cannot leak personal data, and cannot act without permission. Every request passes identity, guardrails, model policy and monitoring, and every decision is recorded so a company can later see why something was allowed, warned, redacted, blocked or sent for human approval.
Retrieved documents and user text are treated as untrusted data: instructions hidden inside them cannot widen permissions or trigger actions, and a risky AI action still goes through the existing human-approval flow (approval, then a 36-hour delay, then execution). The gateway blocks and records; it is strong protection, not a certification, and does not claim to make an AI model perfect.
Live-verified: 23/23 adversarial tests, and a real HTTP round trip against the running server in which a real injection attempt on the business assistant was blocked while normal chat was unaffected. Known boundaries: the voice assistant (speech goes browser to Gemini Live directly) is not gateway-covered; the documentation assistant streams with input-side checks only; routes that have no organization log without an organization audit chain. No independent security certification is claimed.
One pipeline that creates professional business documents from the records Inaya already holds (Finance, CRM, Procurement): data, template, exact calculation, document, validation, approval, evidence, encrypted storage, secure delivery, verification. Nine document types run through the same engine: invoices (standard and professional layouts), purchase orders, quotations, receipts, customer statements, credit notes, debit notes, delivery notes and business reports.
Documents are always derived from the authoritative records, never retyped; a template can contain no executable code; finalized documents are locked (Object Lock) and encrypted; every step is written to the audit chain and Evidence Graph. An AI proposal only ever produces a DRAFT that a person must approve.
Verified against the real database, including a storage-outage simulation and provider fallback. The Pinata plan limit blocked storage during testing; storage now falls back across configured providers. Live PDF generation, including Arabic and Urdu, was confirmed on the production site on 2026-09-27 (a bundler defect that broke every PDF export on Vercel was found by this live check and fixed the same day; see SQA-026 in the defect registry). A secure link is bearer access — the recipient's email is recorded, not verified, except in Data Room delivery. Country-specific e-invoicing formats are not built. Follow-up under investigation: one document-number ledger assertion in the lifecycle suite after an invoice cancel.
A visual, node-based workflow builder inside the Business Workspace. A company draws its own routines (a schedule, a webhook or an event as the trigger, then steps that read its own data, ask the AI to summarize or decide, send notifications, or wait for a person's approval), publishes them, and Inaya runs them on its own with a full step-by-step record. Ready-made templates cover daily business health, invoice follow-up, support escalation, and the Finance Operations Manager routine for the AI Bookkeeper.
The AI reads only what the person who owns the automation may see, can suggest but never change records by itself, and every consequential step goes through the existing Controlled Actions approval flow. Connection credentials are stored encrypted, shown once and never returned, logged or audited.
Verified against the real database. Slack sending and Gmail delivery were each verified live from a published production workflow on 2026-09-26. A real external helpdesk product is NOT verified (tested against a local stand-in only).
A complete support desk built into Inaya, on the customer and invoice records the company already has. Customers sign in to their own portal to raise tickets, attach files and follow the conversation; the company's team works them in a console with queues, assignment, business-hours SLAs that pause and resume correctly, saved replies, internal notes customers never see, a help centre with search, an AI helper that answers from the company's own articles with citations, satisfaction ratings, idea voting, analytics and an open API. Inaya's own users get Help & Support: Business Workspace members raise a ticket to Inaya's support desk, with an email copy to the support mailbox, and dApp visitors are pointed to the portal.
One company's customers can never see another's, and one customer can never see another's tickets; internal notes never reach customers; the AI is untrusted input, cannot change anything by itself and hands over to a person when unsure. Every uploaded file is scanned for malware and stored encrypted; portal sign-in links are single-use and login never reveals whether an address exists.
Verified against the real database; Help & Support verified by seven automated tests and a live production check of the endpoints. NOT yet verified against real providers: reply-by-email through the inbound email provider (built, setup pending), company single sign-on, and the malware scanner. To make Help & Support fully visible to dApp visitors, the Inaya Network organization's portal must be switched on in Customer Support settings.
When a company hires, changes or dismisses someone in its own directory, Inaya follows automatically and can prove the person really lost access. Access is keyed to the provider's immutable identity, changes are planned, executed and verified, and a leaver's revocation is checked step by step: freeze, sessions, credentials, permissions, sharing and break-glass, with failed steps listed and retryable. Managed-service providers can look after several customer companies with strict separation.
Nothing widens access silently: an owner can never be granted by a directory rule, administrator changes go through Controlled Actions, manual exceptions carry a recorded reason, and ambiguous identity matches fail closed. Webhooks require HTTPS, signature, timestamp, replay protection and tenant checks.
Verified against a REAL Microsoft Entra tenant: the Graph directory pull, and the SCIM connection test, joiner and leaver as sent by Entra's own provisioning service, including a leaver with six verified revocation steps. Active Directory is now ALSO verified for real: a genuine Windows Server domain controller was stood up, a real test user (with mail/department/title) was created in it, and the new sync agent pulled her and pushed her through the unmodified engine end to end — PROCESSED, with real identity/membership records to show for it. Three real bugs were found and fixed along the way (tenantId derivation, AD's GeneralizedTime timestamp format, an async client-shutdown race that crashed the agent on Windows). NOT verified: group-membership push from Entra, Rewst (a paid product not available to test; Inaya works with any automation platform through its open API), Okta, and HR/PSA/RMM tools, which are built as generic adapters only. Documentation labels each integration VERIFIED, PARTIAL, UNVERIFIED, UNSUPPORTED or FUTURE.
The AI reads bills, receipts and bank statements, works out what each is and which payments and invoices it matches, and sends anything doubtful or risky to a person. Statements are imported (CSV and OFX/QFX), documents arrive by upload, a signed email relay or WhatsApp, every extracted figure carries where it came from, and confidence is explained and configurable (default 99 percent).
The AI never changes an invoice, expense or payment by itself: a person confirms a match, which records a payment and creates a DRAFT expense, and marking an invoice paid is only ever proposed through the existing Controlled Actions. Risk overrides confidence: a large or unusual payment always needs a manager, however sure the AI is. Text hidden inside a document is untrusted, lowers confidence below any automatic threshold and raises an anomaly.
Verified against the real database (flow, unit and security suites, including organization and department isolation, webhook signatures and replay, and hostile files). NOT verified against real outside accounts: live bank feeds (no provider is registered; import statements instead), a live email provider, a real WhatsApp Business account (tested against a stand-in for Meta), and OCR of images and scanned PDFs (no local OCR engine; depends on the AI model and is never auto-processed). Inaya has no general ledger and none was invented; no savings figures are estimated. Excel and PDF report exports are not offered.
An independent quality audit that deliberately tries to break Inaya rather than re-running existing tests: every API route is probed for access-control gaps, real client tools (the official AWS command line, rclone) are driven against Inaya's storage, and the money, bridge and payment flows are attacked. Each confirmed defect is reproduced, fixed and locked in with an automated regression test, and everything is recorded in a defect registry with severity, root cause and status. Phase one is delivered; the review is continuing across the remaining repositories.
Findings are fixed without weakening permissions, changing public behavior unnecessarily or disabling tests. No 'bug-free' claim is made: the final report states what is ready, what carries evidence-backed risk and what could not be verified.
In progress. Done: main dApp routes, bridge, payments, S3 layer against the AWS CLI and rclone, contract suite, dependency audit. Still to do: Azure, Google Cloud Storage and Terraform against Inaya storage with their real tools; mobile, desktop and Inaya Drive on real devices (needs hardware); concurrency and failure injection; smart-contract static analysis; performance; CI review; and a complete re-run of the 179 test files. Open risks recorded: wallet-address metadata reads are unauthenticated by design, card-customer identity is the payer's email, the main dApp is on a Next.js version whose fix needs a major upgrade, and deleting an object does not yet unpin its provider copy. Provider plan limits (Pinata blocked, Filebase at its 500-pin free limit) need the owner's action.
A real, provisioned PostgreSQL database managed from inside the Business Workspace; a general document-understanding studio that reads any document, not just invoices; and an AI workbench for cataloguing data, checking its quality, registering models, and running one governed piece of code at a time in an isolated, disposable sandbox.
Provisioning a database and running code are owner/admin-only, rate-limited and fully audited. The sandbox never receives Inaya's own server secrets and has no internet access unless a person explicitly turns it on for one run. Inaya does not train AI models on its own infrastructure — registering a model tracks a real file a team already produced elsewhere.
Live. 26 real tests passing across all three workstreams, including live runs against a real, disposable cloud sandbox created and destroyed for each test — not simulated. A real bug (an Evidence Graph collection-name mismatch) was found and fixed by the tests before shipping. Not built: read replicas / failover for the managed database (not yet verified through a real incident), and REGEX-type data-quality rules (the reference SQL connector has no portable REGEXP).
A competitive-expansion layer inspired by the strongest patterns of two well-known products — private end-to-end encrypted collaboration (chat, notes, sharing), and the controls a large organization needs (governance, classification, device management, compliance readiness) — built inside Inaya's existing encrypted storage and permission model rather than as a separate product. Every capability here is off by default; an organization turns it on for itself.
Chat and notes are end-to-end encrypted on the device; an administrator cannot read them. Nothing here is claimed as a government certification or an independently audited cryptographic protocol unless it actually is one.
Secure Chat & Notes
Sharing & Governance
Devices & Infrastructure
Compliance & Developer Tools
Built across 26 workstreams and deployed to the live website behind off-by-default feature flags, 3–5 October 2026. Honest ledger of 114 tracked deliverables: 49 finished and independently checked against the real database and, where there's a screen, a real browser; 35 built and tested in code but not yet proven against a real outside system; 27 partly built; 3 not built (mobile chat and push notifications — left for later by deliberate choice, not an oversight). The Sovereign Gateway, NTFS/Active-Directory folder-permission bridge, high-availability site replication, and Microsoft 365/Outlook integration are built and tested but not yet proven against a real company file server or a real Microsoft 365 tenant. The chat protocol's open-source library implementation has not had an independent security audit. The project's own final verification report states plainly that the SOW is not yet complete — this stage stays IN_PROGRESS until it is.
A delta scope on top of the Competitive Expansion above, inspired by another well-known product's strongest ideas: future-proof encryption key establishment, a private local device cleaner, private video meetings, and one coherent view over the backup system Inaya already had. Nothing here duplicates an existing system — the first engineering step was a full audit of what already existed, and every new piece extends it.
The post-quantum layer protects key establishment, not file content — AES-256 remains the content cipher, unchanged. Meeting media never touches an Inaya server (peer-to-peer by design, not routed through a middle server). Nothing here is described as quantum-safe, zero-access, or fully end-to-end encrypted beyond what is actually implemented and tested.
Post-Quantum Cryptography
Inaya Cleaner
Inaya Meet
Device Protection
Post-quantum cryptography and Computer Backup reconciliation are complete and verified (127/127 SDK cryptography tests, including official ML-KEM test vectors and adversarial downgrade/tamper cases). Cleaner is built and tested (9/9 real filesystem tests on Windows); the live round trip through the compiled desktop app's native command bridge was attempted but not completed in this environment. Meet is functionally complete — 28 server-side tests passing, including every guest-access mode and server-enforced PQC-downgrade rejection — and was verified against a real running server in a real browser, a pass that found and fixed two genuine bugs (a pre-existing crash affecting any user, and a Meet-specific false error for anyone without a camera). What Meet still needs, honestly: a real two-person video call with real cameras, and a real phone running the mobile build — both need real hardware this engineering environment cannot provide. This stage stays IN_PROGRESS until that real-world test happens.
Inaya could always store and protect files, but had no way to actually run compute for a customer. This stage closes that gap: a customer connects their own computer (or a rented server) and it comes online as real, managed infrastructure — their own private slice of cloud-like compute, running on hardware they own, not shared with anyone else. Built independently, inspired by how BYOH providers like Spinifex approach the problem, reusing Inaya's existing security, permissions and activity-logging rather than a second stack.
Each connected node authenticates with its own signed-request credential, never a shared password, and can be revoked at any time. Each customer's virtual machines sit in their own isolated network with default-drop firewall rules. TPM and confidential-compute hardware is detected and reported, never claimed as in use beyond what's verified — see what's explicitly not built below.
Compute, storage & networking
AWS CLI compatibility
Load balancing
Kubernetes
Hardware detection
Built in two rounds and tested against real hardware throughout, not just written and assumed to work — a real VM, a real disk, a real VPC, a real `aws` CLI call, a real HAProxy round-trip, and a real k3s cluster were each exercised end to end on a real QEMU/KVM host. 82+ automated tests pass (30 Rust, 52 Node.js). Real hardware testing caught and fixed 7 genuine bugs a code review alone would have missed, including a pre-existing camelCase/snake_case wire-format mismatch in the node scheduler's capacity comparison (fixed at the customer's own request) and an SSH protocol ordering bug that silently truncated longer guest responses. Explicitly not built: GPU passthrough, full AWS coverage (S3/IAM/autoscaling), HTTP-aware load balancing, and TPM-backed identity or real SEV/TDX execution — each deferred for a stated, concrete reason, not silently skipped.
Inaya's long-term goal is to make decentralized infrastructure invisible to everyday business users.
Businesses should experience a familiar SaaS platform for documents, projects, teams, workflows, operations and business intelligence.
Underneath that experience, Inaya provides privacy-focused decentralized infrastructure, encrypted storage and verifiable data integrity.
Make decentralized infrastructure as easy to use as traditional cloud software.