One permission rule.
One de-identification policy.
Approvals and immutable history.
Viewing, search, SQL and ETL all pass the same gate, for people, AI agents and share links alike. The principle is the same across the three services and stays the same when scale moves down to DIP.
We keep one permission rule, one de-identification policy and one approval history.
Usually every new feature brings another rule. Here three rules come first and features are built on top of them.
One permission rule
People, AI agents and share links pass through the same permission gate. Permissions for the document repository and the data catalog are set in one place and apply whether the path is viewing, search, SQL or ETL.
One de-identification policy
Personal data is masked at read time by a policy set once. doc:// document paths and data:// table columns share one binding, and the original is never touched. Exceptions exist only for named subjects.
Approvals and immutable history
AI proposes and people approve. Document edits, permission changes and AI proposals are recorded in an immutable history and audit log, with who did what and when. No change lands without approval.
Services on top, platform underneath.
Permissions and policy are the same everywhere.
The three services run on the same repository. When scale grows, the platform below takes the processing. Who can see what does not change.
The principles, on screen.
These slots will hold real screens captured on a demo tenant. All personal data is fictitious.
Content filter bindings
One policy for doc:// and data://. One named exception sees the original. Anyone who is not an exempt subject sees masked values only.
Permission grants
Who was granted access to which document and data scope, answered on screen.
3 registered · 2 pending.
Of the three axes that run through everything, the organizational knowledge management system is patent registered. Unified access control and read-time de-identification are patent pending. Registered and pending are labeled separately.
| Status | Title |
|---|---|
| Registered | Cross-network binary repository · package import management (Binup) |
| Registered | Organizational knowledge management system |
| Registered | Open-source SaaS transition and integrated management (PCT · US filing in progress) |
| Pending | Unified access control across heterogeneous resources |
| Pending | Declarative filter binding, read-time transformation (de-identification) |
FAQ
The PAASUP platform principle is one permission rule and one de-identification policy. Viewing, search, SQL and ETL all pass the same gate, for people, AI agents and share links alike.
01What does "one permission, one policy" mean?
Access scope for documents and data is defined in one place and viewing, search, SQL and ETL all follow it. The de-identification policy is bound once to documents (doc://) and data (data://) and applied the same way at read time.
02Can an AI agent bypass permissions?
Agent tool calls pass through a single gate and follow the same permission rules as people. Agents cannot write directly. They propose, and changes land only after approval.
03Is this architecture patented?
Two patents are pending: unified access control across heterogeneous resources, and read-time transformation (de-identification) based on declarative filter binding. Beneath them are 3 registered patents: a cross-network binary repository, an organizational knowledge management system and integrated open-source SaaS management.
04Does it run in an air-gapped network?
PAASUP DIP is designed and supplied for air-gapped environments. An air-gapped bundle for the services is coming soon.
05Do I have to migrate existing documents or data?
No. Repositories stay where they are and the permission rules and policy are set on top. You turn a feature on.
More on the platform.
PAASUP DIP is the infrastructure that carries out these principles. All three services are already supported as an air-gapped bundle.