Purpose
This book sets the baseline for people who design, build, review, release, or operate Kylian systems. It favors clear ownership, simple controls, reliable recovery, and evidence over process for its own sake.
Engineering principles
- Start with the user and the operational decision that must become easier or safer.
- Use secure defaults and grant the least access needed for the shortest practical period.
- Keep customer boundaries explicit in code, data access, logs, tests, and support tooling.
- Design failure states before the happy path and fail without exposing sensitive information.
- Prefer simple, observable systems that can be understood, tested, and reversed.
- Treat artificial intelligence output as untrusted until constrained by context, permissions, validation, and appropriate human review.
Development lifecycle
Work moves through planning, design, implementation, review, testing, release, and operation. Security, privacy, reliability, data migration, and rollback are considered at the beginning of material work and revisited before production.
Secure and private by design
- Minimize collection, retention, exposed interfaces, and unnecessary privileges.
- Validate input, encode output, and enforce authentication and authorization on protected server operations.
- Separate customer data and prevent identifiers supplied by a client from bypassing authorization.
- Protect credentials and never commit secrets to source control.
- Log enough to investigate behavior while excluding or masking sensitive content that is not needed.
- Use data for the purpose communicated to the customer and support deletion and access obligations.
Artificial intelligence systems
AI components are evaluated as probabilistic dependencies. Workflows should constrain model access, retrieve only relevant context, validate tool actions, enforce customer rules outside the model, and preserve an attributable record of important actions.
High-impact housing, legal, financial, safety, and access decisions require deterministic controls or human approval appropriate to the risk. Model confidence is not a substitute for authorization.
Code, tests, and dependencies
Code should match surrounding conventions, make authorization visible, handle errors deliberately, and include tests proportional to risk. Dependencies are added intentionally, kept current, and removed when no longer needed. Security findings are prioritized by exploitability, exposure, and customer impact.
Environments and data
Development and testing should use synthetic, de-identified, or approved data whenever practical. Production access is restricted by role and operational need. Configuration and credentials are separated from code and from lower-trust environments.
Observability and incidents
Services should expose enough health, error, latency, and workflow evidence to detect failures and investigate customer impact. Alerts should be actionable. Incident response focuses first on safety, containment, service restoration, and accurate communication, followed by root-cause correction and prevention.
Change and access control
Material production changes follow the Kylian change control process. Access is approved for a defined role, protected with appropriate authentication, reviewed when responsibilities change, and removed promptly when no longer required.
Continuous improvement
Engineering standards evolve with incidents, customer needs, threat information, regulation, and platform maturity. Exceptions are explicit, owned, time-limited, and reviewed rather than becoming permanent hidden behavior.