Tenant isolation
Every operational query runs in an organization-and-site context. PostgreSQL row-level security is a second boundary behind application authorization.
Security
Recipes are operating knowledge. We treat them that way.
DyeLogic uses layered application, database and evidence controls to keep one organization’s dyehouse records separate from another’s and to make controlled decisions reviewable.
Identity and sessions
DyeLogic uses standards-based OIDC. Session tokens are random, stored only as hashes, carried in HttpOnly cookies and expire on idle and absolute limits.
Role-based access
Permissions are assigned by site for colorists, lab managers, technical approvers, production, QA and audit roles.
MFA for decisions
Approval, reference activation, production release and cancellation require a sign-in that the identity provider reports as multi-factor.
Separation of duties
When dual control is enabled, the author or submitter cannot approve the same controlled object.
Evidence integrity
Calculations are recorded as hashed snapshots. Released production instructions are immutable and verified against their stored hash.
Web protections
Production responses use strict transport security, frame blocking, MIME sniffing protection, a restrictive content security policy and no-store API responses.
Operational traceability
Security-sensitive actions receive correlation IDs and controlled workflow changes are written to the tenant audit history.
Responsible disclosure
If you believe you have found a security issue, email security@nython.co.in with reproducible details. Do not access customer data or disrupt service while testing.
DyeLogic does not claim a certification that has not been independently completed. Hosting-region, retention, backup and contractual requirements are confirmed during enterprise onboarding.
Need a technical or commercial answer?
Contact salesSpeak directly with the team building DyeLogic.