Home / TLS / Philosophy

The 14 Laws

These rules govern every decision, every line of code, every module. They are non-negotiable. The core is the foundation — you don't change the foundation, you build on it.

Absolute rules. These laws apply to every instance, every module, every contributor. They are not guidelines — they are the constitution of the system.

1. Everything Is a Path

Every resource, service, device, API, file, or action is accessed through a path. A path is the universal address. No exceptions.

/node/module/resource
/local/serial/com1/read
/local/web/api/v1/users
/remote-dc1/db/postgres/query
/local/auth/login

If it exists, it has a path. If it has a path, it can be reached.

2. Everything Is a Message

All communication flows through a single structure: the Message. Request, response, event, notification — all are messages.

A message has: a path, a method, headers, a body, and a context. Nothing communicates outside this structure. No backdoors, no shortcuts.

3. The Core Does Nothing

The core is a router, a loader, and a referee. It does not implement business logic. It routes messages, loads modules, enforces access, and traces execution.

All functionality lives in modules. A web server is a module. A database connector is a module. An RS232 reader is a module. An authentication provider is a module.

The core without modules is silent. That is correct.

4. No Hard Dependencies

If module A needs module B and B is not loaded, A does not crash. A receives a clean "unavailable" response and decides what to do.

Every dependency is soft. Every absence is graceful. A module must be designed to work degraded, not to demand perfection.

5. Hot-Load Everything

Modules load, unload, and reload at runtime without stopping the core. The system never stops. Parts come and go. The core endures.

portal:/> module load web
portal:/> module reload iot
portal:/> module unload mqtt

6. One Interface, Universal

A module that reads RS232 speaks the same language as a module that serves HTTP. The message structure is the lingua franca. Learn it once, build anything.

A web UI module can query a serial port module using the same mechanism it uses to query a database module. No adapters, no glue code.

7. Nodes Are Peers

A node is a running core. Nodes connect to form a network. A remote path works exactly like a local path — the core handles federation transparently.

/local/db/users/query       # handled locally
/node-west/db/users/query   # routed to node-west, same format

A module does not need to know if a resource is local or remote.

8. Resource Properties

Every resource declares its access mode: READ, WRITE, or RW. No resource exists without a declared access mode. This is enforced at registration time.

9. Module Authentication

Every module authenticates on load. Credentials come from config (user + password or API key). Default = root. Permissions inherited by all code it executes.

10. Everything Is an Event

Every write, execution, or modification emits an event. Events chain: one event triggers N others. Nothing happens silently.

This is the nervous system of TLS. A cache write emits an event. A webhook listens. A cron job triggers. An audit log records. The system observes itself.

11. Config Files Are Documentation

Every .conf file lists ALL options with comments, descriptions, and defaults. The config file IS the docs. A new user reads the config and understands the module.

12. Universal Resource Names

All resources use the same path syntax everywhere. ls, get, set work identically for local and remote. Resources are found by name across all nodes automatically. One syntax, all modules, all paths.

13. Never Block the Event Loop

Module operations that do I/O must use thread pool or epoll. Thread pool size must be configurable. New clients wait when threads are busy. The event loop is sacred.

14. Exclusive Resource Locking

Physical resources (serial, GPIO, IoT) auto-lock on first write. Implicit keepalive from usage. Auto-release after 60 seconds of inactivity. Config protected while locked. Event subscriptions always remain open.

Summary

#PrincipleOne-liner
1PathEverything has an address
2MessageOne structure for all communication
3CoreRoutes and loads, nothing more
4Soft depsAbsence is handled, never fatal
5Hot-loadModules come and go at runtime
6UniversalSame interface for serial ports and REST APIs
7NodesTransparent federation of cores
8PropertiesEvery resource declares READ, WRITE, or RW
9AuthEvery module has identity
10EventsEvery change is observable
11ConfigConfig files are documentation
12URNOne syntax, all modules, all nodes
13Non-blockingThe event loop is sacred
14LockingPhysical access is exclusive
The elegant solution is the correct solution. If a design requires a paragraph to explain, it is wrong. If a data structure has fields "just in case," remove them. One message structure. One routing mechanism. One module interface. The power comes from composition, not complexity.