Technology and governance
What is designed, what is built, and how we tell them apart.
Every governance area carries one implementation status, and only a status we can substantiate. The products and this website are reported separately.
Implementation status
Designed, in development, implemented, tested and independently assessed are different things. Each area carries exactly one of these statuses, and only one we can substantiate. An area without a substantiated status says so.
- designed
- The intended approach is defined and documented.
- in development
- Being built, and not yet usable.
- implemented
- Built and working, but not yet tested against defined criteria.
- tested
- Checked against defined criteria by our own tests.
- independently assessed
- Reviewed by an independent third party.
LeBitsi OS and LeBitsi AI Life
| Area | What it covers | Intended design | Status |
|---|---|---|---|
| Human oversight | Which actions require a person, and where in the workflow they decide | In the LeBitsi OS mission lifecycle concept, review and approval are made by people before anything executes. | designed |
| Approval workflows | How approval is requested, recorded and enforced | The lifecycle concept places an approval stage, owned by an accountable person, between review and execution. | designed |
| Decision traceability | How each decision is linked to its evidence, its options and the person who made it | LeBitsi OS is designed to keep a record of what was known, what was decided, by whom and why. | designed |
| AI boundaries | Which tasks AI can recommend, prepare or execute, and which remain restricted | AI-assisted analysis is designed to prepare and explain options; it does not make consequential decisions. | designed |
| Operational accountability | Who owns each mission and its outcome | Each mission in the lifecycle concept has an accountable owner and an outcome review. | designed |
| Identity and access management | Authentication, role-based permissions, and separation of user or tenant data | Not yet published | Not yet published |
| Auditability | Which events are logged, how they tie to an identity, and how records are protected | Not yet published | Not yet published |
| Failure handling | Validation failures, timeouts, retries, escalation and recovery limits | Not yet published | Not yet published |
| Data protection | What data is collected, where it is stored, retention, deletion and third-party processing | Not yet published | Not yet published |
Designed means the approach is defined in the LeBitsi OS lifecycle concept, not that it is built. No product area is yet published as implemented, tested or independently assessed.
This website
Measures that protect this website and its contact form. They are separate from the security of the products. Tested means checked on the deployed site by our own automated checks; nothing here has been independently assessed.
| Measure | Status |
|---|---|
| HTTPS only, with HTTP Strict Transport Security | tested |
| Restrictive security headers, including a Content Security Policy that allows no inline scripts | tested |
| Contact form: server-side validation, rejection of unsupported requests, and a spam honeypot | tested |
| No cookies of its own, and no advertising or analytics trackers | implemented |
The LeBitsi OS mission lifecycle
Concept in development. This nine-stage lifecycle describes how LeBitsi OS is intended to govern work. Parts of it are not yet implemented, the implementation status of each stage has not yet been confirmed, and none of it is presented here as a verified capability. Review and approval are decisions made by people.
Define
State the objective, scope, owner and constraints of the mission before any work begins.
Draft
Prepare the proposed plan and actions so there is something concrete to examine.
Validate
Confirm that the data the mission depends on is present, current and fit for the decision.
Simulate
Evaluate proposed actions against modelled outcomes before anything touches a live environment.
Review
Decided by a person
Subject-matter and operational reviewers examine the plan, the evidence and the simulated results.
Approve
Decided by a person
An accountable person authorises, amends or rejects the mission. Nothing proceeds without it.
Execute
Approved actions are carried out within the boundaries that were approved.
Monitor
Results are compared with the intended outcome while and after the mission runs.
Learn
What was observed feeds the next mission, so the next decision is better informed.
Walk through the lifecycle in the mission simulation
Mission Control Center
Mission Control Center is a module within LeBitsi OS, not a separate product. It is a control-oriented interface for monitoring and coordinating relevant organisational activities.
Conceptual architecture
The design philosophy behind both products, stage by stage. Select a stage to see its purpose, inputs, outputs and where people decide.
Conceptual architecture. It shows how both products are designed to work. No stage is presented here as an implemented capability.
01Information sources
Gather the signals a decision depends on.
- Inputs
- Operational data, workflows, tickets and events, or a person's goals, time, learning and spending.
- Outputs
- Information that is still unconnected.
- Connects
- From the lessons of earlier decisions; to context and profile.
- Human oversight
- People choose which sources are connected.
In LeBitsi OSMonitoring, service desk and change records.
In LeBitsi AI LifeYour goals, time and finances, as you enter them.
02Context and profile
Relate the information to the situation it describes.
- Inputs
- Information from the connected sources.
- Outputs
- A picture of current conditions, or a personal profile.
- Connects
- From information sources; to intelligence layer.
- Human oversight
- Context can be inspected and corrected by the people it describes.
In LeBitsi OSWhich services, teams and dependencies are affected.
In LeBitsi AI LifeYour priorities, constraints and progress so far.
03Intelligence layer
Analyse the context and prepare options.
- Inputs
- Context and profile.
- Outputs
- Options, each with its evidence and risk.
- Connects
- From context and profile; to decision framework.
- Human oversight
- AI-assisted analysis prepares and explains options. It does not decide.
In LeBitsi OSAI-assisted analysis of the options for an operational issue.
In LeBitsi AI LifeAI-assisted suggestions for a next step.
04Decision framework
Structure the choice: objective, options, evidence, risk and owner.
- Inputs
- Prepared options.
- Outputs
- A decision that is ready for review.
- Connects
- From intelligence layer; to human review and approval.
- Human oversight
- The framework names the person who is accountable.
In LeBitsi OSA mission definition with its constraints and owner.
In LeBitsi AI LifeA plan shaped by your own time and budget.
05Human review and approval
A person reviews the evidence, then approves, amends or rejects.
- Inputs
- A decision that is ready for review.
- Outputs
- An approved, amended or rejected decision, and who made it.
- Connects
- From decision framework; to execution or recommended action.
- Human oversight
- This is where people decide. Nothing consequential proceeds without it.
In LeBitsi OSThe accountable lead approves or rejects the mission.
In LeBitsi AI LifeYou accept, change or ignore a suggestion.
06Execution or recommended action
Carry out what was approved, within its boundaries.
- Inputs
- An approved decision.
- Outputs
- Coordinated actions, or a recommended next step.
- Connects
- From human review and approval; to monitoring and learning.
- Human oversight
- Actions stay within what was approved.
In LeBitsi OSWork is assigned to the teams involved.
In LeBitsi AI LifeSessions are placed into your week.
07Monitoring and learning
Compare results with the intent, and carry the lessons forward.
- Inputs
- Results and outcomes.
- Outputs
- A record, and lessons for the next decision.
- Connects
- From execution or recommended action; to information sources, closing the loop.
- Human oversight
- People review outcomes, not just outputs. The loop returns to the first stage.
In LeBitsi OSThe decision record and the outcome review.
In LeBitsi AI LifeYour regular review of what moved and what did not.
Governance principles
These principles guide how both products are designed. They describe intent, not verified controls.
- Approval before action. In the intended design, execution follows approval, and approval follows review.
- Evidence before approval. Data is meant to be validated, and outcomes simulated, before reviewers decide.
- Accountability. An accountable person is meant to authorise each mission.
- Learning loop. Monitored outcomes are meant to inform the next mission.
- User-specific by design. In both products, data is designed to be isolated per user, and each plan is designed to start from that user's own information. Isolation controls are listed above only once verified.
Security and privacy of this website
This website is configured to be served over HTTPS only and to send restrictive security headers; those settings are checked on the deployed site before launch. It sets no cookies of its own and uses no advertising trackers. See the Privacy Policy.
Assurance and certifications
LeBitsi AI does not currently make any certification, audit or compliance claims on this website. Any such claim will be published only after it is verified.