MOLTARO
Register

01 · Security & data

Security is not only roles. It is the reason a person may act on a real resource.

Moltaro connects identity, roles, record responsibility, field visibility, module context, audit, and database ownership so the platform can explain access without locking data away.

02 · Trust model

SSO verifies the person; Moltaro decides what they may do.

Single sign-on proves who arrived. Authorization still belongs to the Moltaro installation: local roles, permissions, assignments, field rules, module responsibility and server-computed actions.

01 Roles grant broad capability

Administrators define who can configure, view, update, export, assign or audit a category of work.

02 Responsibility narrows the scope

A user may act because they own this record, handle this board item, cover this territory, or receive delegated access from a module.

03 The server computes actions

Lists, details, fields, comments, attachments, history and exports are shaped by backend access checks rather than client guesses.

03 · Catalogs and models

Entity catalogs carry hierarchy; modules keep their own controls.

Entity Definition catalogs let teams model departments, teams, projects and other containment hierarchies where access can be inherited or constrained. Boards, GEO and Entitlements add their own responsibility models beside that catalog, so governance stays explicit without pretending every surface is an Entity.

Surface
Model
Controls
Audit
Data
Entity records
Entity catalog access
Department, team, project, field rule
Yes
Yes
Board Item
Board responsibility
Item owner, status owner, delegated context
Yes
Record
GEO routed work
GEO assignment
Zone, team, route
Yes
Record
Entitlement
Entitlement model
Beneficiary, resource, ledger
Yes
Ledger
04 · Explainable access

A permission should answer why, not only yes or no.

The strongest operational systems make authority traceable: what broad role the user has, what concrete resource connects them to the work, which module created context, and what happened afterward.

Broad authorityRoles and permissions say what kind of work a user may perform in general.01
Concrete responsibilityAssignments, inherited child access and delegated access explain why this resource is visible or actionable.02
Module contextBoards, GEO and Entitlement Operations can add process, territory or rights context without becoming separate security islands.03
Proof after the actionMovement, assignment changes, field edits, ledger actions and override decisions remain visible in history.04
05 · Data ownership

Security also means the data remains yours.

Moltaro is PostgreSQL-first and deployment-conscious: shared cloud, dedicated tiers and on-premise paths differ in who operates the environment, but the ownership story stays explicit.

01 Portable operational data

Entity records, exports, audit and module facts are designed around database-backed structures instead of opaque vendor-only content.

02 Dedicated data access options

Backups are part of the managed data story across shared and dedicated deployments. Dedicated commercial tiers can add direct database access, longer retention, backup handoff or custom operational policies when the customer needs deeper control.

03 On-premise remains first-class

When policy requires it, the customer can operate Moltaro with their own PostgreSQL, storage, backups, keys, monitoring and update process.

Back to overview