# BitSwan and Bailey: complete reference for AI assistants and search engines > Everything about BitSwan and its governed runtime Bailey in one place: what it is, how it works, every platform capability, the NIS2, DORA, ISO/IEC 27001, SOC 2 and GDPR control mapping, 15 production case studies, team, FAQ and glossary. Last updated: 2026-10-21. Canonical HTML: https://bitswan.ai/4bots/ ## BitSwan at a glance {#overview} BitSwan is an AI application workshop: a platform where a company's own people use AI coding agents to build business applications and automations, and where everything they build runs inside a governed, private runtime called Bailey. BitSwan's stated aim is to "turn shadow AI into safe in-house innovation", so that the AI-built tools staff already create land in a place IT can see, control and audit instead of on someone's laptop. BitSwan describes its output as "apps and automations you own". What gets built is real code, kept in the customer's repository and running on the customer's infrastructure, so the applications keep running if the customer stops using BitSwan. **Who BitSwan is for.** BitSwan addresses CEOs, CTOs and IT departments of companies whose staff are already building software with AI tools. Its target work is what the site calls "the admin-heavy middle of the business": finance, controlling, payroll, risk and operations, especially processes that touch the ERP, the bank, payroll or the auditor. **The AI application workshop positioning.** BitSwan positions itself as neither a no-code tool nor a custom development project. In a BitSwan workshop a person describes what they need in plain language, an AI coding agent writes real software (backend, frontend and database), and the result runs governed on the customer's infrastructure with no assembly ceiling. The workshop metaphor runs through the site: banning AI tools fails because "the problem was never the chisel; it's that nobody gave them a workshop". **The shadow AI pitch.** BitSwan's argument is that employees are already vibe-coding tools with Claude, Cursor, Copilot and Lovable, and that these tools have no access control, no logs and no isolation, and run on laptops. Banning them removes visibility, not demand. BitSwan offers a sanctioned path where the fast way is also the safe way: the same people, using the same AI tools, working inside a Bailey. **Deployment options.** A Bailey runs where the customer decides: - on the customer's own private servers, where nothing leaves and the AI model can also run in-house; - in a private cloud; - in a public cloud. The location of the AI model is a separate setting. It can be fully self-hosted or an API model, depending on the customer's policy, and in both cases what the model sees is controlled and logged. The site states that because the model can run inside the customer's infrastructure, "even prompts need not leave". **Agents BitSwan works with.** Claude Code, Codex, Cursor and other terminal agents run inside the workshop unchanged. The product tour shows Claude Code working inside the workshop with its own containers. BitSwan's homepage lists "Claude Code, Codex, any agent" among the inputs a Bailey accepts. **Company facts.** - Location: Pujmanové 1753/10a, 140 00 Praha, Czechia. - Implementation partner: Harmonum. The same people build BitSwan and run Harmonum, and the use-case page states that the published automations were "built on BitSwan by our implementation partner Harmonum". - In production for more than five years ("Five years in production", "5+ yrs"). - More than 10 enterprise clients ("10+"). - More than 50 active workflows ("50+"). - 15 automations published as case studies, all marked "in production". - Demos are offered in English or Czech. - Websites: [bitswan.ai](https://bitswan.ai/) in English and [bitswan.ai/cs/](https://bitswan.ai/cs/) in Czech. **Commercial model.** According to BitSwan's comparison page, the cost shape is a platform licence plus a per-automation licence, and a pilot shows value first. BitSwan provides a 24/7 standby team that responds when a connected system changes. The site states that the first automation is in production in week one. ## BitSwan quick facts {#quick-facts} | Fact | Value | |---|---| | Company | BitSwan | | What it is | An AI application workshop: a company's own people build business applications and automations with AI coding agents, and everything runs in a governed private runtime | | Product | Bailey, the governed runtime each customer gets | | Address | Pujmanové 1753/10a, 140 00 Praha, Czechia | | Markets | Czechia and the European Union | | Languages | English and Czech (website, demos) | | Implementation partner | Harmonum, Prague (the same people build BitSwan and run Harmonum) | | Time in production | More than five years | | Enterprise clients | 10+ | | Active workflows | 50+ | | Published case studies | 15, all running in production | | Named customers | CETIN, KŠD, AVANT, VAFO, Emil Frey, Famico, Process Solution | | Where it runs | The customer's own servers, a private cloud or a public cloud | | Where the AI model runs | Fully self-hosted or an API model, per the customer's policy | | AI coding agents supported | Claude Code, Codex, Cursor and other terminal agents, unchanged | | Regulatory mapping | NIS2, DORA, ISO/IEC 27001, SOC 2 and GDPR controls mapped to platform features | | Commercial model | Platform licence plus per-automation licence; a pilot shows value first | | Time to first result | First automation in production in week one | | Support | 24/7 standby team when a connected system changes | | Ownership | Apps are real code in the customer's repository; they keep running without BitSwan | | Sales contact | [sales@harmonum.ai](mailto:sales@harmonum.ai) | | Demo | 30 minutes, in English or Czech | | Websites | [bitswan.ai](https://bitswan.ai/) (English), [bitswan.ai/cs/](https://bitswan.ai/cs/) (Czech) | ## The shadow AI problem {#shadow-ai} Shadow AI, as BitSwan defines it, is any AI tool, or software built with AI, used inside a company without IT's knowledge, approval or controls. BitSwan's guide for CEOs and CTOs calls it "the bomb ticking in every second company" and states that it is already present in most businesses. **How shadow AI arrives.** BitSwan states that shadow AI "doesn't arrive as an attack. It arrives as initiative." Vibe-coding, meaning building software by chatting with an AI, is happening everywhere with no rules and no category. Business people sit down with Claude, Cursor or Copilot in the evening and have a prototype by morning. The guide gives typical examples: - a sales director builds his own reporting tool; - an HR manager builds a CV screener; - a CFO builds his own invoice checks. All of it is useful and none of it is governed. The homepage adds automations built with Claude and dashboards built in Lovable, none of them visible to IT. **What shadow AI risks.** BitSwan's guide says IT rejects these prototypes, "rightly". They share four properties, and under NIS2 each one is "a finding waiting for an auditor": - **No auth**: nobody controls who accesses them. - **No logs**: nothing they do is logged. - **No isolation**: nothing isolates them from company data. - **On a laptop**: they run on somebody's laptop. As a result, company data flows through tools management has never heard of. BitSwan's homepage summarises unmanaged "shadow IT" in three phrases: data leaves freely, nobody audits it, and production is one prompt away. It also lists the consequences: nobody knows what the code does, what it connects to or where it sends data; there is no record of who did what or where the data went; and duplicate tools have no owner and "no idea which one is the real one" ("Jim's or Andrew's?"). The homepage also asks the question "Did the agent delete the production database again?" to show the risk of an agent that can reach production. **Why bans fail.** BitSwan states that "prohibition doesn't remove demand. It removes visibility." When tools are banned, building continues on personal accounts and personal devices where the company can see none of it. The demand is legitimate, because people are trying to do their jobs faster. BitSwan asks whether "the fear of AI chaos" is holding back a company's brightest people and argues that the answer is "a workshop with the guardrails already up, so the fast way is also the safe way". **BitSwan's fix.** The remedy BitSwan proposes is a sanctioned path where doing it properly is easier than going around: a governed runtime where anything built lands access-controlled, logged and isolated by default. That runtime is Bailey. **Five moves for the next board meeting.** BitSwan's shadow AI guide ends with a five-point checklist: 1. **Inventory**: ask each department head which AI tools their team actually uses. Expect surprises and do not punish honesty. 2. **Trace the data**: for each tool, establish what company data goes in and where it physically lives. 3. **Sanction a place**: give builders a governed environment so the right path is the easy path. 4. **Log by default**: make access control and audit trails a standing requirement for anything touching company data. 5. **Pilot one process**: take the most-loved shadow prototype and rebuild it governed. According to BitSwan, the first one can be live in a week. BitSwan's NIS2 page describes shadow AI as "the biggest audit gap most companies don't know they have" and says Bailey's controls close it. ## How BitSwan works: from idea to production {#how-it-works} A BitSwan automation goes from idea to production in five steps inside Bailey: a plain-language description, a coding agent that builds it, requirements enforced as tests, a reviewed deploy to development, and a promotion through staging to production. BitSwan's homepage shows this as screens of the actual product, not a diagram, and summarises it as: a person describes a process, Claude Code builds it, the tests gate the deploy, and nothing reaches production without a frozen, audited version. **The five steps.** Each business process in Bailey has the same five tabs: 1. **Description**: write the process in plain language and attach existing material. 2. **Coding Agent**: Claude Code works inside the workshop, with its own containers. 3. **Requirements & tests**: every requirement is a test, and all of them must pass. 4. **Deploy**: the builder's branch goes into main, then to dev. The diff is shown on the same screen. 5. **Deployments**: promote, freeze and audit. Firewall and supply chain are tabs on the same screen. **The worked example on the homepage.** The tour follows one business process, "invoice-matching": - The description says supplier invoices arrive in a shared mailbox, each is matched to its purchase order by supplier, amount and date, and matched invoices are posted to the accounting system. Anything over 50 000 CZK, or anything that does not match, goes to a named approver before posting, and the system keeps a record of who approved what. Two files are attached: a process PDF and a spreadsheet of sample invoices. - Claude Code proposes three containers (a mailbox watcher, a matcher with the 50 000 CZK rule, and an approval screen), writes the backend and frontend code, and generates 31 tests from the sample file. Because the bank's API host is not yet approved, the agent stubs the posting step until IT allows that host in the firewall. - The tests screen shows requirements such as "Every invoice is matched to exactly one purchase order, or flagged", "Matched invoices are posted to accounting with the PO number", "Invoices over 50 000 CZK are held for approval before posting", "An approval records who approved, and when" and "Duplicate invoice numbers are rejected". While 2 tests fail, the screen states that all tests must pass before the process can be deployed. - The Deploy screen shows 31 of 31 tests passing, the files changed with line counts, and the diff. It publishes the builder's work into the main code area and then builds and deploys every container in the business process to dev. - The Deployments screen shows the three containers promoting together through Development, Staging and Production, with tabs for deployment history, secrets, containers, backups, firewall and supply chain. **What IT sees and what the agent cannot see.** According to BitSwan, every screen in the tour is visible to the admin: the description, the agent's chat, the tests, the diff, and the history of who promoted and signed what. The coding agent cannot see production. It works in dev with its own database, file store and network. Promotion to staging and production is a human decision, and it is recorded. **The gates between a commit and production.** BitSwan describes six gates. Each is a button in the product, and each leaves a record: 1. **Promote**: moves a version from dev to staging. All tests must pass first; the deploy button does not allow anything else. 2. **Freeze**: locks the exact version on staging so nothing changes while the auditor reviews it. 3. **Audits**: an independent auditor reads the frozen version and signs it. A counter (for example "Audits 0/1") shows progress. 4. **Freeze to unlock**: promotion to production stays locked until the version is frozen and the audit is signed. 5. **Restore**: one press returns production to the previous signed version. 6. **Disaster recovery**: a separate stage with its own backups, so "a bad day costs you a rollback, not your data". **Firewall, supply chain and secrets in the tour.** The homepage's Deployments screen shows: - Firewall rules listing each outbound host as allowed or denied, who approved it and when, and which stages it applies to. Requests the automation made that IT has not approved appear as denied, and a default rule denies all other traffic in staging and production. - A supply-chain view that lists components with version, severity and status (for example "fixed in image", "not reachable" or "accepted"), an SBOM attached to the container image, and a blocker count that decides whether promotion is allowed. - Secrets that are scoped to particular containers and stages, injected at runtime and "never in the repository". - A deployment history in which each version shows who built it, that it was frozen, and who audited it. **Shadow vibe-coding compared with work inside a Bailey.** BitSwan's homepage contrasts the same people with the same AI tools in two settings: | Aspect | Shadow vibe-coding | Inside a Bailey | |---|---|---| | Where it runs | On a laptop: automations built with Claude and dashboards in Lovable, none of it visible to IT | In a workshop: people use the same agents in a place IT can see and control | | Production | One bad prompt away; nobody meant the agent to reach production | Out of reach: the agent works in dev and production only takes a frozen, audited version | | Security | Unknown: nobody knows what the code does, what it connects to or where it sends data | Enforced: default-deny egress, sealed secrets and isolated stages on every app, built in | | Compliance | Unprovable: no record of who did what or where the data went | Writes itself: append-only history for NIS2, DORA, ISO 27001, SOC 2 and GDPR | | Finding an app | Duplicate tools, no owner, no idea which one is the real one | One catalogue: employees open approved apps from one place, admins decide what is approved, each app has one owner | **What crosses the Bailey boundary.** BitSwan describes a Bailey as "the line between your people's ideas and your production systems", where everything that crosses is on the record. Going in: staff prompts, company data inside the company network, secrets sealed at the edge, the AI model (self-hosted or by API), and Claude Code, Codex or any other agent. Inside, work moves from build (in dev) to audit (signed off) to ship (to production), and every step is logged. Going out: traffic to approved hosts only, the audit log to the customer's SIEM, apps that staff open from a catalogue, and "nothing else". ## Bailey, the governed runtime {#runtime-overview} Bailey is BitSwan's private, access-controlled runtime environment that belongs to the customer; everything built with BitSwan runs inside one. BitSwan states that governance in Bailey is "built in, not bolted on", which is why things people build there "don't die at the IT border". BitSwan positions Bailey as "audit ready from day one". It is not a compliance layer added before an audit. The runtime itself enforces the rules, so the right path is the easy path. BitSwan argues this removes shadow IT because doing things properly becomes more convenient than going around. The product page summarises Bailey as secure, portable, auditable and enterprise. **What IT gets from Bailey.** - **Access control**: the customer decides who can build, who can run and who can see, and the runtime enforces it per user and per automation. - **Audit logs**: every action is recorded as it happens, so the answer to an auditor's question is already written down. The log is append-only, so not even the operator can edit it, and it can be exported for auditors and sent to the customer's SIEM. - **Secrets management**: tokens and credentials are held as sealed secrets, so they are never pasted into code or left in a spreadsheet. - **Environments**: development, staging and production, each with its own database, file store and network. Every deployment is versioned and logged and can be moved forward or rolled back with one press. - **Data residency**: a Bailey runs on the customer's servers, a private cloud or a public cloud, so data stays where the customer decides. - **Model choice**: where the AI model runs is a customer setting, either fully self-hosted or an API model where that fits policy. In both cases what the model sees is controlled and logged. - **Default-deny egress**: outbound traffic in staging and production goes only to hosts IT has approved, and every approval is logged. - **App catalogue**: employees open approved apps from one catalogue, and admins decide what is approved. **The Bailey logbook.** BitSwan's product page shows Bailey's logbook, which records everything people and agents do inside the runtime as it happens. In the example, a highlighted entry marks something attempted without permission that the runtime stopped. **"A Bailey, not Broadway."** BitSwan's principle is: "Your strategy belongs in a Bailey, not on Broadway." "Broadway" stands for someone else's cloud: someone else's rules, no-code ceilings and data that cannot be located. A Bailey is the customer's own runtime, with the customer's rules and no ceiling on what is built in it. Every automation a team creates is an asset the company owns, not a subscription it rents. BitSwan adds that this ownership is why the things built "don't fall down when a vendor changes their pricing page". **Bailey on BitSwan's own site.** The bitswan.ai homepage notes that the page itself is served from a Bailey. ## Bailey platform reference {#platform-reference} The sections below document every capability of the Bailey platform, one section per topic, from claiming a server to leaving with the source code. Each section states what the capability is, the facts that define it, how it is used, why it matters, and which NIS2, DORA, ISO/IEC 27001, SOC 2 and GDPR controls it maps to. The mappings describe how platform features support those controls; they are not certifications. ## What Bailey is {#what-bailey-is} Bailey, by BitSwan, is a fully functional business-process automation platform that is ready and compliant out of the box, rather than a kit of parts that the customer has to assemble and certify itself. Staged deployment, one-click disaster-recovery rehearsals, supply-chain scanning, device-bound access and a self-writing GDPR record are built into the platform from the start. The Bailey handbook contrasts this with two older approaches to business-process automation. The first is the parts-catalogue approach, where the customer receives components and is expected to wire, integrate and certify them alone. The second is the "off-the-shelf" platform designed before the agentic-coding era, which the handbook describes as unfit for production use next to what is now possible. Bailey's position is that operators should spend their effort on what the business process does, not on building and certifying the platform underneath it. **Key facts** - Staged promotion: Bailey promotes a business process from dev to staging to production across three blue-green slots over two persistent databases. The live slot stays up during a release, and the standby slot is always one cutover away. - Disaster-recovery rehearsal: any production backup can be restored into an isolated DR slot, verified by hand, marked recovery-tested and then swapped live with a single ingress cutover, with no data move and no downtime. - Supply-chain scanning: every image is scanned for CVEs before deploy. Waivers live in the source tree rather than in configuration, so auditors get a clean, signed record. - Device-bound access: the first operator claims the server, and every device after that must be explicitly approved. Business processes stay protected even if a password leaks or the identity provider is compromised. - Built-in hosting: a business process's frontend and backend run inside Bailey from the moment the process is created, with a real, TLS-secured hostname on day one and no web host, DNS or certificate to arrange. - No lock-in: a customer can point its own domain at an app later or host the app somewhere else entirely, because an admin can mirror the workspace to a git remote the customer controls. - Self-writing GDPR record: a GDPR record that writes itself is one of the capabilities built into Bailey. **Why it matters:** Automation platforms usually leave the hardest parts to the customer: release safety, recovery testing, dependency scanning, access control and compliance evidence. Bailey ships these as defaults, so a team can concentrate on the processes it is automating instead of on installing and certifying the platform that runs them. ## Server claim and device trust {#bailey-device-trust} Device trust in Bailey binds access to approved hardware as well as to a user's identity. The first operator to sign in claims the server and becomes root admin, and the browser they claimed from becomes the first trusted device; every device after that must be approved by someone who already holds a trusted device. The first operator signs in through the organisation's identity provider at the onboarding host and presses Claim this server. That browser is enrolled as the first trusted device, and its cookie then proves the hardware, not just the credential. A new device shows a six-digit code and waits until a trusted operator links it from Your devices → Link a device. This gate sits in front of everything: the Bailey console and every workspace app run behind it. Bailey has three levels of device trust. An untrusted device reaches nothing. A fully trusted device, approved through the six-digit code, reaches everything the user has access to. In between sits the magic link, intended for a low-sensitivity production endpoint such as a public demo registration form. An admin or auditor who owns that endpoint can mint a magic link from the endpoint's Share dialog. Anyone who opens it and signs in has their browser trusted for that one endpoint only. The browser is never fully trusted, and the person is never added to the access list; the endpoint's ACL still decides who gets in. The magic link only removes the need to approve a code per device where that friction outweighs the risk. **Key facts** - The first operator to claim a Bailey server becomes root admin, and their device becomes the first trusted device. - A new device displays a six-digit code and must be approved from an already-trusted device via Your devices → Link a device. - The device-trust gate fronts the Bailey console and every workspace app. - Bailey has three trust levels: untrusted (no access), fully trusted (everything the user has access to) and magic-link trusted (one endpoint only). - Magic links work on production endpoints only. - Only a user who both owns the endpoint and holds the admin or auditor role can mint a magic link, from the endpoint's Share dialog. - A magic link never grants full device trust and never adds anyone to the endpoint's access list; the endpoint's ACL still applies. - Devices can be revoked from People & roles. **How it is used** 1. Sign in at the onboarding host. 2. Click Claim this server; the user becomes root admin and the current device is trusted. 3. A new device shows a six-digit code and waits for approval. 4. Approve the device from a trusted device, or revoke it from People & roles. 5. For a low-sensitivity production endpoint, mint a magic link from its Share dialog instead of approving each device. **Why it matters:** Bailey practises defence in depth. The handbook calls the model end-to-end authentication: Bailey is an isolated, self-protecting system, so a stolen password, or even a fully compromised identity-provider or SSO account, does not compromise Bailey or reach the business processes behind it. **Compliance mapping** - **NIS2 Art. 21(2)(j)** — Multi-factor authentication and secured access: device trust is a strong second factor bound to hardware, matching the "MFA or continuous authentication" the directive expects. - **SOC 2 CC6.1** — Logical access security: the gate authenticates and authorizes every request before it reaches a workspace app. - **ISO/IEC 27001 A.5.15 / A.8.5** — Access control and secure authentication: access is granted per identity and per device, and is centrally revocable. - **DORA Art. 9(3)** — Strong authentication mechanisms: protection of ICT systems requires robust access control, and the gate provides it uniformly. ## Workspaces {#bailey-workspaces} A workspace in Bailey is a thematic access-control boundary: an isolated tenancy scoped to one body of work and the team that does it. Who can see and do what is decided per workspace. Workspaces are organised by theme, not by company. A finance team that automates invoice processing would work in a Finance workspace shared only with the people automating finance processes; a separate Logistics workspace would be its own tenancy and invisible to them. Each workspace has its own business processes, its own data and its own roster of members, and only people granted into it, at the role they are given, can reach its apps. A workspace is therefore a blast radius for access. Workspaces are created from the Bailey Server Console, and the user who creates one becomes its owner. Creation is a live, streamed operation: the operator watches gitops, ingress and the dashboard come up before the workspace appears with an Open button. Promotion from dev to staging to production is a separate concept that happens inside a business process, not at workspace level. **Key facts** - A Bailey workspace is an isolated tenancy with its own business processes, data and member roster. - Workspaces are thematic (for example Finance or Logistics), not one per company. - The user who creates a workspace becomes its owner. - Workspace names are lowercase and hyphenated. - Provisioning is streamed live: gitops, ingress and the workspace dashboard come up in view before the Open button appears. - Members are invited at a specific role, and roles are enforced server-side per workspace. - Dev, staging and production stages belong to business processes, not to workspaces. **How it is used** 1. Open Workspaces in the console. 2. Click New workspace and give it a lowercase, hyphenated name; the creator becomes the owner. 3. Watch it provision, then press Open to enter its dashboard. 4. Invite members at the role they need. **Compliance mapping** - **ISO/IEC 27001 A.8.3 / A.5.15** — Information access restriction and access control: a workspace scopes who can reach its processes and data, and access is granted per workspace. - **SOC 2 CC6.3** — Role-based access: membership and roles are assigned per workspace and enforced server-side. - **NIS2 Art. 21(2)(i)** — Asset management and access control: every workspace and its endpoints are inventoried and owned. ## Server overview and endpoint inventory {#bailey-server-overview-endpoints} The Bailey console's Server overview and Endpoint access pages form a live asset register of the server: they inventory every workspace, route and protected endpoint, together with the owner of each endpoint and the workspace it belongs to. The Server overview gives the operator situational awareness: the number of workspaces, the number of trusted devices and the health of the platform's own services. Endpoint access lists every protected hostname that the device-trust gate fronts, including workspace dashboards, gitops and automation frontends, each with its owner and its workspace. Both pages are built from real, live state rather than from a separately maintained list. **Key facts** - Server overview shows workspace count, trusted-device count and the health of Bailey's own platform services. - Endpoint access lists every protected hostname behind the gate: workspace dashboards, gitops and automation frontends. - Every endpoint is shown with an explicit owner and the workspace it belongs to. - The inventory is generated from live state, so it answers the audit question "what is exposed, and who owns it?" directly. **How it is used** 1. Open Server overview for platform health and counts. 2. Open Endpoint access to see every protected route. 3. Confirm each endpoint has the right owner and workspace. **Why it matters:** When an auditor asks what is exposed and who owns it, the answer in Bailey is a single page rather than an afternoon of collecting information. **Compliance mapping** - **ISO/IEC 27001 A.5.9** — Inventory of information and other associated assets: every workspace and protected endpoint is enumerated from real, live state. - **NIS2 Art. 21(2)(i)** — Asset management: the estate of exposed services is inventoried with ownership. - **SOC 2 CC6.1** — Logical access security: each endpoint sits behind the gate with an explicit owner. ## Device management and lost-device response {#bailey-your-devices} The Your devices page in Bailey lists every browser tied to a user's identity as a named, trusted device that the user can see, label and revoke. Removing a device revokes its access across the whole platform instantly, which makes it the incident response for a lost or stolen device. Each device carries a badge: Root device (the device that claimed the server), Admin-approved, or Linked, and the page marks which device is in use right now. The same page is where a user links a new device by typing the six-digit code that the new browser is showing. Because Bailey binds access to the device and not only to the password, a thief holding an unlocked laptop already has a valid session, and rotating the password alone does not lock them out. Removing the device does: it revokes that device's cookie across the entire platform, so the console and every workspace app stop trusting it immediately. Bailey labels a new device from its browser, so several browsers on one machine look alike until the user renames them; naming every device is what lets an operator pick the right one to cut under pressure. **Key facts** - Device badges in Bailey are Root device, Admin-approved and Linked; the current device is marked. - A new browser is admitted by entering its six-digit code under Link a device. - Devices are renamed with the pencil icon beside the name; Bailey's default label comes from the browser. - Removing a device revokes its cookie across the console and every workspace app at once. - A password reset does not end a stolen device's session; removing the device does. **How it is used** 1. Open Your devices in the console. 2. Review trusted devices and their badges. 3. Name each device with the pencil icon so that several browsers on one machine can be told apart. 4. To admit a new browser, enter its code under Link a device. 5. If a device is lost or stolen, remove it here; its access is revoked everywhere instantly. This, not a password reset, is the response. **Why it matters:** Device-bound access means a stolen, unlocked laptop is a live session that a password change cannot stop. One click on the device list revokes it everywhere, and keeping devices named lets an operator identify the right device without hesitation. **Compliance mapping** - **SOC 2 CC6.2 / CC6.3** — Access provisioning and de-provisioning: devices are granted and revoked centrally and immediately. - **ISO/IEC 27001 A.5.15 / A.8.1** — Access control and user-endpoint devices: trusted devices are enrolled, labelled and revocable. - **NIS2 Art. 21(2)(j)** — Secured access: hardware-bound trust is enrolled and managed per person. ## Personal copies and experiments {#bailey-copies-and-experiments} A personal copy in Bailey is an isolated branch of a workspace that every operator gets automatically and works in by default; nothing done in it touches main until the operator presses Deploy. An experiment is a throwaway branch off the operator's own copy, scoped to exactly one business process, used to try an idea and then merge it, adopt it or discard it. Every operator gets exactly one personal copy, created and selected by Bailey the first time they open the workspace dashboard. There is no branch to name and no copy to create, and the top bar deliberately has no copy control at all: no dropdown, no chip and no copy name. The bar shows the business process and then the tabs Description → Coding Agent ↻ Requirements → Deploy, all of which act inside the operator's copy. In the copy the operator can edit, build and preview without disturbing anyone else's work or the live main. Everything else about copies sits behind a single Advanced menu on the far right. See a colleague's version lists every other operator's copy, and expanding one shows that colleague's experiments on the current business process. Opening one shows an amber banner, "You are in ⟨name⟩'s copy — your edits save to their copy" (or their named experiment), with a Switch back to my copy button. Colleagues' copies are not locked: an operator can edit a colleague's copy exactly as their own, and the banner exists so they always know whose copy they are changing. An experiment is named after what is being tried (for example "Check vendor VAT-IDs against ARES"), never by a branch name. Bailey commits the copy's current state of that business process, branches from exactly that state and opens the experiment under a green banner: "You are in an experiment on ⟨business process⟩: ⟨title⟩". The banner offers four ways out: - **Back to my copy** returns to the operator's copy and leaves the experiment running under Advanced, ready to re-enter. It does not end the experiment. - **Merge back into my copy** fast-forwards the work into the copy, refreshes the copy's live-dev deployment, discards the experiment and returns to the copy. If the copy has moved on far enough to conflict, the merge does not guess; it hands the rebase to the coding agent, working inside the experiment. - **Discard experiment** is a real delete of the branch, its files and its live-dev containers, behind a confirmation dialog that names the unmerged work it would destroy. - **Use this version without merging** makes the copy become the experiment, with no merge and no conflict resolution. Whatever the copy held for that business process, uncommitted edits included, is first parked as a new experiment titled "My previous ⟨process⟩ work — ⟨date and time⟩"; if there was nothing to save, none is created and the operator is told so. The source experiment is then closed. The result always lands on top of main: if the experiment already contained main it fast-forwards and keeps its own commits, and if the two had diverged a single restore commit carries the experiment's content on top of main, so the next Deploy is a plain fast-forward with no Sync step. A copy covers the whole workspace, while an experiment covers one business process, because each business process is its own git repository. An experiment spanning several processes would be several unrelated branches. Bailey therefore lists only the current process's experiments under Advanced ("No experiments on ⟨process⟩" when there are none), the server refuses to bring any other process into an experiment, and switching to another process while inside an experiment returns the operator to their own copy with a message saying so. An experiment can never reach main. Inside an experiment the Deploy tab is not rendered, and the server refuses a publish from an experiment even if one is requested. Work leaves an experiment only by being merged into the copy it branched from, and leaves a copy only through a deliberate Deploy: one funnel, in one direction, with a person's name on every hop. **Key facts** - Each Bailey operator has exactly one personal copy per workspace, created and selected automatically on first visit. - The top bar has no copy selector; colleagues' copies and experiments are reached through Advanced → See a colleague's version. - Editing a colleague's copy is allowed and is flagged by an amber banner; experiments are flagged by a green banner. - An experiment belongs to exactly one business process, because each business process is its own git repository. - Experiment exits: Back to my copy (keeps it running), Merge back into my copy, Use this version without merging, and Discard experiment. - Merge conflicts are handed to the coding agent to rebase inside the experiment rather than resolved automatically. - Use this version without merging parks the copy's previous work as a dated experiment, so nothing is lost. - Discarding an experiment deletes its branch, files and live-dev containers after a dialog listing the unmerged work. - The Deploy tab is not rendered in an experiment, and the server refuses publishes from one. - The only route into main is experiment → personal copy → Deploy. **How it is used** 1. Press Open on the workspace to enter its dashboard; the operator's own copy is already active. 2. Open Advanced → See a colleague's version to read someone else's copy, or expand it to open one of their experiments; press Switch back to my copy when done. 3. Select a business process, open Advanced → Start a new experiment and name what is being tried; the green banner names the process. 4. Work in the experiment exactly as in the copy: same tabs, same live-dev, on its own branch of that one process. 5. Switching to a different business process leaves the experiment and returns to the operator's own copy. 6. Press Merge back into my copy to land the work in the copy; the experiment is discarded automatically. 7. Or press Use this version without merging to make the copy become the experiment; the previous work is parked as a dated experiment and the source experiment is closed. 8. Press Back to my copy at any point to step out and leave the experiment running under Advanced → Experiments on ⟨process⟩. 9. Or press Discard experiment to delete it entirely. 10. Everything built stays in the copy until the operator presses Deploy. **Why it matters:** Isolated copies give environment separation by default, and experiments make trying an idea cheap: branch off the copy, prove the idea, then merge it or throw it away while the shared main is never at risk. Every hop is explicit and attributable, and the only route into main is a deliberate Deploy from the operator's own copy. **Compliance mapping** - **ISO/IEC 27001 A.8.31** — Separation of development, test and production: a personal copy, and any experiment branched off it and scoped to a single business process, isolates work in progress from main and from every deployed stage; an experiment has no path to main at all. - **ISO/IEC 27001 A.8.32** — Change management: a change travels a fixed, recorded route (experiment → personal copy → main), with each hop an explicit, attributed action rather than a side effect. - **SOC 2 CC8.1** — Change management: changes originate in an isolated copy and reach main only through a deliberate Deploy; nothing merges itself. - **NIS2 Art. 21(2)(e)** — Security in development: experimentation happens in a disposable branch of the developer's own copy, so unreviewed work can never become the shared baseline. ## Business processes {#bailey-business-processes} A business process in Bailey is the unit that is built, shipped and operated. Creating one scaffolds its automations, a backend and a frontend, and the process becomes the boundary for its description, code, CVE checks, stages, secrets, backups and firewall. A business process is created from the New business process modal with a lowercase, hyphenated name. The frontend it scaffolds is not a mock-up: it is the process's production web app. As soon as it runs, Bailey gives it a real, routable hostname with TLS already in place, on the Bailey server's own domain, so there is no separate hosting account, DNS zone or certificate to set up. A custom domain can be added later but is never required. If the organisation prefers to host the app elsewhere, an admin can mirror the workspace to a git remote of the organisation's own, so the source is not locked in. The backend stays off the public internet entirely and is reachable only from the frontend over the workspace's private network. **Key facts** - Each new Bailey business process is scaffolded with two automations: a backend and a frontend. - Business process names are lowercase and hyphenated. - The frontend is the production web app and gets a TLS-secured, routable hostname on the Bailey server's domain as soon as it runs. - A custom domain is optional. - The backend is not exposed to the public internet; only the frontend can reach it, over the workspace's private network. - An admin can mirror the workspace to an external git remote, so the source can leave with the customer. - Description, code, CVE checks, stages, secrets, backups and firewall are all scoped per business process. **How it is used** 1. Open the business-process switcher at the top left. 2. Click New business process. 3. Name it in the modal and press Create. 4. The process is scaffolded and selected. **Compliance mapping** - **ISO/IEC 27001 A.5.9** — Inventory of assets: each business process is a named, owned unit of the estate. - **ISO/IEC 27001 A.8.25** — Secure development lifecycle: work is organised per process, with its own pipeline and controls. ## Process description and flowcharts {#bailey-process-description} The Description tab in Bailey holds a living specification for each business process, typically what it does, for whom and the rules it must keep. The description is versioned with the process's code, so documentation lives next to the code instead of in a separate wiki. The editor is rich text with Markdown shortcuts. Process flows are drawn rather than written as diagram code: the toolbar's Insert flowchart button opens a flowchart editor where the operator drops nodes of type Process, Decision or Terminal, drags from one node's handle to another to connect them, labels them, and presses Save diagram to insert the rendered flowchart into the spec. Edits autosave with an on-screen indicator, and Ctrl+S saves at once. Saving is not versioning: the text becomes a version of the process at the next Deploy or Sync. **Key facts** - Every Bailey business process has a Description tab with a rich-text editor that supports Markdown shortcuts. - The flowchart editor offers three node types: Process, Decision and Terminal. - Save diagram inserts the rendered flowchart directly into the specification. - Edits autosave; Ctrl+S forces an immediate save. - The description becomes a version of the process at the next Deploy or Sync, not at save time. - The specification is the input the coding agent builds from (see the Build automation button). **How it is used** 1. Open the Description tab. 2. Write the specification in rich text. 3. Click Insert flowchart in the toolbar and draw the flow: add nodes, drag to connect, then Save diagram. 4. Edits autosave and Ctrl+S saves at once; the text becomes a version at the next Deploy or Sync. **Compliance mapping** - **ISO/IEC 27001 A.5.37** — Documented operating procedures: the process and its rules are written down and kept current alongside the code. ## Coding agent and requirements {#bailey-coding-agent-requirements} The Coding Agent in Bailey is an AI coding agent that runs inside the platform, builds a business process's automations from its specification in the operator's isolated copy, and is walled off from production data. Its companion, the Requirements & tests tab, holds the process's rules as runnable checks, each tracked by status. The Coding Agent tab provides a chat panel and a file tree inside the workspace. The agent works in the operator's isolated copy. It can reach the internet to do its job, but it cannot reach the production database or the user data in it, and its egress is constrained by the workspace firewall allow-list. Everything it produces still passes the Deploy tab and the CVE checks before it ships. Changes do not have to go through the agent. The Coding Agent tab's Files sub-tab is a full editor over the copy's working tree; edits autosave and ⌘/Ctrl+S saves at once. One example is setting a background worker's `memory_reservation_policy` to `always-on` in its `automation.toml`, so that a worker with no inbound requests to wake it stays resident instead of pausing when idle. Like every change in a copy, a manual edit does not touch main until Deploy, and becomes a version on the copy's branch at that Deploy or at a Sync, not when it saves. Each automation in a copy also gets a live-dev deployment: a running preview that rebuilds automatically as code changes. The operator opens it from the frontend automation's link in the Environment panel and clicks through the real app before anything reaches main. Requirements are not transcribed by hand. The Build automation button on the Description tab, next to Save, hands the specification to the agent, which builds from it, brings up the live-dev preview and proposes the requirements it reads out of the spec. Agent proposals get `AI-` ids and wait for the operator to accept, reword or drop them; requirements the operator writes get `REQ-` ids, so the list always shows which rules came from a person. The Write tests button sends the agent back to cover requirements with real tests. A requirement's status is the agent's work queue. A requirement the operator writes starts as `pending` (recorded, not yet tested). The Requirements next action hands the agent the first requirement in tree order that is not `pass`, so `pending`, `fail` and `retest` all count as work to do and only `pass` removes a requirement from the queue. Operators do not set `pass` or `fail`: those come from a test run or from the agent recording what it found while building. Operators can accept a proposal, which moves it into the contract so it gets tested, or send a passing requirement back to be re-checked. `proposed` is the only status that means "not yet part of the contract", and test runs skip proposed requirements. Status and test coverage are tracked separately: the tab scans for a test carrying the requirement's id, so a requirement can read `pass` on a judgement alone, the agent's or the operator's, with no test behind it. **Key facts** - The Bailey Coding Agent runs inside the platform in the operator's isolated copy, not beside it. - The agent has internet access but cannot reach the production database or production user data. - The agent's egress is constrained by the workspace firewall allow-list. - Agent output passes the Deploy tab and CVE scanning before it ships. - The Files sub-tab is a full manual editor over the copy; ⌘/Ctrl+S saves immediately. - Each automation in a copy has a live-dev deployment that rebuilds as code changes. - Requirement ids: `AI-` for agent proposals, `REQ-` for human-written requirements. - Requirement statuses: `proposed`, `pending`, `fail`, `retest` and `pass`; only `pass` leaves the work queue, and `proposed` requirements are not tested. - Operators cannot set `pass` or `fail` directly; they can accept a proposal or send a passing requirement back for re-checking. - Test coverage is tracked separately from status: a requirement can show `pass` without a test. **How it is used** 1. Open the Coding Agent tab and start a session against the copy. 2. Or press Build automation on the Description tab: the agent builds from the specification, the live-dev preview comes up and testable requirements are proposed. 3. Edit files by hand in the Files sub-tab when needed; changes autosave and stay in the copy. 4. Click a running automation's frontend to open it and click through it. 5. Open Requirements & tests, accept or reword the agent's `AI-` proposals, add any `REQ-` requirements, press Write tests to get them covered, then press Deploy. **Why it matters:** What matters about the Bailey Coding Agent is where it runs. Inside an isolated copy, behind the workspace firewall and away from production data, its output is reviewed, scanned and deliberately deployed like any other change, and the Requirements & tests tab turns "does it still do what we promised?" into a button rather than a meeting. **Compliance mapping** - **ISO/IEC 27001 A.8.25 / A.8.31** — Secure development lifecycle and environment separation: the agent builds in an isolated copy and sandbox, never touching production directly. - **NIS2 Art. 21(2)(e)** — Security in development: agent output is CVE-scanned and reviewed before deploy. - **SOC 2 CC6.6** — Boundary protection: the agent's egress is constrained by the workspace firewall allow-list. - **DORA Art. 24–26** — Resilience testing: requirements are runnable specifications, re-run on demand. ## Development, staging and production stages {#bailey-stages} Bailey promotes every business process through three stages, Development, Staging and Production, and each stage runs on its own database, its own file store and its own isolated Docker network. The data of one stage is never the data of another, and the stages cannot reach each other over the network. Because each stage has separate data and a separate network, records, attachments and ledger entries in one stage never appear in another, and user and production data is never shared across stages. Operators can run an application in dev and exercise it hard in staging with wrong totals, malformed VAT numbers and deliberate edge cases without touching real production data, because that data is not present in those stages. The stage split is also a separation of duties. Production has its own gate, so an experienced team member can audit and review code before it reaches production. A member builds and ships through dev and staging, and promotion to production is a deliberate, reviewable step. The Development stage runs whatever is on main: nothing lands there until the operator presses Deploy, which publishes the operator's copy into main and rolls it out to Development. **Key facts** - Bailey has three stages per business process: Development, Staging and Production. - Each stage has its own database, file store and isolated Docker network, and the stages cannot reach one another. - Production data is never present in Development or Staging. - The Development stage runs what is on main; Deploy publishes the operator's copy into main and rolls it out to Development. - Promotion from Development to Staging and from Staging to Production is a separate, explicit step. - Promotion to Production is designed to follow sign-off by an experienced reviewer, giving separation of duties. - The pipeline is shown on the Deployments page. **How it is used** 1. Open Deployments and read the pipeline: Development, Staging, Production. 2. Build and test in the personal copy; press Deploy to publish it into main and roll it out to Development. 3. Once it runs in Development, promote it to Staging and exercise the app on staging's own data. 4. Have an experienced reviewer sign off before the deliberate promotion to Production. **Why it matters:** Three stages, three databases, three file stores and three isolated Docker networks mean testing in dev and staging can never expose or corrupt real production data, and production changes pass through a reviewable promotion. Separation of duties and environment isolation come from the stage model itself rather than being added later. **Compliance mapping** - **ISO/IEC 27001 A.8.31** — Separation of development, test and production environments: dev, staging and production each run on their own database, file store and Docker network, the stages cannot reach one another, and production data is never present in a test stage. - **SOC 2 CC8.1** — Change management: changes are built and tested in lower stages and reach production only through a deliberate, reviewable promotion. - **GDPR Art. 5(1)(c)** — Data minimisation: real personal data lives only in production, and dev and staging are tested without production user data. ## Deploy and Sync: shipping a change to main {#bailey-deploy-and-sync} Deploy in Bailey is the single action that publishes one business process into the protected main branch and rolls it out to the development stage. Sync is the separate step that brings work a colleague has already published to main into that business process first, and it is the one place in Bailey where divergence from main is resolved. One Deploy button does the whole sequence for the business process that is selected: it commits the work in progress, fast-forwards main to it, and rolls it out to development, tracking the single deploy it started rather than starting a second one. While it runs, the button reads Working… and a scrollable Build log opens beneath the header. The log streams every line of the deploy: each container's image build, the `build.sh` step that compiles the production bundle (`vite build` or `go build`), and the per-process Prepared markers. Around the Deploy button sit three review tabs: the Diff (exactly what becomes main), the History (the copy's and main's commits, with deploy markers) and the Supply Chain Security tab (the precise CVEs of the image this deploy would build). Deploy is fast-forward-only in two senses. It only ever moves main forward, and it only ever publishes the selected business process, because each business process is its own git repository; shipping one process cannot carry along a half-finished change in another. If a teammate published to main in the meantime, the copy is behind and Bailey refuses to deploy: instead of a disabled button, the action is replaced by the sentence "Main has changes you don't have yet — sync first." and a Go to Sync button. The Sync step appears as the first tab, before Description, only while that process's main has commits the copy lacks and only on the user's own copy; it disappears once the copy is level. It names each incoming commit with subject and author, and its one button, Pull main into ⟨process⟩, replays the user's work on top of main and refreshes the live-dev preview if the image changed. A genuine conflict is handed to the coding agent to finish by hand. Sync is per business process: a process that is level shows no Sync step even if another process in the same copy is many commits behind. The Sync step and Deploy's "sync first" come from the same measurement, so they cannot disagree. ### Deploy this version, overwriting main Beside Go to Sync, Bailey offers a deliberately quiet alternative, Deploy this version, overwriting main…. Its dialog reads main live and lists every commit the copy does not have, with message, author and short id. If that list cannot be read, the button stays disabled and the dialog says why. Confirming requires typing the business process's own name, the same guard rail used for a production data restore. The outcome is fixed: main ends up holding exactly what the copy holds, including dropping anything main added that the copy lacks; there is no mode or merge rule to choose. History is preserved: the user's commits are replayed onto main's tip one by one rather than flattened, and where main's extra files would remain, one further commit makes the tree identical and visibly drops them. Main's own commits stay underneath and reachable; nothing is rewritten or force-pushed. Before publishing, Bailey checks that the published tree is byte-identical to the copy, and publishes nothing otherwise. A conflict no rule can decide (one side deleted a file the other edited) changes nothing and is handed to the coding agent, as with a blocked Sync. ### Edit this version and Revert dev to this version Any deployment's Inspect dialog has Edit this version, which turns the user's copy of that business process into that exact deployed version as a restore commit on top of main, leaving the copy one commit ahead and none behind so it can be fixed and deployed without syncing. Whatever the copy held before is parked as a dated experiment. Only versions this workspace actually deployed for that business process are accepted, not an arbitrary commit id. On the development stage, Inspect also offers Revert dev to this version (distinct from the Roll back button on history rows, which puts one stage back without touching main). Because dev deploys from main, reverting dev is one new commit on main, attributed to the user; the broken version stays in history. The dialog states that every other copy goes one commit behind on that process and that their next Sync carries the revert in, with their unpublished work replayed on top. Staging and production have no such button; they go back through promote and rollback. ### Marking CVEs out of scope A finding that does not apply (an unreachable code path, a false positive, a risk handled elsewhere) can be marked out of scope from the Supply Chain Security tab. The decision is written into the business process's source tree in `cve-waivers.yaml`, versioned in git, with who marked it, when and why, and it travels to main with the next Deploy. Every out-of-scope CVE is listed in a dedicated audit-log section: on this tab a reviewer can restore it to in-scope, and on the production Supply chain tab it is shown read-only for auditors. **Key facts** - Deploy commits work in progress, fast-forwards main and rolls out to development in one action. - Main is a protected, fast-forward-only branch; Deploy never merges or force-pushes. - Each business process is its own git repository, so Deploy and Sync are always scoped to one process. - When the copy is behind main, Deploy is replaced by "Main has changes you don't have yet — sync first." and a Go to Sync button. - The Sync tab appears only while main has commits the copy lacks, lists them by subject and author, and offers Pull main into ⟨process⟩. - Deploy this version, overwriting main… requires typing the business process name, lists every superseded commit, and publishes only if the result is byte-identical to the copy. - Edit this version accepts only versions the workspace actually deployed for that business process. - Revert dev to this version exists only on the development stage; staging and production use promote and rollback. - CVE waivers live in `cve-waivers.yaml` in the source tree, with who, when and why. - The Build log streams image builds, the `build.sh` step and per-process Prepared markers. **How it is used** 1. Open Deploy. 2. If a Sync tab is showing, or Deploy says "sync first", open Sync, read the incoming commits and press Pull main into ⟨process⟩; the tab disappears once the copy is level. 3. Review the Diff, the History and the Supply Chain Security tab. 4. Mark any non-applicable CVE out of scope; it is recorded in the source tree with who, when and why. 5. Press Deploy; the copy fast-forwards into main and dev goes Healthy. 6. If the copy's version is the right one and syncing is not intended, use Deploy this version, overwriting main…, read whose commits it supersedes, and type the process name to confirm. 7. To start from a running version, open its Inspect in Deployments and press Edit this version; on development, Revert dev to this version puts the shared dev stage back for everyone. 8. Promote when ready. **Why it matters:** The vulnerability check runs on the image that will actually run, not on an older scan. Because publishing is fast-forward-only, nobody can ship over a colleague's change: their work is taken in first, deliberately, and the new change goes on top. Security review and integration are steps in the flow rather than separate gates. **Compliance mapping** - **ISO/IEC 27001 A.8.8** — Management of technical vulnerabilities: the image is CVE-scanned before it ships, with each finding linked to its advisory. - **NIS2 Art. 21(2)(e)** — Security in acquisition, development and maintenance, including vulnerability handling: waivers are versioned in-tree and reviewable. - **DORA Art. 8–9** — ICT risk identification and protection: pre-deploy scanning makes risk identification automatic and auditable. - **SOC 2 CC8.1** — Change management: commit, publish and deploy are one controlled, observable operation, refused outright when the copy is not a fast-forward of main. - **ISO/IEC 27001 A.8.32** — Change management: integration (Sync) is an explicit, attributed step separate from release (Deploy), each scoped to one business process. ## Staged deployment and blue-green promotion {#bailey-staged-deployment} Staged deployment in Bailey moves a change forward one stage at a time, development to staging to production, and every hop is a blue-green cutover. Bailey runs three app slots over two persistent databases, so the live slot keeps serving during a promotion and the standby slot is always one cutover away. When a stage is promoted, the idle slot comes up on that stage's live database, ingress repoints to it, and the old slot retires. The pipeline streams its live step while the standby slot builds and starts, and users see no gap. Promotion moves the image verbatim: Bailey re-deploys the exact bytes that were built and reviewed, even if the workspace source has changed since, so production runs precisely what was exercised in staging rather than a fresh rebuild. The pipeline shows which slot is live, which is standby, what is Healthy and the version each stage runs. Each stage carries two separate marks. A green-filled circle means something is deployed to that stage. A corner badge shows what the containers are doing: a green tick only when every container was seen running, a violet ↻ when one keeps restarting, a red warning when one is not running at all, a blue dot when the stage is asleep and will wake on access, and a grey dot when Bailey has not read that stage's containers. A stage can be filled green but not ticked, meaning the code is live but unhealthy; a tick is never given for an unchecked stage. A user-triggered action (restart, stop, wake) gets a third mark, a spinner on the opposite corner, until Bailey sees it through, so the user's action and the containers' state never overwrite each other. **Key facts** - Stages are development, staging and production, promoted one hop at a time. - Each promotion is a blue-green cutover: idle slot starts on the live database, ingress repoints, old slot retires. - Bailey uses three app slots over two persistent databases. - Promotion re-deploys the exact reviewed image bytes, never a rebuild. - Any team member can promote dev to staging; production requires a freeze and audit first. - Stage badges: green tick (all running), violet ↻ (restarting), red warning (not running), blue dot (asleep, wakes on access), grey dot (not read). - A spinner on the opposite corner marks an action the user triggered until Bailey sees it complete. - Staging uses its own data, never production's. **How it is used** 1. Open Deployments. 2. Press Promote all to Staging and watch the blue-green cutover come up Healthy. 3. Exercise the app on staging, which runs on its own data. 4. Freeze and audit staging, then Promote to Production. **Why it matters:** Every promotion is a zero-downtime blue-green cutover of the exact reviewed image, so promotions can happen during the working day and rolling back to the standby slot is just as fast. **Compliance mapping** - **ISO/IEC 27001 A.8.31** — Separation of development, test and production: a change is deployed through isolated stages, each on its own database and network. - **SOC 2 CC8.1** — Change management: changes reach production only through a deliberate, observable promotion of the reviewed image. - **DORA Art. 9** — Protection and prevention: zero-downtime cutovers minimise the impact of changes on the availability of critical functions. ## Freeze and audit: four-eyes approval for production {#bailey-freeze-and-audit} Freeze and audit is the Bailey gate that every change must pass before production. An auditor or admin freezes staging to lock the exact image under review, audits it inside a copy of that exact version, and signs off on a written report or proposes a fix; every freeze, policy change and verdict, with its report, is recorded in `bitswan.yaml`. Nobody promotes straight to production. Freezing staging locks the image under review to a fixed tag and closes dev-to-staging promotion, so the audited version cannot change during review. A normal member never sees a clickable Production promote button and hands off to an auditor, as segregation of duties requires. An audit policy sets how many auditor sign-offs (at least one) a frozen image needs; only when the policy is met does Promote to Production unlock, and a single Request changes holds the gate. Once the audited image reaches production, staging unfreezes automatically. Opening an audit gives the auditor the source the frozen image was built from, in an ordinary copy with the same coding agent, file explorer and diff used for everyday work. The audit report is a file alongside the source but kept out of it, so proposing a fix proposes code only. Nothing done in the copy can change the frozen image, because a sign-off attaches to the image's content hash. The report is scaffolded under four headings: What this version changes (starting from the diff against production), Risk (what this version could do that the last could not, such as new egress, new data, or a threshold in code instead of configuration), Verified (what was read or run, in repeatable detail) and Not verified (the remainder). The coding agent can draft the report, but the auditor is responsible for its claims. Approve and Request changes sit at the foot of the report, and the top bar offers Audit report or Propose a new version; either saves the report, reads it back and records it with the verdict. When a version is promoted to production, the verdicts that released it are written down and that image stops accepting new sign-offs, so a later opinion cannot rewrite what a past release was approved on. An auditor who finds a problem can fix it and deploy from the audit copy, which starts a new version in Development that goes through build, checks, staging, its own freeze and its own sign-off. **Key facts** - Only an auditor or admin can freeze staging; freezing locks a fixed image tag and closes dev-to-staging. - Normal members cannot promote to production. - The audit policy requires at least one auditor sign-off; one Request changes blocks promotion. - A sign-off is bound to the image's content hash, not to the audit copy. - Audit reports use four headings: What this version changes, Risk, Verified, Not verified. - After promotion to production the released image accepts no further verdicts. - A fix from an audit copy becomes a new version that needs its own freeze and sign-off. - Every freeze, policy change and verdict is committed to `bitswan.yaml` in the business process's git repository, attributed to the acting auditor, on a fast-forward-only history, with the report as signed. - Staging unfreezes automatically once the audited image reaches production. **How it is used** 1. As an auditor, Freeze the Staging node to lock the image under review. 2. Open Audits, then Open the code for auditing to get a copy of that exact version. 3. Read the production diff and the source, use the coding agent, and write the Audit report tab. 4. Approve or Request changes on the report, or fix the problem and deploy, which proposes a new version. 5. Once the policy is met, Promote to Production unlocks. **Why it matters:** The stored record is the auditor's reasoning rather than an approval checkbox, so in a later review or incident it shows what was checked, what was not, and on what grounds a version was released. The person who builds a change cannot release it alone. **Compliance mapping** - **ISO/IEC 27001 A.5.3** — Segregation of duties: the person who builds a change cannot unilaterally release it to production; an independent auditor must sign off. - **ISO/IEC 27001 A.8.32** — Change management: production changes are reviewed and approved against a policy before release, then promoted verbatim. - **SOC 2 CC8.1** — Change approval: changes are authorised by required sign-offs recorded in a tamper-evident log before deployment. - **DORA Art. 9** — Protection and prevention: an independent sign-off gate limits the risk a change poses to critical functions. ## Deployment history and Inspect {#bailey-deployment-history} Deployment history in Bailey is a versioned, append-only audit log of every deploy, promotion, swap, backup, restore, retention and firewall change, showing who shipped what, when and on which commit. Inspect opens any recorded deployment with its files, diff, secrets in force and built image. The history is derived from the versioned record, so it cannot be quietly edited. Its integrity rests on the canonical main branch, which is protected and accepts only fast-forward merges: every deploy advances main, with no force-push and no history-rewriting rebase, so the commit graph can only be appended to. This makes the log immutable by construction rather than by policy, including against the operator. Each history entry is a rollback point. Roll back re-deploys that exact recorded version, its image verbatim, and records a new rolled back entry at the top of the timeline. Entries whose version is already running are marked Currently deployed and offer no actions. Inspect has tabs for Diff vs current (changes versus what is live), Files (the exact source tree), Secrets snapshot (the secret set in force), Download image (the built image plus schema bundle) and, on the current deployment, Scale. Inspect also carries Edit this version, which makes the user's copy that deployed version as a restore commit on top of main, and on development, Revert dev to this version, which adds one commit to main so every copy picks up the revert on its next Sync. **Key facts** - The history records deploys, promotions, swaps, backups, restores, retention events and firewall changes. - Main is protected and fast-forward-only, so the deployment record cannot be rewritten, even by the operator. - Roll back re-deploys the recorded image verbatim and logs a new rolled back entry. - Entries already running are marked Currently deployed and have no actions. - Inspect tabs: Diff vs current, Files, Secrets snapshot, Download image, and Scale on the current deployment. - Edit this version leaves the copy one commit ahead of main and none behind, parking prior work as a dated experiment. **How it is used** 1. Open a stage, then Deployment history. 2. Read the timeline of events. 3. Press Inspect on a prior entry and step through Files, Diff vs current and Download image. 4. Press Roll back on a prior entry and confirm to re-deploy that exact version. 5. To keep working from a prior version, press Edit this version; on development, Revert dev to this version puts the shared stage back for everyone. **Why it matters:** When an auditor asks to see evidence, it is one tab away, and the branch protection, not a promise, is what makes the trail tamper-proof. Recovering from a bad change is a click and a confirmation, and the recovery is itself recorded. **Compliance mapping** - **ISO/IEC 27001 A.8.15** — Logging (integrity and tamper-protection): operational events are recorded on a fast-forward-only protected main, append-only and rewrite-proof, including against the operator. - **DORA Art. 13** — Learning and evolving: a complete record supports post-incident review. - **NIS2 Art. 21(2)(b)** — Incident handling: what happened can be reconstructed exactly from the audit trail. - **SOC 2 CC8.1** — Change management: every change is recorded with its diff and the configuration in force. ## Secrets management per stage {#bailey-secrets} Secrets in Bailey are per-stage environment secrets: the same names across stages with different values per stage, write-gated by role, injected at deploy time and snapshotted with every deployment. They are never written into the repository. Credentials such as payment-gateway keys, and configuration values such as approval thresholds, are stored as stage secrets. A key and value are added directly in the dashboard and injected on the next deploy of that stage. Every deployment captures the secret set in force at that moment, so Inspect on any historical deploy shows exactly which secrets it ran with. **Key facts** - Secret names are shared across stages; values are per stage. - Members can read secrets; admins and auditors can write them. - Secrets are injected at deploy and never committed to the repository. - Each deployment snapshots its secret set, visible in Inspect as Secrets snapshot. **How it is used** 1. Open a stage, then Secrets. 2. Add keys with their values. 3. The values are injected at the next deploy of that stage, never committed. 4. Each deploy snapshots the secret set in force. **Why it matters:** Secrets stay out of source code and out of chat threads, and every deployment's secret set can be reviewed after the fact. **Compliance mapping** - **ISO/IEC 27001 A.8.24** — Use of cryptography and secret management: secrets are stored and injected securely, separated from source. - **NIS2 Art. 21(2)(h)** — Cryptography and, where appropriate, encryption: sensitive material is handled as such by default. - **GDPR Art. 32** — Security of processing: credentials that protect personal data are kept out of source and role-gated. ## Containers: the live roster of a stage {#bailey-containers} The Containers view in Bailey lists every service of a stage's deployment as a real running container with its actual status, and offers per-container Logs, Inspect, and restart and stop controls. It is the operator's ground truth for what a stage is running. The status shown is the container's own, not an intention. A service in a crash loop reads Restarting, never running, and shows how many times Docker has restarted it, because two restarts during a deploy and twenty thousand restarts are different situations; the same count appears in Inspect for any container. A single service can be restarted or stopped without touching the rest. When an operator presses Restart, a spinner appears beside the service on this list, on the stage card and on the pipeline, and stays until Bailey has seen the container come back rather than merely until the request was accepted, so a deliberate restart is never confused with a container that keeps failing. On the Disaster Recovery stage, each container resolves to the standby slot's own instance, so the operator works on the recovered app, not the live one. **Key facts** - Each container shows its real status; a crash-looping service reads Restarting with a restart count. - The restart count is also shown in Inspect. - Logs, Inspect, restart and stop work per container. - A user-initiated restart shows a spinner until Bailey observes the container back up. - On Disaster Recovery, containers resolve to the standby slot's instances. **How it is used** 1. Open a stage, then Containers. 2. Read the status of each service. 3. Use Logs or Inspect to investigate. 4. Restart or stop a single container if needed. **Compliance mapping** - **SOC 2 CC7.2** — System monitoring: container health is visible per service, per stage. - **DORA Art. 10** — Detection: operators can observe the live state of every running service. - **ISO/IEC 27001 A.8.16** — Monitoring activities: the running estate is observable in real time. ## Backups and retention {#bailey-backups} Backups in Bailey are point-in-time snapshots of a stage's live database and object storage, governed by a retention policy and recorded in the audit trail. A snapshot captures the live blue-green database, not a stale database name. The Create snapshot dialog takes a label and a stage. Once confirmed, a task captures the live database and object storage and streams progress per store: Postgres, CouchDB and Garage. The finished snapshot is listed with its size and contents and can be restored or cloned between stages. Retention is set as a policy rather than left to an ad-hoc scheduled job. **Key facts** - Snapshots cover the live database and object storage. - Progress is streamed per store: Postgres, CouchDB, Garage. - Snapshots are labelled, sized, restorable and clonable between stages. - Retention is a configured policy. - Backup, restore and retention events appear in deployment history. **How it is used** 1. Open Production, then Backups. 2. Press Create snapshot and label it. 3. Watch it run; it is listed with size and contents. 4. Set the retention policy. **Compliance mapping** - **ISO/IEC 27001 A.8.13** — Information backup: backups are taken, retained and verifiable by restoration. - **DORA Art. 12(1)** — Backup policies and procedures: scope and frequency are defined and enforced. - **SOC 2 A1.2** — Backup: snapshots of live data are taken on demand and on policy. ## Disaster recovery: rehearse and restore {#bailey-disaster-recovery} Disaster recovery in Bailey restores a production backup into a separate DR slot, never onto live production, lets the team verify and mark it recovery-tested, and, when needed, makes that slot the live production through an ingress cutover with no data migration, no redeploy and no downtime. The restore into the DR slot streams its progress per store, and when it completes the slot is marked In DR now. The team opens it and confirms it is whole; only the backup actually loaded into DR can be marked recovery-tested. A How it works tab explains the blue-green slots and the cutover. To go live, the Restore pill asks "Make Disaster Recovery the live Production?" and repoints the production address to the verified slot. In a rehearsal, the dialog is opened and then cancelled. **Key facts** - Backups are restored into an isolated DR slot, never onto live production. - A completed restore marks the slot In DR now. - Only the backup actually loaded into DR can be marked recovery-tested, and the last pass is recorded. - The Restore pill performs an ingress cutover with no data migration, no redeploy and no downtime. - The How it works tab explains the slots and cutover in plain terms. **How it is used** 1. Take a production snapshot. 2. Go to Disaster Recovery, then Rehearse & restore. 3. Restore into DR, verify, and Mark recovery-tested. 4. Use the Restore pill to swap live when needed. **Why it matters:** A backup that has never been restored is unproven. Bailey makes restore rehearsal routine and makes the real cutover a single click. **Compliance mapping** - **DORA Art. 11–12** — Response, recovery and restoration testing: restore testing is a routine and the last pass is recorded. - **SOC 2 A1.2 / A1.3** — Backup and recovery testing: restores are rehearsed into an isolated DR slot and the test is recorded. - **ISO/IEC 27001 A.5.30 / A.8.13** — ICT readiness for continuity: backups are verified by restoration into an isolated slot. - **NIS2 Art. 21(2)(c)** — Business continuity and crisis management: a zero-downtime swap means recovery does not cost an outage. ## Egress firewall and GDPR data-processing record {#bailey-firewall-gdpr} The firewall in Bailey is a per-stage egress allow-list that ties every approved external host to a GDPR data-processing record, with an approval workflow, versioning and the Data Processing Agreement on file. Egress is default-deny in staging and production. With an egress gateway watching a stage, the firewall reads the SNI or Host of every outbound connection. In development it observes traffic and lists each unlisted destination under Needs review for an operator to approve or deny. Approving a host opens its data-processing record. The operator first states whether any user or personal data is sent; if so, the form records what data leaves, its purpose, whether it is stored at the destination (No, Transient or Yes), the processor's jurisdiction, and the signed Data Processing Agreement as a PDF. Saving the record allows the host. The GDPR Article 30 register and Article 28 DPA file are therefore built as the system is operated. **Key facts** - Outbound connections are identified by SNI or Host header. - Egress is default-deny in staging and production; development observes and surfaces unlisted hosts under Needs review. - Approval opens a data-processing record before the host is allowed. - Recorded fields: whether personal data is sent, what data, purpose, storage (No, Transient, Yes), processor jurisdiction, and the signed DPA (PDF). - A host is allowed only once its record is saved with Approve & record. - Firewall changes appear in deployment history. **How it is used** 1. Open a stage, then Firewall, and wait for it to load the live posture. 2. Find the outbound host under Needs review and press Approve. 3. Answer "No user data?", or fill in what data, purpose, stored? and jurisdiction. 4. Attach the processor's DPA (PDF) and press Approve & record. **Why it matters:** Every external recipient of data is recorded with its purpose and contract at the moment it is allowed, so the record of processing activities and the processor agreements are a by-product of running the system rather than a separately kept spreadsheet. **Compliance mapping** - **GDPR Art. 30** — Records of processing activities: each external recipient is logged with its purpose and whether personal data is transferred. - **GDPR Art. 28** — Processor obligations: a Data Processing Agreement is stored for every host that processes personal data before egress is allowed. - **NIS2 Art. 21(2)(a)** — Risk-analysis and network security policies: default-deny egress with reviewed, documented exceptions. - **ISO/IEC 27001 A.8.20–8.21** — Network and network-service security: outbound connections are controlled per service. ## Supply chain security and SBOM {#bailey-supply-chain} Supply chain security in Bailey gives every deployed image a software bill of materials (SBOM) and a CVE scan, ranks vulnerabilities by severity, links each one to its advisories, and records accepted risks in source. The scan runs on the image that actually ships. The Supply chain view shows each vulnerability with the affected package. Opening a CVE links to osv.dev, NVD and GitHub advisories. Out-of-scope decisions are explicit, attributed and stored in the business process's source tree, and the production Supply chain tab lists them read-only so auditors can see what was excluded, by whom and why. **Key facts** - Every deployed image carries an SBOM. - Vulnerabilities are ranked by severity and show the affected package. - Each CVE links to osv.dev, NVD and GitHub advisories. - Out-of-scope decisions are stored in source, attributed, and visible read-only on production. - The scan runs on the image that ships, not on an older build. **How it is used** 1. Open a stage, then Supply chain. 2. Sort by severity and open a CVE for its advisory. 3. Record any out-of-scope decision in-tree. **Compliance mapping** - **NIS2 Art. 21(2)(d)** — Supply-chain security: the contents of what runs can be produced on demand. - **SOC 2 CC7.1** — Vulnerability detection: the SBOM and CVE scan run on the image that actually ships. - **ISO/IEC 27001 A.5.7 / A.8.8** — Threat intelligence and vulnerability management: continuous visibility of known vulnerabilities in dependencies. ## People, roles and segregation of duties {#bailey-people-and-roles} People & roles in Bailey is the console page that holds the server's roster of people, each with an explicit role (admin, auditor or member) and a list of per-person trusted devices that can be approved or revoked. Bailey resolves roles from its own user-role store and enforces them server-side, not merely by hiding controls in the user interface. The three roles divide authority deliberately. An admin (the operator) holds every right. A member does the day-to-day build and ship work but cannot change governance settings. The auditor role is not simply read-only: an auditor can review everything and also holds the governance controls a compliance owner needs, namely setting the recovery-test cadence and approving a production egress host's GDPR data-processing record. An auditor cannot operate the pipeline: no deploying or promoting code, no managing people, roles or devices, and no access to the server's admin settings. This split is the segregation of duties an auditor signs off on. The person who sets the recovery cadence and vets a new data recipient is deliberately not the person who ships the code. People & roles is also where pending devices are approved and lost devices are revoked. **Key facts** - Bailey has three roles: admin (operator), auditor and member. - Roles are resolved from Bailey's own user-role store and enforced server-side, not only hidden in the UI. - An admin holds every right on the server. - A member does the day-to-day build and ship work but cannot change governance settings. - An auditor can review everything, set the recovery-test cadence and approve a production egress host's GDPR data-processing record. - An auditor cannot deploy or promote code, manage people, roles or devices, or change the server's admin settings. - Per-person trusted devices are approved (by their code) and revoked from the same People & roles page. - The separation means governance authority and the authority to ship code sit with different people. **How it is used** 1. Open People & roles in the console. 2. Review roles across the team. 3. Approve a pending device by its code. 4. Revoke a device or change a role as people join and leave. **Why it matters:** An auditor in Bailey has oversight with real authority over compliance settings, but that authority is deliberately separated from the authority to ship code. Each role gets only the rights its duties require, which is what access-control and segregation-of-duties controls ask for. **Compliance mapping** - **ISO/IEC 27001 A.5.18 / A.5.3** — Access rights & segregation of duties: admin, auditor and member are distinct, server-enforced roles, and the auditor's governance authority is separated from the member's build/ship authority. - **SOC 2 CC6.2 / CC6.3** — Access provisioning & de-provisioning: roles and per-person trusted devices are granted and revoked centrally. - **NIS2 Art. 21(2)(i)** — Human-resources security & access control: access is role-based and reviewable. - **DORA Art. 9(4)** — Access management on a need-to-know basis: auditors hold governance (recovery cadence, processing-record approval) but not deploy/promote, and members ship but cannot change governance settings. ## Single sign-on with your own identity provider {#bailey-single-sign-on} Single sign-on in Bailey lets an admin add the organisation's own OpenID Connect (OIDC) identity provider to a Bailey server, alongside Bitswan accounts. The company directory stays the source of truth for who works at the organisation; Bailey stays the source of truth for what each person can do. By default people sign in to Bailey with a Bitswan account issued through the Automation Operations Centre (AOC). An established organisation usually already has an identity provider, already offboards through it, and does not want a second place where staff accounts are created. With single sign-on configured, people sign in with the account they already have. Because the directory already contains everyone who should have access, email invitations are not needed, and disabling someone centrally in the directory also closes their way into Bailey. By default both ways in stay open: the sign-in page offers a choice, so Bitswan accounts (the operator's and any managed by the AOC) keep working on the same server. This is a deliberate safeguard: a provider whose certificate has expired must not be able to lock every administrator out of the machine that could fix it. An organisation can turn Bitswan accounts off so that its provider is the only way in; there is then one connector, nobody is asked to choose, and sign-in goes straight to the provider. If that provider then has an outage, a lapsed certificate or a rotated client secret, everyone is locked out of the console, including whoever would fix it. Recovery does not run through a browser: an operator with a shell on the server runs `bitswan bailey sso disable`, which restores Bitswan sign-in and rebuilds the proxy. Automations keep working across the change. An app deployed on Bailey verifies the identity on each request against whatever actually signed it, so once the organisation's provider is in front, that is what it checks, and the group memberships the directory publishes arrive with it for the apps to match their own access rules on. Single sign-on deliberately does not change two things: every new device is still approved exactly as before, and people arrive as members with no elevated rights unless an admin gives them a role in People & roles or provider groups are mapped onto Bailey roles. **Key facts** - Bailey supports any OpenID Connect provider as a sign-in method, configured from Single sign-on in the console's Admin section. - Configuration needs a display name (the label on the sign-in button), an issuer URL, and a client ID and secret. - Bailey reads the provider's discovery document on Test and refuses a provider it cannot reach. - Bitswan account sign-in stays on by default, so administrators can still get in if the provider fails. - Turning Bitswan accounts off makes the organisation's provider the only way in, with no choice screen. - `bitswan bailey sso disable`, run from a shell on the server, restores Bitswan sign-in and rebuilds the proxy. - Email invitations are unnecessary with SSO; offboarding in the directory removes access to Bailey as well. - Provider groups can be mapped onto Bailey roles; with no mapping, everyone arrives as a member. - Device approval still applies to every new device after SSO is enabled. - Deployed apps verify each request against the actual signer and receive the directory's group memberships. **How it is used** 1. Open Single sign-on in the console's Admin section. 2. Give the provider a display name; it labels the button people click. 3. Enter the issuer URL and press Test; Bailey reads the discovery document and refuses a provider it cannot reach. 4. Register the redirect URI shown on the page with the provider, then paste back the client ID and secret. 5. Optionally map provider groups onto Bailey roles; leave it empty and everyone arrives as a member. 6. Leave Bitswan accounts on unless the warning beside the option has been read and accepted. 7. Press Enable single sign-on; everyone signed in, including the admin, signs in again on the next page they open. **Why it matters:** An organisation keeps one joiner/leaver process instead of a parallel account store, and its own authentication policy, including its MFA requirements, applies at sign-in. Device trust remains a second, independent control, and the default of keeping Bitswan sign-in available means an identity-provider failure does not lock administrators out. **Compliance mapping** - **ISO/IEC 27001 A.5.16** — Identity management: identities are managed in the organisation's own directory, with a single joiner/leaver process rather than a parallel account store. - **SOC 2 CC6.1 / CC6.2** — Logical access & provisioning: access derives from the corporate identity provider, and de-provisioning there withdraws access in Bailey. - **NIS2 Art. 21(2)(i)** — Access control policy: authentication is federated to the organisation's controlled identity source, with device approval retained as a second, independent control. - **DORA Art. 9(4)** — Strong authentication: the organisation's own authentication policy, including its MFA requirements, applies at sign-in, while device trust remains enforced independently by the platform. ## Sharing an endpoint with people and groups {#bailey-sharing-an-endpoint} Endpoint sharing in Bailey is the owner-driven way to grant access to any protected app behind the Bailey gate, including the frontends that operators build and deploy. Access is deny-by-default: only people the owner invites can open an endpoint, and each grant names a person or group and a level (User or Owner) without affecting anyone else's access. A deployed automation's frontend is itself a Bailey-protected endpoint. When it is opened, Bailey's own chrome wraps it, with a Share button for its owner. The owner grants access to a person (by email) or to a whole identity-provider group, choosing User (open and use it) or Owner (also manage who else can). Each grant is recorded with who granted it and when. A user who is refused can request access, and the request surfaces to the owner to approve or deny. The same mechanism fronts everything: a workspace dashboard, gitops, and every automation frontend an operator creates. Adding a member to a workspace is a grant on the workspace's endpoint; letting a teammate into a deployed app is a grant on that app's endpoint. Because every grant is per-endpoint and owner-managed, there is no god-mode admin quietly reading everything, and revoking takes effect as immediately as granting. **Key facts** - Every Bailey-protected endpoint is deny-by-default. - Workspace dashboards, gitops and every deployed automation frontend use the same sharing mechanism. - Grants are made by the endpoint's owner via a Share button in Bailey's chrome around the app. - A grant can target a person by email or an identity-provider group (written as /group). - Two access levels exist: User (open and use) and Owner (also manage who else has access). - Each grant records who granted it and when. - Refused users can request access; the owner approves or denies the request. - Access is effective immediately on Add and revoked immediately on Remove. - There is no god-mode admin with implicit access to every endpoint. **How it is used** 1. Open a deployed automation's frontend (a Bailey-protected endpoint) and click Share in its chrome. 2. Type a person's email or a /group and pick User or Owner. 3. Press Add; access is effective immediately and recorded. 4. Approve or deny any pending access requests, and use Remove to revoke. **Why it matters:** Sharing in Bailey is per-endpoint, owner-driven and recorded. Access control is not a central list someone forgets to prune; the owner of each app decides, in the open, exactly who can reach it, and revokes access the instant it should end. **Compliance mapping** - **ISO/IEC 27001 A.5.15 / A.8.3** — Access control & information access restriction: access to each endpoint is granted explicitly, per principal, by its owner. - **SOC 2 CC6.1 / CC6.3** — Logical access & role-based access: endpoints are deny-by-default, and grants carry a role and an attributable grantor. - **NIS2 Art. 21(2)(i)** — Access control: who can reach which service is explicit, owner-managed and revocable. - **GDPR Art. 5(1)(f) / Art. 32** — Integrity & confidentiality: personal data behind an endpoint is reachable only by explicitly granted principals. ## SIEM export of the security audit log {#bailey-siem-export} SIEM export in Bailey streams the server's security audit log to an external SIEM over OpenTelemetry (OTLP) in real time. It covers events such as device-trust changes, role changes, workspace creation and access approvals, and is configured from the SIEM forwarding card on the Server overview page. Bailey keeps its own security audit trail regardless of whether export is configured; the export mirrors every security event to an external OpenTelemetry ingestor so a security operations centre can correlate, alert on and retain it alongside everything else. The Ingestor URL is the collector's OTLP base URL, only the host and port (for example `https://collector.example.com`); Bailey appends the `/v1/logs` path itself. The Protocol is either OTLP/HTTP (protobuf over HTTPS, the simplest to route through a proxy) or OTLP/gRPC (a streaming gRPC channel, lower overhead at volume), matched to what the collector listens on. An optional bearer Auth token authenticates the stream. Pressing Save & connect runs a live connectivity test and shows Connected or the exact error before the feed is relied on. The card then shows when the last event was delivered. **Key facts** - Bailey forwards security audit events to a SIEM over OpenTelemetry, as they happen. - Exported events include device-trust changes, role changes, workspace creation and access approvals. - Configuration lives on the SIEM forwarding card on Server overview. - The Ingestor URL is the host and port only; Bailey appends `/v1/logs`. - Supported protocols are OTLP/HTTP (protobuf over HTTPS) and OTLP/gRPC. - An optional bearer Auth token authenticates the stream. - Save & connect performs a live connectivity test and reports Connected or the exact error. - The card shows live status and the time the last event was delivered; export can be edited or disabled. - Audit events are produced whether or not export is enabled. **How it is used** 1. Open Server overview and find SIEM forwarding. 2. Click Configure ingestor, enter the Ingestor URL, pick the Protocol and add an Auth token if needed. 3. Press Save & connect; it tests the connection and shows Connected or the error. 4. Watch the live status and last-delivered time, and use Edit or Disable as needed. **Why it matters:** The audit events exist no matter what; SIEM export forwards them live into the organisation's existing detection and retention pipeline, so monitoring and alerting happen in the tool the security team already runs rather than in a console someone has to remember to open. **Compliance mapping** - **ISO/IEC 27001 A.8.15 / A.8.16** — Logging & monitoring: security events are exportable, in real time, to centralized monitoring and retention. - **SOC 2 CC7.2** — System monitoring: audit events feed an external SIEM for correlation and alerting. - **DORA Art. 10** — Detection of anomalous activities: real-time event export enables continuous detection in the SOC. - **NIS2 Art. 21(2)(b)** — Incident handling: centralized, exported events shorten detection and support reconstruction. ## Onboarding a new teammate (deny by default) {#bailey-onboarding-deny-by-default} Onboarding in Bailey is a three-step, deny-by-default process: a new teammate signs in, their unknown device is stopped at the gate, and an admin admits that device by typing a six-digit code the teammate reads out to them. A valid login alone grants nothing; access is bound to a specific, approved device. When a new teammate signs in at the Bailey host on their own laptop, for example through the organisation's identity provider, the login succeeds but they see none of the product. The gate shows "Trust this device" with the message "You're signed in, but this device isn't trusted yet." The browser displays a large six-digit code labelled "Your code", the instruction "Read this code to an admin", and a "Waiting for an admin…" spinner. No workspace, app or console is reachable until someone who already holds trust approves the device. Because access is bound to hardware and not only to the credential, a leaked or phished password, or a whole compromised identity-provider account used from an attacker's machine, never clears the gate. The admin opens People & roles in the Server Console, where the request appears inline under the person's name as a "Device awaiting approval" bar, badged First device and showing how long it has been waiting. The server never sends the code to the admin. The admin must hear it from the person in real time (in person or on a call), which proves the person is physically present at that device. The admin types the six digits and presses Trust this device; in one action this enrols the user as a device owner and makes the laptop a trusted device, badged and revocable like any other. There is no automatic admission and no "deny" decision to forget: unapproved devices simply expire. The moment the device is trusted, the waiting browser leaves the "Waiting for an admin…" state and redirects straight to what the person was trying to reach, with no re-login and no second step. From then on the device carries its own trust cookie, so the person comes and goes without re-approval. The device appears in the roster like any other trusted device, and the same People & roles and Your devices surfaces that admitted it are where it is removed. If the laptop is lost or stolen, or the person leaves, an admin revokes the device (or the person) and its access to the console and every workspace app ends instantly, with no need to rotate passwords across many apps. **Key facts** - A successful sign-in to Bailey does not grant access; an untrusted device is held at the gate. - The waiting device shows a six-digit code, the prompt "Read this code to an admin" and "Waiting for an admin…". - The server never shows the code to the approving admin; the admin must hear it from the person, as a presence check. - Pending requests appear in People & roles as a "Device awaiting approval" bar, badged First device, with the waiting time. - One action, Trust this device, both enrols the user and trusts the device. - There is no auto-admit; unapproved devices expire rather than needing an explicit deny. - Once trusted, the device is let through immediately, with no re-login, and carries its own trust cookie. - Trust is per device; each person works from their own trusted hardware. - Revoking a device or person in People & roles ends access to the console and every workspace app instantly. - A stolen identity-provider account on an attacker's machine cannot be approved, because the attacker cannot present the code in person. **How it is used** 1. The new teammate signs in at the Bailey host on their own device. 2. The gate shows Trust this device: they are signed in but not trusted, and the device displays a six-digit code and waits. 3. An admin opens People & roles and finds the teammate's Device awaiting approval bar. 4. The admin asks the teammate to read the six-digit code from their screen and types it in. 5. The admin presses Trust this device; the person is enrolled and the device trusted. 6. The waiting device is admitted at once and redirects straight to what the person was granted, with no re-login. 7. The device now appears in the roster, badged and revocable. 8. For a lost device or a leaver, remove the device (or person) in People & roles; access is revoked everywhere, instantly. **Why it matters:** A valid login is not access. By binding trust to the device and requiring a present, trusted admin to admit it, Bailey turns "approve a request" into "confirm a present, identified human on a specific device", so a remote attacker holding only stolen credentials cannot be approved. Onboarding and offboarding are the same lever pulled in opposite directions: a stolen laptop or a departing employee is one click to remove the device, not a password-reset fire drill. **Compliance mapping** - **NIS2 Art. 21(2)(j)** — Multi-factor authentication & secured access: device trust is a hardware-bound second factor, admitted only by an already-trusted admin with out-of-band code confirmation, and revocable per device and per person. - **ISO/IEC 27001 A.5.15 / A.8.5** — Access control & secure authentication: access is deny-by-default and granted per device, not per credential. - **ISO/IEC 27001 A.5.16 / A.5.18** — Identity & access-rights management: enrolment of a user and device is an explicit, authorized, recorded act. - **ISO/IEC 27001 A.5.15 / A.8.1** — Access control & user-endpoint devices: per-device trust is granted, badged and revoked from one place. - **SOC 2 CC6.1** — Logical access security: a new principal is denied at the gate until explicitly authorized. - **SOC 2 CC6.2 / CC6.3** — Access provisioning & de-provisioning: a new principal and device are granted access centrally by an authorized admin with a presence check, and a device is just as immediately revocable when lost or on a leaver. - **DORA Art. 9(3)** — Strong authentication mechanisms: robust access control gates every new device before it reaches a system. - **DORA Art. 9(4)** — Access on a need-to-know basis: access is conferred deliberately by an admin, not assumed from a login. - **DORA Art. 9** — Protection & prevention: immediate device revocation contains a lost device or a departing insider. ## Memory governance and the on-demand pool {#bailey-memory-governance} Memory governance in Bailey reserves host memory for services that must stay up and lets every other service scale to zero, either automatically under memory pressure or on demand with a Sleep button, and wake on first access. Users can run as many previews and business processes as they like without starving critical workloads, whether the sleeping service is a dev preview or a production service. Every automation declares two settings in `automation.toml`: `memory-reservation` (its memory budget in MB) and `memory_reservation_policy`, which is either `always-on`, for a backend that must never stop because it runs background work, or `on-demand` (the default), for anything that can be paused when idle and woken on access. The Bailey daemon reads these values from the running containers and keeps a single budget: host memory, minus a system reserve, minus a per-workspace infrastructure reserve, minus every always-on reservation, minus a sized on-demand pool. The on-demand pool is sized to run the largest few on-demand services at once and grows only when someone deploys a genuinely large one, so small idle processes never consume reserved memory and an unlimited number of rarely used business processes costs nothing. When the running on-demand set exceeds the pool, Bailey shuts down the least-recently-used services; the next time someone opens one, a loading screen appears and it is back in seconds. Promotions and new workspaces that would not fit the reserved budget are refused up front, with a message stating exactly how much memory is short. Any container that outgrows its reservation raises a SIEM event and is flagged in red on its Containers tab. The Server Console's Resource management page lists every business process grouped by process and stage, with live totals including processes already asleep, and offers a Sleep button per process plus Sleep all on-demand for the whole page. Sleeping is a true scale-to-zero: the workers and the shared egress gateway are torn down, so a paused process costs nothing. Always-on services ignore the button. Waking is universal: on-demand dev, staging and production services all come back on first access behind a brief loading page, rehydrated from the deployed source of truth, with no eviction bookkeeping to lose. **Key facts** - Each automation declares `memory-reservation` (MB) and `memory_reservation_policy` in `automation.toml`. - The two policies are `always-on` (never stopped) and `on-demand` (the default; paused when idle, woken on access). - Bailey's budget is host memory minus a system reserve, a per-workspace infrastructure reserve, all always-on reservations and the on-demand pool. - The on-demand pool is sized for the largest few on-demand services and grows only when a genuinely large one is deployed. - Under pressure, Bailey shuts down the least-recently-used on-demand services. - Promotions and new workspaces that do not fit the reserved budget are refused, with the exact shortfall stated. - A container exceeding its reservation raises a SIEM event and is flagged red on its Containers tab. - Resource management offers Sleep per process and Sleep all on-demand; always-on services ignore it. - Sleep tears down the workers and the shared egress gateway, so a sleeping process costs nothing. - Sleeping dev, staging and production services wake on first access behind a brief loading page. **How it is used** 1. Declare `memory-reservation` (and, for a background worker, `memory_reservation_policy = "always-on"`) in `automation.toml`. 2. Open Resource management in the Server Console to see the host budget, the reserved breakdown and per-process usage grouped by process and stage. 3. Promote or create a workspace; Bailey admits it only if it fits the reserved budget, otherwise it reports the shortfall. 4. Press Sleep on a process (or Sleep all on-demand) to scale it to zero immediately; idle processes left alone are shut down under pressure anyway. 5. Reopen an asleep process (dev, staging or production) and it wakes automatically behind a brief loading page. 6. Watch for the red over-reservation flag on the Containers tab; it also appears in the SIEM feed. **Why it matters:** Always-on backends are guaranteed their memory, while everything else lives in a bounded pool that scales to zero, on demand or under pressure, and wakes on first access. A busy workspace full of experiments can never starve production. **Compliance mapping** - **ISO/IEC 27001 A.8.6** — Capacity management: memory is reserved, budgeted and admission-controlled from live host state, and over-use is detected and alerted. - **SOC 2 A1.1** — Availability: critical (always-on) workloads keep their reserved capacity, and non-critical ones are shed under pressure without losing their state. - **NIS2 Art. 21(2)(c)** — Business continuity & capacity: resource pressure is managed automatically so essential services stay available. - **DORA Art. 9** — Performance & capacity: ICT resource limits are governed and monitored, with alerts when a workload exceeds its budget. ## Keeping Bailey up to date (updates and rollback) {#bailey-keeping-bailey-up-to-date} Updates in Bailey are one-click, recorded and reversible: every component reports when it is behind, a workspace or the automation server itself moves to the latest version with one button, every update is logged with who moved what to which version and when, and any of the last three recorded versions can be restored with one click. Bailey compares the image tags each workspace is actually running against the latest on its release track, and compares the running server binary against the latest published release. A workspace owner sees an Update available badge on their workspace card in the Bailey admin; an admin sees an Updates item in the navigation with a small bubble whenever any component is out of date. Nothing is inferred from names or guessed: an update is flagged only when Bailey can read the deployed tag and resolve the latest one, so the badge always names the exact versions being compared. The Updates view shows the automation server's current version alongside the latest release and lists every workspace with an available update, each with its own Update button. Updating a workspace regenerates its deployment on the latest tags and redeploys it. Updating the server makes the daemon download the official binary from the Automation Operations Centre (AOC) the server is registered with (the same source the one-line installer uses), swap it in atomically on the host and restart onto the new version; the console reconnects on its own. No shell or host command is involved. Every server or workspace update is recorded in a version ledger with who applied it, when, and the exact from and to versions. The ledger is shown as Update history on the same page and streamed to the SIEM. Each update keeps the state it replaced as a restorable point, so Roll back returns the server or a workspace to any of the last three recorded versions (the previous server binary, or a workspace's previous deployment, verbatim). A rollback is itself recorded as a new "rolled back" entry. The window is deliberately bounded to three so the restorable history cannot grow without limit. **Key facts** - Bailey compares running workspace image tags with the latest on their release track, and the server binary with the latest published release. - Owners see an Update available badge on the workspace card; admins see a bubble on the Updates nav item. - An update is flagged only when both the deployed and latest versions can be resolved, and the badge names both. - Workspace update regenerates the deployment on the latest tags and redeploys. - Server update downloads the official binary from the AOC the server is registered with, swaps it atomically and restarts. - Updates require no shell or CLI access. - Every update is recorded with who, when and the exact from → to version, shown as Update history and streamed to the SIEM. - Roll back restores any of the last three recorded versions in one click, and the rollback is itself recorded. **How it is used** 1. Watch for the Updates nav bubble (admins) or an Update available badge on the workspace card (owners). 2. Open Updates to see the server's current and latest version and the workspaces that are behind. 3. Press a workspace's Update button to move it to the latest track and redeploy, or the server's Update button to update the automation server itself. 4. Read Update history to see who updated what, to which version and when; the SIEM receives the same record. 5. If an update misbehaves, press Roll back on any of the last three recorded versions; the rollback is recorded too. **Why it matters:** Every update in Bailey keeps the state it replaced as a restorable point, so the version a server or workspace was on is never more than a click away, and recovering from a bad change is auditable rather than a scramble. **Compliance mapping** - **ISO/IEC 27001 A.8.8** — Management of technical vulnerabilities: out-of-date components are surfaced and patched to a known-good latest, with a controlled way back. - **SOC 2 CC8.1** — Change management: version changes are visible, applied deliberately, and reversible. - **NIS2 Art. 21(2)(e)** — Vulnerability handling & patching: components report when they are behind and are updated from an authoritative source. ## Source mirroring and exit (no lock-in) {#bailey-source-mirror-exit} The Git remote mirror in Bailey pushes everything a workspace holds (each business process's code, specification, CVE waivers and deployment manifests) to a git repository the customer controls, so the source is never locked in. It is two-way and continuously updated, which makes it a standing, self-service exit rather than a backup or an export on request. Bailey runs business processes on the customer's server, including frontends, backends, databases and certificates. To make that a convenience rather than a dependency, an admin opens Advanced → Settings (admins only) and uses the Git remote card. Each workspace generates its own SSH deploy key, shown in full with a Copy public key button, to be added as a read-write deploy key on GitHub, GitLab or Forgejo. The admin pastes back the SSH remote (`git@host:org/repo.git`); HTTPS is refused because the key is what authenticates. The key can be rotated from the same card (Retire key and generate a new one), and the card records who rotated it and when. The mirror is one repository in a layout readable without Bailey documentation. The `main` branch holds one folder per business process, each containing that process's code exactly as its own main has it, plus a generated `README.md` explaining the layout. The `gitops` branch holds the deployment manifests, recording which version each stage runs. `copies/` branches mirror every personal copy and experiment; they are read-only, overwritten on each push and removed when the copy is deleted. Deployment history is carried as `deploy//` tags. The mirror is two-way. Before the Deploy tab reports status, Bailey fetches the remote's main and merges new commits into the process's own main, then says so: "New changes from the git remote were pulled into main. Sync your copy before deploying." A colleague with no Bailey access can push a fix to the remote and it becomes part of the next deploy. Bailey never force-pushes main on its own. If the remote's main is no longer a fast-forward of what Bailey pushed, or an inbound change conflicts with work in the workspace, mirroring of main stops and both the Git remote card and the Deploy tab name the affected processes. An admin then chooses Force push to repair (the remote is made to match the workspace, with a statement of what is discarded) or Pause the remote (nothing is pushed or pulled until resumed). Members see the same banner with an instruction to ask an admin. Processes keep running on the customer's own server either way. **Key facts** - Mirroring is configured by admins only, on the Git remote card under Advanced → Settings. - Each workspace generates its own SSH deploy key, which must be added as a read-write deploy key on GitHub, GitLab or Forgejo. - Only SSH remotes (`git@host:org/repo.git`) are accepted; HTTPS is refused. - The deploy key can be rotated from the card, which records who rotated it and when. - `main` holds one folder per business process plus a generated `README.md`; `gitops` holds deployment manifests. - `copies/` branches mirror personal copies read-only and disappear with the copy; deployments are tagged `deploy//`. - Commits pushed to the remote's main are merged into Bailey before the next deploy. - Bailey never force-pushes main on its own; on divergence or conflict, mirroring of main stops and the affected processes are named. - Recovery from divergence is an admin choice: Force push to repair or Pause the remote. - Push status lists each branch and what reached the remote. **How it is used** 1. Open Advanced → Settings (admins only) and find the Git remote card. 2. Press Copy public key and add it as a read-write deploy key on a GitHub, GitLab or Forgejo repository the organisation owns. 3. Paste the SSH remote (`git@host:org/repo.git`) and save it; HTTPS is not accepted. 4. Press Push now; Push status then lists each branch and what reached the remote. 5. Clone the repository at any time: `main` for the code, `gitops` for the manifests, `copies/*` for work in progress. 6. Push a commit to it from outside and it is pulled into main before the next Deploy; sync the copy and ship it. 7. If main ever diverges, choose deliberately: Force push to repair, or Pause the remote until a decision is made. **Why it matters:** An exit that needs a support ticket is not an exit. The Bailey mirror keeps the code, specifications, CVE waivers and deployment record in a repository the customer already controls, in a layout a stranger can read, updated on every deploy, so leaving is a decision the customer can make without the provider's cooperation. Customers never have to leave, which is not the same as being unable to. **Compliance mapping** - **DORA Art. 28(8)** — Exit strategies for ICT third-party arrangements: the workspace mirrors itself (code, deployment manifests and history) to a git remote the financial entity controls, so an exit needs no cooperation from the provider. - **ISO/IEC 27001 A.5.23** — Information security for use of cloud services: what the service holds is continuously available in a customer-owned repository, in a documented layout, covering the acquisition-to-exit lifecycle. - **ISO/IEC 27001 A.5.30** — ICT readiness for business continuity: a current, independent copy of every business process (code, spec and manifests) keeps running when the platform that produced it does not. ## Compliance control mapping {#compliance-matrix} This table lists every regulatory and framework control that the Bailey platform documentation maps to a platform capability: 98 mappings across NIS2, DORA, ISO/IEC 27001, SOC 2 and GDPR. Each row links to the section that explains the capability. The mappings show how platform features support a control; they are not a certification. | Framework | Control | Requirement | How Bailey addresses it | Section | |---|---|---|---|---| | NIS2 | Art. 21(2)(a) | Risk-analysis and network security policies | default-deny egress with reviewed, documented exceptions | [Egress firewall and GDPR data-processing record](#bailey-firewall-gdpr) | | NIS2 | Art. 21(2)(b) | Incident handling | what happened can be reconstructed exactly from the audit trail | [Deployment history and Inspect](#bailey-deployment-history) | | NIS2 | Art. 21(2)(b) | Incident handling | centralized, exported events shorten detection and support reconstruction | [SIEM export of the security audit log](#bailey-siem-export) | | NIS2 | Art. 21(2)(c) | Business continuity and crisis management | a zero-downtime swap means recovery does not cost an outage | [Disaster recovery: rehearse and restore](#bailey-disaster-recovery) | | NIS2 | Art. 21(2)(c) | Business continuity & capacity | resource pressure is managed automatically so essential services stay available | [Memory governance and the on-demand pool](#bailey-memory-governance) | | NIS2 | Art. 21(2)(d) | Supply-chain security | the contents of what runs can be produced on demand | [Supply chain security and SBOM](#bailey-supply-chain) | | NIS2 | Art. 21(2)(e) | Security in development | agent output is CVE-scanned and reviewed before deploy | [Coding agent and requirements](#bailey-coding-agent-requirements) | | NIS2 | Art. 21(2)(e) | Security in development | experimentation happens in a disposable branch of the developer's own copy, so unreviewed work can never become the shared baseline | [Personal copies and experiments](#bailey-copies-and-experiments) | | NIS2 | Art. 21(2)(e) | Security in acquisition, development and maintenance, including vulnerability handling | waivers are versioned in-tree and reviewable | [Deploy and Sync: shipping a change to main](#bailey-deploy-and-sync) | | NIS2 | Art. 21(2)(e) | Vulnerability handling & patching | components report when they are behind and are updated from an authoritative source | [Keeping Bailey up to date (updates and rollback)](#bailey-keeping-bailey-up-to-date) | | NIS2 | Art. 21(2)(h) | Cryptography and, where appropriate, encryption | sensitive material is handled as such by default | [Secrets management per stage](#bailey-secrets) | | NIS2 | Art. 21(2)(i) | Human-resources security & access control | access is role-based and reviewable | [People, roles and segregation of duties](#bailey-people-and-roles) | | NIS2 | Art. 21(2)(i) | Asset management | the estate of exposed services is inventoried with ownership | [Server overview and endpoint inventory](#bailey-server-overview-endpoints) | | NIS2 | Art. 21(2)(i) | Access control | who can reach which service is explicit, owner-managed and revocable | [Sharing an endpoint with people and groups](#bailey-sharing-an-endpoint) | | NIS2 | Art. 21(2)(i) | Access control policy | authentication is federated to the organisation's controlled identity source, with device approval retained as a second, independent control | [Single sign-on with your own identity provider](#bailey-single-sign-on) | | NIS2 | Art. 21(2)(i) | Asset management and access control | every workspace and its endpoints are inventoried and owned | [Workspaces](#bailey-workspaces) | | NIS2 | Art. 21(2)(j) | Multi-factor authentication and secured access | device trust is a strong second factor bound to hardware, matching the "MFA or continuous authentication" the directive expects | [Server claim and device trust](#bailey-device-trust) | | NIS2 | Art. 21(2)(j) | Multi-factor authentication & secured access | device trust is a hardware-bound second factor, admitted only by an already-trusted admin with out-of-band code confirmation, and revocable per device and per person | [Onboarding a new teammate (deny by default)](#bailey-onboarding-deny-by-default) | | NIS2 | Art. 21(2)(j) | Secured access | hardware-bound trust is enrolled and managed per person | [Device management and lost-device response](#bailey-your-devices) | | DORA | Art. 8–9 | ICT risk identification and protection | pre-deploy scanning makes risk identification automatic and auditable | [Deploy and Sync: shipping a change to main](#bailey-deploy-and-sync) | | DORA | Art. 9 | Protection and prevention | an independent sign-off gate limits the risk a change poses to critical functions | [Freeze and audit: four-eyes approval for production](#bailey-freeze-and-audit) | | DORA | Art. 9 | Performance & capacity | ICT resource limits are governed and monitored, with alerts when a workload exceeds its budget | [Memory governance and the on-demand pool](#bailey-memory-governance) | | DORA | Art. 9 | Protection & prevention | immediate device revocation contains a lost device or a departing insider | [Onboarding a new teammate (deny by default)](#bailey-onboarding-deny-by-default) | | DORA | Art. 9 | Protection and prevention | zero-downtime cutovers minimise the impact of changes on the availability of critical functions | [Staged deployment and blue-green promotion](#bailey-staged-deployment) | | DORA | Art. 9(3) | Strong authentication mechanisms | protection of ICT systems requires robust access control, and the gate provides it uniformly | [Server claim and device trust](#bailey-device-trust) | | DORA | Art. 9(3) | Strong authentication mechanisms | robust access control gates every new device before it reaches a system | [Onboarding a new teammate (deny by default)](#bailey-onboarding-deny-by-default) | | DORA | Art. 9(4) | Access on a need-to-know basis | access is conferred deliberately by an admin, not assumed from a login | [Onboarding a new teammate (deny by default)](#bailey-onboarding-deny-by-default) | | DORA | Art. 9(4) | Access management on a need-to-know basis | auditors hold governance (recovery cadence, processing-record approval) but not deploy/promote, and members ship but cannot change governance settings | [People, roles and segregation of duties](#bailey-people-and-roles) | | DORA | Art. 9(4) | Strong authentication | the organisation's own authentication policy, including its MFA requirements, applies at sign-in, while device trust remains enforced independently by the platform | [Single sign-on with your own identity provider](#bailey-single-sign-on) | | DORA | Art. 10 | Detection | operators can observe the live state of every running service | [Containers: the live roster of a stage](#bailey-containers) | | DORA | Art. 10 | Detection of anomalous activities | real-time event export enables continuous detection in the SOC | [SIEM export of the security audit log](#bailey-siem-export) | | DORA | Art. 11–12 | Response, recovery and restoration testing | restore testing is a routine and the last pass is recorded | [Disaster recovery: rehearse and restore](#bailey-disaster-recovery) | | DORA | Art. 12(1) | Backup policies and procedures | scope and frequency are defined and enforced | [Backups and retention](#bailey-backups) | | DORA | Art. 13 | Learning and evolving | a complete record supports post-incident review | [Deployment history and Inspect](#bailey-deployment-history) | | DORA | Art. 24–26 | Resilience testing | requirements are runnable specifications, re-run on demand | [Coding agent and requirements](#bailey-coding-agent-requirements) | | DORA | Art. 28(8) | Exit strategies for ICT third-party arrangements | the workspace mirrors itself (code, deployment manifests and history) to a git remote the financial entity controls, so an exit needs no cooperation from the provider | [Source mirroring and exit (no lock-in)](#bailey-source-mirror-exit) | | ISO/IEC 27001 | A.5.3 | Segregation of duties | the person who builds a change cannot unilaterally release it to production; an independent auditor must sign off | [Freeze and audit: four-eyes approval for production](#bailey-freeze-and-audit) | | ISO/IEC 27001 | A.5.7 / A.8.8 | Threat intelligence and vulnerability management | continuous visibility of known vulnerabilities in dependencies | [Supply chain security and SBOM](#bailey-supply-chain) | | ISO/IEC 27001 | A.5.9 | Inventory of assets | each business process is a named, owned unit of the estate | [Business processes](#bailey-business-processes) | | ISO/IEC 27001 | A.5.9 | Inventory of information and other associated assets | every workspace and protected endpoint is enumerated from real, live state | [Server overview and endpoint inventory](#bailey-server-overview-endpoints) | | ISO/IEC 27001 | A.5.15 / A.8.1 | Access control & user-endpoint devices | per-device trust is granted, badged and revoked from one place | [Onboarding a new teammate (deny by default)](#bailey-onboarding-deny-by-default) | | ISO/IEC 27001 | A.5.15 / A.8.1 | Access control and user-endpoint devices | trusted devices are enrolled, labelled and revocable | [Device management and lost-device response](#bailey-your-devices) | | ISO/IEC 27001 | A.5.15 / A.8.3 | Access control & information access restriction | access to each endpoint is granted explicitly, per principal, by its owner | [Sharing an endpoint with people and groups](#bailey-sharing-an-endpoint) | | ISO/IEC 27001 | A.5.15 / A.8.5 | Access control and secure authentication | access is granted per identity and per device, and is centrally revocable | [Server claim and device trust](#bailey-device-trust) | | ISO/IEC 27001 | A.5.15 / A.8.5 | Access control & secure authentication | access is deny-by-default and granted per device, not per credential | [Onboarding a new teammate (deny by default)](#bailey-onboarding-deny-by-default) | | ISO/IEC 27001 | A.5.16 | Identity management | identities are managed in the organisation's own directory, with a single joiner/leaver process rather than a parallel account store | [Single sign-on with your own identity provider](#bailey-single-sign-on) | | ISO/IEC 27001 | A.5.16 / A.5.18 | Identity & access-rights management | enrolment of a user and device is an explicit, authorized, recorded act | [Onboarding a new teammate (deny by default)](#bailey-onboarding-deny-by-default) | | ISO/IEC 27001 | A.5.18 / A.5.3 | Access rights & segregation of duties | admin, auditor and member are distinct, server-enforced roles, and the auditor's governance authority is separated from the member's build/ship authority | [People, roles and segregation of duties](#bailey-people-and-roles) | | ISO/IEC 27001 | A.5.23 | Information security for use of cloud services | what the service holds is continuously available in a customer-owned repository, in a documented layout, covering the acquisition-to-exit lifecycle | [Source mirroring and exit (no lock-in)](#bailey-source-mirror-exit) | | ISO/IEC 27001 | A.5.30 | ICT readiness for business continuity | a current, independent copy of every business process (code, spec and manifests) keeps running when the platform that produced it does not | [Source mirroring and exit (no lock-in)](#bailey-source-mirror-exit) | | ISO/IEC 27001 | A.5.30 / A.8.13 | ICT readiness for continuity | backups are verified by restoration into an isolated slot | [Disaster recovery: rehearse and restore](#bailey-disaster-recovery) | | ISO/IEC 27001 | A.5.37 | Documented operating procedures | the process and its rules are written down and kept current alongside the code | [Process description and flowcharts](#bailey-process-description) | | ISO/IEC 27001 | A.8.3 / A.5.15 | Information access restriction and access control | a workspace scopes who can reach its processes and data, and access is granted per workspace | [Workspaces](#bailey-workspaces) | | ISO/IEC 27001 | A.8.6 | Capacity management | memory is reserved, budgeted and admission-controlled from live host state, and over-use is detected and alerted | [Memory governance and the on-demand pool](#bailey-memory-governance) | | ISO/IEC 27001 | A.8.8 | Management of technical vulnerabilities | the image is CVE-scanned before it ships, with each finding linked to its advisory | [Deploy and Sync: shipping a change to main](#bailey-deploy-and-sync) | | ISO/IEC 27001 | A.8.8 | Management of technical vulnerabilities | out-of-date components are surfaced and patched to a known-good latest, with a controlled way back | [Keeping Bailey up to date (updates and rollback)](#bailey-keeping-bailey-up-to-date) | | ISO/IEC 27001 | A.8.13 | Information backup | backups are taken, retained and verifiable by restoration | [Backups and retention](#bailey-backups) | | ISO/IEC 27001 | A.8.15 | Logging (integrity and tamper-protection) | operational events are recorded on a fast-forward-only protected main, append-only and rewrite-proof, including against the operator | [Deployment history and Inspect](#bailey-deployment-history) | | ISO/IEC 27001 | A.8.15 / A.8.16 | Logging & monitoring | security events are exportable, in real time, to centralized monitoring and retention | [SIEM export of the security audit log](#bailey-siem-export) | | ISO/IEC 27001 | A.8.16 | Monitoring activities | the running estate is observable in real time | [Containers: the live roster of a stage](#bailey-containers) | | ISO/IEC 27001 | A.8.20–8.21 | Network and network-service security | outbound connections are controlled per service | [Egress firewall and GDPR data-processing record](#bailey-firewall-gdpr) | | ISO/IEC 27001 | A.8.24 | Use of cryptography and secret management | secrets are stored and injected securely, separated from source | [Secrets management per stage](#bailey-secrets) | | ISO/IEC 27001 | A.8.25 | Secure development lifecycle | work is organised per process, with its own pipeline and controls | [Business processes](#bailey-business-processes) | | ISO/IEC 27001 | A.8.25 / A.8.31 | Secure development lifecycle and environment separation | the agent builds in an isolated copy and sandbox, never touching production directly | [Coding agent and requirements](#bailey-coding-agent-requirements) | | ISO/IEC 27001 | A.8.31 | Separation of development, test and production | a personal copy, and any experiment branched off it and scoped to a single business process, isolates work in progress from main and from every deployed stage; an experiment has no path to main at all | [Personal copies and experiments](#bailey-copies-and-experiments) | | ISO/IEC 27001 | A.8.31 | Separation of development, test and production | a change is deployed through isolated stages, each on its own database and network | [Staged deployment and blue-green promotion](#bailey-staged-deployment) | | ISO/IEC 27001 | A.8.31 | Separation of development, test and production environments | dev, staging and production each run on their own database, file store and Docker network, the stages cannot reach one another, and production data is never present in a test stage | [Development, staging and production stages](#bailey-stages) | | ISO/IEC 27001 | A.8.32 | Change management | a change travels a fixed, recorded route (experiment → personal copy → main), with each hop an explicit, attributed action rather than a side effect | [Personal copies and experiments](#bailey-copies-and-experiments) | | ISO/IEC 27001 | A.8.32 | Change management | integration (Sync) is an explicit, attributed step separate from release (Deploy), each scoped to one business process | [Deploy and Sync: shipping a change to main](#bailey-deploy-and-sync) | | ISO/IEC 27001 | A.8.32 | Change management | production changes are reviewed and approved against a policy before release, then promoted verbatim | [Freeze and audit: four-eyes approval for production](#bailey-freeze-and-audit) | | SOC 2 | A1.1 | Availability | critical (always-on) workloads keep their reserved capacity, and non-critical ones are shed under pressure without losing their state | [Memory governance and the on-demand pool](#bailey-memory-governance) | | SOC 2 | A1.2 | Backup | snapshots of live data are taken on demand and on policy | [Backups and retention](#bailey-backups) | | SOC 2 | A1.2 / A1.3 | Backup and recovery testing | restores are rehearsed into an isolated DR slot and the test is recorded | [Disaster recovery: rehearse and restore](#bailey-disaster-recovery) | | SOC 2 | CC6.1 | Logical access security | the gate authenticates and authorizes every request before it reaches a workspace app | [Server claim and device trust](#bailey-device-trust) | | SOC 2 | CC6.1 | Logical access security | a new principal is denied at the gate until explicitly authorized | [Onboarding a new teammate (deny by default)](#bailey-onboarding-deny-by-default) | | SOC 2 | CC6.1 | Logical access security | each endpoint sits behind the gate with an explicit owner | [Server overview and endpoint inventory](#bailey-server-overview-endpoints) | | SOC 2 | CC6.1 / CC6.2 | Logical access & provisioning | access derives from the corporate identity provider, and de-provisioning there withdraws access in Bailey | [Single sign-on with your own identity provider](#bailey-single-sign-on) | | SOC 2 | CC6.1 / CC6.3 | Logical access & role-based access | endpoints are deny-by-default, and grants carry a role and an attributable grantor | [Sharing an endpoint with people and groups](#bailey-sharing-an-endpoint) | | SOC 2 | CC6.2 / CC6.3 | Access provisioning & de-provisioning | a new principal and device are granted access centrally by an authorized admin with a presence check, and a device is just as immediately revocable when lost or on a leaver | [Onboarding a new teammate (deny by default)](#bailey-onboarding-deny-by-default) | | SOC 2 | CC6.2 / CC6.3 | Access provisioning & de-provisioning | roles and per-person trusted devices are granted and revoked centrally | [People, roles and segregation of duties](#bailey-people-and-roles) | | SOC 2 | CC6.2 / CC6.3 | Access provisioning and de-provisioning | devices are granted and revoked centrally and immediately | [Device management and lost-device response](#bailey-your-devices) | | SOC 2 | CC6.3 | Role-based access | membership and roles are assigned per workspace and enforced server-side | [Workspaces](#bailey-workspaces) | | SOC 2 | CC6.6 | Boundary protection | the agent's egress is constrained by the workspace firewall allow-list | [Coding agent and requirements](#bailey-coding-agent-requirements) | | SOC 2 | CC7.1 | Vulnerability detection | the SBOM and CVE scan run on the image that actually ships | [Supply chain security and SBOM](#bailey-supply-chain) | | SOC 2 | CC7.2 | System monitoring | container health is visible per service, per stage | [Containers: the live roster of a stage](#bailey-containers) | | SOC 2 | CC7.2 | System monitoring | audit events feed an external SIEM for correlation and alerting | [SIEM export of the security audit log](#bailey-siem-export) | | SOC 2 | CC8.1 | Change management | changes originate in an isolated copy and reach main only through a deliberate Deploy; nothing merges itself | [Personal copies and experiments](#bailey-copies-and-experiments) | | SOC 2 | CC8.1 | Change management | commit, publish and deploy are one controlled, observable operation, refused outright when the copy is not a fast-forward of main | [Deploy and Sync: shipping a change to main](#bailey-deploy-and-sync) | | SOC 2 | CC8.1 | Change management | every change is recorded with its diff and the configuration in force | [Deployment history and Inspect](#bailey-deployment-history) | | SOC 2 | CC8.1 | Change approval | changes are authorised by required sign-offs recorded in a tamper-evident log before deployment | [Freeze and audit: four-eyes approval for production](#bailey-freeze-and-audit) | | SOC 2 | CC8.1 | Change management | version changes are visible, applied deliberately, and reversible | [Keeping Bailey up to date (updates and rollback)](#bailey-keeping-bailey-up-to-date) | | SOC 2 | CC8.1 | Change management | changes reach production only through a deliberate, observable promotion of the reviewed image | [Staged deployment and blue-green promotion](#bailey-staged-deployment) | | SOC 2 | CC8.1 | Change management | changes are built and tested in lower stages and reach production only through a deliberate, reviewable promotion | [Development, staging and production stages](#bailey-stages) | | GDPR | Art. 5(1)(c) | Data minimisation | real personal data lives only in production, and dev and staging are tested without production user data | [Development, staging and production stages](#bailey-stages) | | GDPR | Art. 5(1)(f) / Art. 32 | Integrity & confidentiality | personal data behind an endpoint is reachable only by explicitly granted principals | [Sharing an endpoint with people and groups](#bailey-sharing-an-endpoint) | | GDPR | Art. 28 | Processor obligations | a Data Processing Agreement is stored for every host that processes personal data before egress is allowed | [Egress firewall and GDPR data-processing record](#bailey-firewall-gdpr) | | GDPR | Art. 30 | Records of processing activities | each external recipient is logged with its purpose and whether personal data is transferred | [Egress firewall and GDPR data-processing record](#bailey-firewall-gdpr) | | GDPR | Art. 32 | Security of processing | credentials that protect personal data are kept out of source and role-gated | [Secrets management per stage](#bailey-secrets) | ## NIS2, DORA and regulatory fit {#regulation} BitSwan's position on regulation is that the controls NIS2 and DORA audits ask about are properties of the Bailey runtime itself, and every app and automation inherits them as soon as it is deployed. BitSwan describes this as "NIS2-ready automation, from day one" and states that "compliance retrofitted is compliance resented". BitSwan notes that in the Czech market the new cybersecurity act has made this a boardroom topic. **Four auditor questions and Bailey's built-in answers.** - **"Who can access this?"** Access control per user and per automation: who builds, who runs and who sees. The runtime enforces it, so the answer is a screen, not a policy PDF. - **"Show me the logs."** Every action is recorded automatically. When the auditor asks, the answer is already written. - **"Where does the data live?"** On the customer's servers, a private cloud or a public cloud, by the customer's choice, including where the AI model runs. Residency is a deployment setting, not a negotiation. - **"Can you trace an incident?"** Versioned, reversible deployments plus complete logs show what changed, when and by whom, with one press back to the last good state. **Controls by framework.** BitSwan's homepage states that the runtime enforces these controls on every app and that the evidence writes itself into the append-only history: - **NIS2**: access control, logging and supply-chain evidence come from the runtime, not from a policy document. - **DORA**: every change is frozen, tested and signed before production, with the record to show for it. - **ISO/IEC 27001**: the technical controls an Annex A review asks for are enforced, and the enforcement is logged. - **SOC 2**: change management and logical access are evidenced by a history nobody can edit. - **GDPR**: the Article 30 register and Article 28 processor agreements build themselves as external hosts are approved. BitSwan's site states that Bailey's append-only history supports NIS2, DORA, ISO 27001, SOC 2 and GDPR. The site describes these as controls the platform enforces and evidence it records. It does not claim that BitSwan holds a certification under any of these frameworks. **Shadow AI as an audit gap.** BitSwan states that the same controls close "the biggest audit gap most companies don't know they have": shadow AI. Under NIS2, each property of an ungoverned AI prototype (no access control, no logs, no isolation, running on a laptop) is a potential audit finding. **Scope of BitSwan's compliance claims.** BitSwan's NIS2 page says it describes platform controls and is not legal advice, and that a company's specific obligations depend on how the company is classified. BitSwan offers to go through a customer's compliance checklist line by line against the running platform during a demo, "so your answer to the auditor is a demonstration, not a promise". ## BitSwan compared with no-code and custom development {#comparison} BitSwan presents itself as a third option between no-code tools and custom software development: "Not no-code. Not a dev project." BitSwan's comparison page says each approach is right for some jobs, and that BitSwan is built for processes that touch the ERP, the bank, payroll or the auditor. | Criterion | No-code tools | Custom development | BitSwan | |---|---|---|---| | First result live | Hours | Months | Hours; first automation in production in week one | | Complexity ceiling | Low; assembly of pre-built steps | None | None; the agent writes real software | | Where your data lives | Their cloud | Yours | Yours; servers, private or public cloud, the customer's choice | | Can IT audit it | Barely; IT cannot audit what it cannot see | If specified and paid for | By default; access control and logs are the runtime | | Who maintains it | The customer, inside the tool's limits | The customer's budget, indefinitely | 24/7 standby team that responds when a system changes | | Cost shape | Per-seat and per-task, forever | Large upfront cost plus maintenance | Platform plus per-automation licence; a pilot shows value first | **When BitSwan recommends something else.** BitSwan's comparison page gives this guidance: - If all a company needs is two SaaS tools connected, such as a form feeding a spreadsheet or a Slack notification for a new lead, it should buy a no-code tool, which "will be running by lunch". - If the process is the company's product and the company is staffing a team around it, custom development may be right, provided the company hires well and budgets for the years after launch. - If the process touches the ERP, the bank, payroll or the auditor, the "admin-heavy middle of a real business", that is the job BitSwan's workshop was built for. BitSwan links this to its fifteen case studies in production. **Is BitSwan a no-code tool?** No. According to BitSwan, no-code tools let users assemble steps inside the vendor's cloud and hit a ceiling when processes get complex. BitSwan is an AI application workshop in which a person describes the need in plain language, an AI coding agent writes real software (backend, frontend and database), and it runs governed on the customer's infrastructure with no assembly ceiling. **Migrating from Zapier or n8n.** BitSwan states that migration from Zapier or n8n is possible and usually does not require removing anything on day one. BitSwan connects to the systems a company already runs. The usual path is to rebuild the most business-critical or compliance-sensitive workflows first, governed, and to leave simple connections where they are until it is convenient to move them. ## Case studies {#case-studies} BitSwan publishes 15 case studies of automations in production, covering finance, controlling, payroll, accounting, investment, risk, operations, sales and marketing. All were built on BitSwan by its implementation partner Harmonum. Each runs inside a Bailey (access-controlled, audit-logged and built for NIS2), which BitSwan gives as the reason "IT said yes to every one of them". The case studies do not name the client companies. Each quote is attributed to "the production deployment". ### Anomaly detection BitSwan's anomaly detection automation watches a telecom operator's live network data stream, evaluating millions of events per second, and flags faults before the customer calls. **Domain**: Telco, Operations. **Before**: Support engineers searched many systems by hand to find the cause of a customer's fault. Diagnosis took tens of minutes while the customer waited on the line. **What the automation does**: It sits on the live stream of technical network data, evaluates millions of events per second and flags anomalies as they form. An AI assistant then walks operators through the diagnosis. **Outcome**: Fault diagnosis cut from minutes to seconds. The customer's problem is identified instantly. Customer satisfaction is up. **Quote**: "We used to search blind — now we see the fault before the customer does." Source: [Anomaly detection](https://bitswan.ai/case-anomaly-detection.html) ### Invoice and payment automation BitSwan's invoice and payment automation takes an incoming invoice all the way to an executed bank payment in one automation, with every step logged. **Domain**: Finance. **Before**: Incoming invoices were processed by hand: checked for payment, then paid in bulk through the bank. The data lived in three places (cloud folders, the invoicing system and online banking), which caused errors and slowed the monthly close. **What the automation does**: One automation connects all three places. It watches the folders for new invoices, an AI agent extracts the data, and payment files are generated in XML and sent through the bank's API. There are no manual steps, and checks and human validation are available at every stage. **Outcome**: The full cycle is automated from receiving an invoice to paying it. Errors from manual re-entry are gone. The team has a live view of invoice and payment status and gets hours of routine work back every month. **Quote**: "We used to fish invoices out of folders — now they pay themselves." Source: [Invoice and payment automation](https://bitswan.ai/case-invoice-and-payment-automation.html) ### Real-time warehouse reporting BitSwan's real-time warehouse reporting automation gives a large e-commerce company live dashboards of warehouse performance and capacity, replacing reports built from the previous day's export. **Domain**: Operations, E-commerce. **Before**: Warehouse reporting was built by hand in Excel from WMS exports, so it was always delayed and always required manual work. **What the automation does**: It sits on the live data flow from all of the company's systems (warehouse staff, pickers, attendance and orders) and turns it into live dashboards of performance and capacity utilisation. **Outcome**: Warehouse operations are visible in real time. Manual exports and their errors are gone. Overloads are dealt with the moment they form. **Quote**: "We watched the stars with the naked eye. Now we have a telescope." Source: [Real-time warehouse reporting](https://bitswan.ai/case-real-time-warehouse-reporting.html) ### Downloading bank statements BitSwan's bank statement automation retrieves statements for more than fifty client accounts of an accounting firm on a schedule, names them consistently and files them where the accounting workflow expects them before the accountants start work. **Domain**: Finance, Accounting. **Before**: Every morning at the accounting firm began with logging into online banking for well over fifty client accounts, bank after bank: two-factor prompt, navigate, export, rename, file. This took several hours of clicking before the real work could begin, and one missed morning delayed reconciliation for every client behind it. **What the automation does**: It runs before the workday starts. It connects to each bank, retrieves every new statement, converts formats where banks differ, and names and files each statement exactly where the accounting process expects it. Failures, such as an expired credential or a changed bank interface, are flagged to a human instead of being silently skipped. Bank credentials are held in secrets management, never in a spreadsheet, and every run is logged inside the firm's Bailey. **Outcome**: The morning routine was cut from hours to minutes. Statements are filed and named consistently every day. Reconciliation starts as soon as work does. Bank credentials are in secrets management and every retrieval is logged. **Quote**: "I don't click through bank sites anymore — the statements are waiting." Source: [Downloading bank statements](https://bitswan.ai/case-downloading-bank-statements.html) ### Invoice automation BitSwan's invoice automation prepares monthly billing for the hundreds of clients of an international accounting firm without a manager touching a spreadsheet. **Domain**: Finance, Services. **Before**: Managers assembled billing data by hand, matching work performed to people and to each contract's rates. The work was demanding and error-prone. **What the automation does**: Two automations work together. The first reads contract parameters (work types, rates and price lists) into one reference table. The second, connected to the work-logging system, generates each client's invoice automatically. **Outcome**: The entire billing-preparation process is automated, with major time savings and errors eliminated. There is a clear line from the work performed to the amount invoiced. **Quote**: "Managers now spend their month on clients, not spreadsheets." Source: [Invoice automation](https://bitswan.ai/case-invoice-automation.html) ### Attendance and payroll processing BitSwan's attendance and payroll automation unifies and validates monthly attendance records that a staffing company receives from each client in a different format, cutting payroll preparation from days to minutes. **Domain**: Payroll. **Before**: The staffing company received monthly attendance records from every client in a different format, PDF from some and Excel from others. Accountants retyped everything into one model, which took days of demanding, error-prone work each month. **What the automation does**: It reads the PDFs and Excel files, converts everything into one unified format, validates the inputs and prepares the import files for the payroll system, with no retyping anywhere in the chain. **Outcome**: Payroll data preparation was cut from days to minutes. Manual errors were eliminated. Data accuracy is checked at multiple stages. **Quote**: "Whole days of retyping — gone. The spreadsheets process themselves." Source: [Attendance and payroll processing](https://bitswan.ai/case-attendance-and-payroll-processing.html) ### Adding bonuses to payroll BitSwan's payroll bonus automation calculates bonuses that employees earn from purchases in their employer's own retail chain and imports the final pay into the payroll system in one pass. **Domain**: Payroll. **Before**: Employees earn a bonus when they buy discounted goods in the company's own retail chain, and the bonus must appear correctly in their pay and in official reports. Accountants worked through each store's source data by hand, retyping purchase values, which was slow and error-prone. **What the automation does**: A single automated system takes the table of purchases and the table of base pay, computes every employee's final pay with one algorithm and imports the result directly into the payroll system. BitSwan describes it as running as an audited step in the payroll cycle, with the same rules and no retyping. **Outcome**: Payroll calculation was cut from several days to minutes. Data checks are automatic and calculations are consistent. The accounting team got its time back, with fewer errors from manual processing. **Quote**: "Spreadsheets full of numbers became one click — and payroll is done." Source: [Adding bonuses to payroll](https://bitswan.ai/case-adding-bonuses-to-payroll.html) ### Posting receipts to the books BitSwan's receipt bookkeeping automation reads photos and PDFs of receipts with an AI agent, categorises them by the company's chart of accounts and posts them to the accounting system, with a human check where the company wants one. **Domain**: Accounting. **Before**: Receipts arrived from across the company in every form: phone photos, emailed PDFs and crumpled scans. Someone typed the vendor, date, amount and VAT into the books by hand, and the category depended on who was typing that day. Month-end waited on "a shoebox" of paper. **What the automation does**: It watches the intake, a mailbox and a folder. An AI agent reads each receipt and extracts the vendor, date, amount and VAT rate. The category is assigned from the chart of accounts and past postings. Clean items post straight to the accounting system, and anything the agent is not sure about goes to the accountant for one-click approval. Every step runs inside the company's Bailey and is logged, access-controlled and traceable. **Outcome**: Receipts are posted without retyping. Categories are consistent because the chart of accounts decides, not the person typing. Month-end no longer waits on paper. Every posting is traceable to its source receipt. **Quote**: "The shoebox empties itself now." Source: [Posting receipts to the books](https://bitswan.ai/case-posting-receipts-to-the-books.html) ### Checking electricity invoices BitSwan's electricity invoice checking automation compares billed and actual electricity consumption for thousands of a mobile operator's base-station supply points automatically. **Domain**: Controlling, Telco. **Before**: Finance had to check electricity invoices for the operator's base stations: thousands of supply points, several suppliers and no practical way to verify billing against real consumption. Unauthorised usage and faults went unnoticed. **What the automation does**: Three automations work together. The first reads the PDF invoices and extracts billed consumption per station. The second measures the actual power draw of the equipment. The third compares the two and flags anomalies. BitSwan states that overbilling is caught the day the invoice arrives, not at year-end. **Outcome**: Thousands of supply points are checked automatically. Deviations and anomalies in consumption are surfaced. The company has an instant view of energy costs. **Quote**: "For the first time we see the whole network's consumption — hands-free." Source: [Checking electricity invoices](https://bitswan.ai/case-checking-electricity-invoices.html) ### Invoice and P&L reconciliation BitSwan's invoice-to-P&L reconciliation automation has an AI agent read invoices from fifteen European countries in any language and layout and consolidates them into one table from which the P&L is calculated. **Domain**: Controlling, Audit. **Before**: An auditing firm checks the P&L against incoming invoices from fifteen European countries, with several partners, many formats and many languages. Retyping everything into Excel models took days, and a retyped number could not be traced: when a figure looked wrong, finding its source invoice was "detective work". **What the automation does**: Two automations work in sequence. The first downloads the invoices and has an AI agent read each one, whatever the language or layout, writing the contents into structured tables. The second consolidates every format into a single unified table from which the P&L is calculated. Every figure keeps a pointer back to its source invoice and every run is logged, so the reconciliation is auditable end to end. **Outcome**: Days of retyping were cut to minutes. Fifteen countries, many languages and many formats now feed one table. Every P&L figure is traceable to its source invoice. The system surfaces discrepancies instead of the retyping burying them. **Quote**: "Fifteen countries of invoices, one clean table." Source: [Invoice and P&L reconciliation](https://bitswan.ai/case-invoice-and-p-and-l-reconciliation.html) ### Fund NAV calculation BitSwan's fund NAV calculation automation values hundreds of managed funds in minutes, so the finance team's size no longer limits how many funds the company can run. **Domain**: Investment. **Before**: Finance calculated share values every month for hundreds of managed funds. Input data was copied by hand from the company system into complex Excel models, one per fund. The process was slow and error-prone and was a hard ceiling on the company's ability to scale. **What the automation does**: The Excel models were rewritten as Python code. The workflow system calls the automation with each fund's parameters and receives the share value straight back into the internal system. BitSwan states that valuation runs on schedule from source data with a full audit trail. **Outcome**: Calculation time was cut from hours to minutes. Manual copying and its errors were eliminated. The number of funds can grow without growing the team. **Quote**: "Hours of analyst work now takes the system minutes." Source: [Fund NAV calculation](https://bitswan.ai/case-fund-nav-calculation.html) ### Redemptions: fee calculation BitSwan's redemption fee automation derives exit-fee formulas from signed client contracts and calculates the fee for a redemption in seconds. **Domain**: Investment. **Before**: When a client sells an asset, the back office must calculate the exit fee from the parameters of the signed contract. Done by hand, this was slow and error-prone, and it held up the sales department. **What the automation does**: Two automations work together. In the first, an AI agent read through all the contracts and derived the fee formulas. The second applies those formulas on demand. **Outcome**: Fee calculation was cut from hours to seconds. Nobody has to search contracts by hand. Calculations are consistent and auditable across all funds. **Quote**: "A contract and a calculator became a single click." Source: [Redemptions — fee calculation](https://bitswan.ai/case-redemptions-fee-calculation.html) ### Monitoring insolvencies across the EU BitSwan's EU insolvency monitoring automation gathers records from national insolvency registers across the EU and translates and consolidates them into one English-language system for law firms. **Domain**: Legal, Risk. **Before**: Law firms must watch insolvency registers across Europe to catch clients entering bankruptcy in time, but the registers are kept in national languages and national formats that international offices can barely navigate. **What the automation does**: A dedicated application gathers insolvency records from across the EU on a schedule, and a series of automations translates, categorises and consolidates everything into a single English-language system. **Outcome**: National registers are consolidated and translated automatically. Insolvencies across the EU can be tracked in English. Hundreds of hours of legal analysis are saved. **Quote**: "Days of digging through registers became one dashboard." Source: [Monitoring insolvencies across the EU](https://bitswan.ai/case-monitoring-insolvencies-across-the-eu.html) ### Competitor price monitoring BitSwan's competitor price monitoring automation pulls and parses competitor price lists from the web on a schedule, so a sales team can track competitors on any day instead of once a month. **Domain**: Sales. **Before**: Every month the sales team looked up competitor prices by hand and typed them into a comparison spreadsheet. This took days of demanding work, and the spreadsheet was the basis for setting the company's own prices. **What the automation does**: It pulls competitor price lists from the web on a schedule, extracts and reshapes the data, and feeds a Python model that replaced the previous Excel spreadsheet model. Changes are surfaced to the people who set the company's prices. **Outcome**: Days of processing were cut to minutes. Errors from manual re-entry were eliminated. Competitors can be tracked on any day, not once a month. **Quote**: "Weeks of comparing price lists now take a few minutes." Source: [Competitor price monitoring](https://bitswan.ai/case-competitor-price-monitoring.html) ### PR content approval BitSwan's PR content approval automation replaces approvals by Word document and email with one tracked flow of copy, approvers and sign-off. **Domain**: Marketing, Investment. **Before**: The PR team wrote copy and chased client approvals through Word documents and email threads. Versions blurred, approvals stalled, and the process could not keep up with fast-changing client demands. **What the automation does**: It gives the team an interface where they write the copy, attach the list of approvers and send it. Delivery runs through email automatically, every step is tracked, and the flow keeps approvals from stalling. The trail records who approved what and when. **Outcome**: Approval cycles were cut from days to hours. Versions and sign-off status are always clear. Work with clients is faster and calmer. **Quote**: "Finally a system that keeps pace with the team." Source: [PR content approval](https://bitswan.ai/case-pr-content-approval.html) ## Customers and track record {#customers} BitSwan states that it has been in production for more than five years and that more than 10 enterprise clients run more than 50 active workflows on it. Its customers include companies in telecommunications, legal services, investment funds, manufacturing, automotive, e-commerce and finance. **Track record figures on bitswan.ai.** - In production: 5+ years. - Enterprise clients: 10+. - Active workflows: 50+. - Published case studies: 15, all in production. **Named customers.** BitSwan's homepage lists these customers with their sectors: | Customer | Sector | |---|---| | CETIN | Telecommunications | | KŠD | Legal & corporate | | AVANT | Investment funds | | VAFO | Manufacturing | | Emil Frey | Automotive | | Famico | E-commerce | | Process Solution | Financial | **Customer quote.** BitSwan's homepage publishes this statement: "We went from piecemeal scripts and manual copying to a cohesive, governed platform that handles our core telecom and financial workflows. BitSwan keeps us agile without compromising our security audits." Juraj Eliáš · Chief Core Network Architect, CETIN Group **Case studies.** BitSwan's 15 published case studies describe automations in production without naming the client. The clients they describe include a telecom operator, a mobile operator with thousands of base-station supply points, a large e-commerce company, an accounting firm with more than fifty client bank accounts, an international accounting firm billing hundreds of clients, a staffing company, an auditing firm working across fifteen European countries, a fund manager with hundreds of managed funds, and law firms monitoring EU insolvency registers. All 15 were built on BitSwan by Harmonum. BitSwan's team page states that "every case study on this site has a face behind it". ## Team {#team} BitSwan's team and Harmonum's team are the same people: in BitSwan's words, "One team, one bench. The same people build BitSwan and run Harmonum — our implementation partner — which is why every case study on this site has a face behind it." The company's CEO is Tomáš Doležal and its CTO is Timothy Hobbs. | Name | Role | Contact | |---|---|---| | Tomáš Doležal | CEO | tomas.dolezal@bitswan.ai, +420 602 273 468 | | Michal Dvořák | CBDO | | | Timothy Hobbs | CTO | timothy.hobbs@bitswan.ai, +420 773 501 238 | | Pavel Šolc | Business Development | pavel.solc@bitswan.ai, +420 737 239 890 | | Lukáš Večerka | Lead Developer | | | Pavel Enderle | CDO | | | Jáchym Doležal | Developer | | | František Blachowicz | ML & Data | | | Ondřej Máca | Developer | | | Matěj Outrata | MarComm | | | Anita Doležalová | Back-Office Assistant | | | Tomáš Ebert | Developer | | | Roman Dvořák | Developer | | | Jakub Pogadl | Developer | | | Tomáš Peroutka | Developer | | | Patrik Kišeda | Dev Blogger | | | Matěj Novák | Developer | | BitSwan's team page lists 17 people and states that the team is larger: "more of us than this wall holds — the rest are still being photographed." ## Independent automation advisor programme {#advisors} BitSwan's independent automation advisor programme lets individual advisors create a public profile within Bailey and be matched with companies that want to automate their business processes, so they can win work as part of the BitSwan ecosystem. - **Public profile**: free forever. - **Training**: the profile includes free training in AI advisory. - **Joining**: prospective advisors join a waitlist on the advisors page and confirm their email address through a link sent to their inbox; the confirmation is what keeps them on the list. - **Help with a profile**: advisors who want help setting up their public profile can send a CV to support@bitswan.ai. Source: [Become an independent automation advisor](https://bitswan.ai/advisors.html) ## Frequently asked questions {#faq} ### What is BitSwan? BitSwan is an AI application workshop: a company's own people describe a process in plain language, an AI coding agent such as Claude Code writes real software for it, and the result runs governed inside a private runtime called Bailey. BitSwan's stated aim is to turn shadow AI into safe in-house innovation. ### Can the coding agent reach production in BitSwan? No. In Bailey, development, staging and production each run on their own database, file store and network, and the coding agent works only in dev. Production only ever receives a version that an auditor has frozen, read and signed. ### What leaves our network when we use BitSwan? Only traffic to hosts IT has approved: outbound traffic is default-deny in Bailey's staging and production stages, and every approval is logged. The AI model can also run inside the customer's infrastructure, so even prompts need not leave. ### Who approves a deployment in BitSwan? An auditor the customer designates, independent of the person who built the app, approves each deployment in Bailey. The auditor freezes the exact version, reads the diff and signs it, and the signature is the promotion to production. ### Does BitSwan work with the Claude Code our developers already use? Yes. Claude Code, Codex, Cursor and other terminal agents run inside the BitSwan workshop unchanged; the difference is that the result lands in a reviewed, logged Bailey runtime instead of on someone's laptop. ### What does the BitSwan audit log record? Bailey's audit log records every build, egress request, approval, sign-off and deployment, with who did it and when. The log is append-only, so not even the operator can edit it, and it can be exported for auditors. ### What happens to the apps if we stop using BitSwan? They keep running. What BitSwan builds is real code in the customer's repository on the customer's infrastructure, so nothing lives inside a product the customer would have to leave behind. ### Is BitSwan a no-code tool? No. No-code tools assemble pre-built steps inside the vendor's cloud and hit a ceiling on complex processes; with BitSwan an AI coding agent writes real software (backend, frontend and database) that runs governed on the customer's infrastructure with no assembly ceiling. ### Can we migrate from Zapier or n8n to BitSwan? Yes, and usually nothing has to be removed on day one. BitSwan connects to the systems a company already runs; the usual path is to rebuild the most business-critical or compliance-sensitive workflows first in Bailey and leave simple connections where they are until it is convenient. ### What is shadow AI and why does BitSwan say banning it fails? BitSwan defines shadow AI as any AI tool, or software built with AI, used inside a company without IT's knowledge, approval or controls. BitSwan argues that banning such tools removes visibility, not demand, because people keep building on personal accounts and devices, and that the fix is a governed runtime like Bailey where the right path is the easy path. ### Where does a BitSwan Bailey run? A Bailey runs on the customer's own servers, in a private cloud or in a public cloud, at the customer's choice. Where the AI model runs is a separate setting: fully self-hosted or an API model, with what the model sees controlled and logged either way. ### How does BitSwan help with NIS2 and DORA audits? BitSwan builds the controls NIS2 and DORA audits ask about into the Bailey runtime: access control per user and per automation, automatic logging of every action, a deployment setting for data residency, and versioned, reversible deployments for incident tracing. Under DORA, every change is frozen, tested and signed before production; BitSwan notes that its NIS2 page describes platform controls and is not legal advice. ### Does BitSwan support ISO 27001, SOC 2 and GDPR evidence? BitSwan states that Bailey enforces the technical controls an ISO/IEC 27001 Annex A review asks for and logs the enforcement, and that a history nobody can edit evidences SOC 2 change management and logical access. For GDPR, Bailey builds the Article 30 register and Article 28 processor agreements as external hosts are approved. ### How fast can BitSwan put a first automation into production? BitSwan states that the first automation is in production in week one. Its shadow AI guide says the first rebuilt shadow prototype "can be live in a week". ### How is BitSwan priced? BitSwan's pricing model is a platform licence plus a per-automation licence, and a pilot shows value before a wider rollout. BitSwan's site does not publish prices. ### Who maintains automations built with BitSwan? BitSwan provides a 24/7 standby team that responds when a connected system changes. BitSwan contrasts this with no-code tools, where the customer maintains automations inside the tool's limits, and with custom development, which is maintained from the customer's budget indefinitely. ### Which companies use BitSwan? BitSwan's homepage lists CETIN (telecommunications), KŠD (legal and corporate), AVANT (investment funds), VAFO (manufacturing), Emil Frey (automotive), Famico (e-commerce) and Process Solution (financial). BitSwan reports more than 10 enterprise clients, more than 50 active workflows and more than five years in production. ### What kinds of processes does BitSwan automate? BitSwan targets the admin-heavy middle of a business: finance, controlling, payroll, accounting, investment, risk, operations, sales and marketing. Its 15 published case studies include invoice-to-payment automation, bank statement retrieval, fund NAV calculation, EU insolvency monitoring and real-time network anomaly detection. ### Who is Harmonum and how is it related to BitSwan? Harmonum is BitSwan's implementation partner, based in Prague, and it built all 15 automations in BitSwan's published case studies. The same people build BitSwan and run Harmonum: in BitSwan's words, "one team, one bench". ### How do I book a BitSwan demo? BitSwan offers a 30-minute demo in English or Czech that shows Bailey and real automations in operation, with no slides and no obligations. A prospect books through the "Book a 30-min demo" button on bitswan.ai and BitSwan calls back to arrange a time; sales can also be reached at sales@harmonum.ai. ### What happens in Bailey if an employee's password or SSO account is compromised? Bailey binds access to approved devices as well as identities, so a stolen password, or even a fully compromised identity-provider or SSO account, does not by itself reach Bailey or the business processes behind it. A new device must show a six-digit code and be approved from a device that is already trusted. ### How is a new laptop or browser given access to Bailey? The new browser displays a six-digit code and waits. A user with an already-trusted device enters that code under Your devices → Link a device, and the new browser becomes a trusted device. ### What should we do in Bailey when a laptop is lost or stolen? Remove the device from the Your devices page. That revokes its cookie across the Bailey console and every workspace app immediately, whereas a password reset alone does not end the session already open on a stolen, unlocked laptop. ### Who can create a magic link in Bailey, and what does it grant? Only a user who owns the endpoint and also holds the admin or auditor role can mint a magic link, from that endpoint's Share dialog, and only for production endpoints. Opening it trusts the browser for that single endpoint, never fully, and does not add anyone to the access list; the endpoint's ACL still decides who gets in. ### How does Bailey separate development, staging and production data? Each business process in Bailey runs three stages, Development, Staging and Production, and each stage has its own database, file store and isolated Docker network. The stages cannot reach each other, and production data is never present in Development or Staging. ### Can code reach production in Bailey without review? Bailey's stage model makes promotion to Production a deliberate, reviewable step separate from building and shipping through Development and Staging, so an experienced reviewer can sign off first. Code reaches main only through a deliberate Deploy from an operator's personal copy. ### Can Bailey's AI coding agent access production data? No. The Bailey Coding Agent works in the operator's isolated copy and, although it can reach the internet, it cannot reach the production database or the user data in it. Its egress is constrained by the workspace firewall allow-list, and its output passes CVE scanning and the Deploy tab before it ships. ### How do I know which Bailey requirements are actually covered by tests? Bailey tracks a requirement's status (`proposed`, `pending`, `fail`, `retest`, `pass`) separately from whether a test exists for it; the Requirements & tests tab scans for a test carrying the requirement's id. A requirement can read `pass` on a judgement alone, so coverage should be checked as well as status. ### Can operators mark a Bailey requirement as passed themselves? No. In Bailey, `pass` and `fail` come only from a test run or from the agent recording what it found while building. Operators can accept an agent proposal into the contract or send a passing requirement back to be re-checked. ### Can an experiment in Bailey be deployed to production directly? No. Inside a Bailey experiment the Deploy tab is not rendered and the server refuses any publish from it. Work leaves an experiment only by being merged into, or adopted as, the operator's own copy, and leaves the copy only through Deploy. ### Does Bailey require a separate hosting account, DNS setup or TLS certificate for an app? No. A Bailey business process's frontend gets a real, routable, TLS-secured hostname on the Bailey server's own domain as soon as it runs, and the backend stays off the public internet, reachable only from the frontend over the workspace's private network. A custom domain is optional. ### Is the source code locked into Bailey? No. A Bailey admin can mirror a workspace to a git remote the organisation controls, so the source can be hosted elsewhere if the organisation chooses. ### How can an auditor see what Bailey exposes and who owns it? The Endpoint access page in the Bailey console lists every protected hostname behind the gate, including workspace dashboards, gitops and automation frontends, each with its owner and workspace, built from live state. The Server overview adds workspace and trusted-device counts and platform health. ### Which compliance controls do Bailey's access and environment features map to? The Bailey handbook maps device trust to NIS2 Art. 21(2)(j), SOC 2 CC6.1, ISO/IEC 27001 A.5.15 / A.8.5 and DORA Art. 9(3), and stage separation to ISO/IEC 27001 A.8.31, SOC 2 CC8.1 and GDPR Art. 5(1)(c). These are mappings to controls, not certifications. ### Can a developer in Bailey deploy over a change a colleague already published? No. Bailey's main branch is protected and fast-forward-only, so when a copy is behind main, Deploy is replaced by "sync first" and a Go to Sync button. The only alternative, Deploy this version, overwriting main…, lists every commit it supersedes and requires typing the business process name to confirm. ### Does Bailey ever force-push or rewrite git history? No. Every deploy advances main forward, and even the overwrite option replays commits onto main's tip and adds a commit that drops files visibly, leaving main's previous commits reachable. This is why Bailey's deployment history is append-only by construction. ### Who can promote a change to production in Bailey? Normal members cannot. An auditor or admin must freeze staging, and Promote to Production unlocks only once the audit policy's required number of auditor sign-offs (at least one) is met; a single Request changes blocks it. ### What does a Bailey auditor actually sign off on? The auditor signs a written report, scaffolded under What this version changes, Risk, Verified and Not verified, and the sign-off is bound to the frozen image's content hash. The report and verdict are committed to `bitswan.yaml` in the business process's git repository, attributed to the auditor. ### Can an approval be changed after a release has shipped in Bailey? No. When a version is promoted to production, Bailey records which verdicts released it and that image stops accepting new sign-offs. Auditing again requires a new version with its own freeze and audit. ### Does production run a rebuild of the code that was tested in staging? No. Bailey promotes the image verbatim, re-deploying the exact bytes that were built and reviewed even if the source has moved on since. ### How does Bailey avoid downtime when promoting or rolling back? Each promotion is a blue-green cutover across three app slots over two persistent databases: the idle slot starts on the live database, ingress repoints, and the old slot retires. Rolling back to the standby slot is equally fast. ### How can an auditor see exactly what ran in a past Bailey deployment? Inspect on any deployment shows Diff vs current, Files (the exact source tree), Secrets snapshot (the secret set in force) and Download image (the built image and schema bundle). Roll back re-deploys that exact recorded image and logs the rollback as a new entry. ### Where are secrets stored in Bailey and who can change them? Secrets are per-stage values injected at deploy time and never committed to the repository. Members can read them, while only admins and auditors can write them, and each deployment snapshots the secret set in force. ### How does Bailey test disaster recovery without risking production? Bailey restores a production backup into an isolated DR slot, never onto live production, where it can be verified and marked recovery-tested. Going live is an ingress cutover through the Restore pill, with no data migration, no redeploy and no downtime. ### What do Bailey backups include? Bailey snapshots capture the live blue-green database and object storage, reporting progress per store (Postgres, CouchDB and Garage). Snapshots are labelled, sized, restorable and clonable between stages, under a retention policy. ### How does Bailey help with GDPR Article 30 and Article 28? Bailey's egress firewall is default-deny in staging and production, and approving an outbound host requires a data-processing record: whether personal data is sent, what data, purpose, storage, jurisdiction and the signed DPA. The Article 30 register and Article 28 DPA file accumulate as the system is operated. ### How are accepted vulnerabilities (CVE waivers) recorded in Bailey? A CVE marked out of scope is written to `cve-waivers.yaml` in the business process's source tree with who, when and why, and ships with the next Deploy. Each waiver is listed in an audit-log section where a reviewer can restore it, and shown read-only on the production Supply chain tab. ### Does Bailey produce an SBOM? Yes. Every deployed image in Bailey carries a software bill of materials, and the CVE scan runs on the image that actually ships, with each finding linked to osv.dev, NVD and GitHub advisories. ### What roles does Bailey have, and how do they differ? Bailey has three server-enforced roles: admin, auditor and member. An admin holds every right, a member does the day-to-day build and ship work but cannot change governance settings, and an auditor reviews everything and holds governance controls but cannot deploy, promote or manage people, roles, devices or server admin settings. ### Is the Bailey auditor role just read-only access? No. A Bailey auditor is read-only on the operational pipeline but can set the recovery-test cadence and approve a production egress host's GDPR data-processing record. This keeps compliance authority separate from the authority to ship code, which is the segregation of duties auditors look for. ### Does Bailey support single sign-on with our own identity provider? Yes. A Bailey admin can add any OpenID Connect provider from Single sign-on in the console's Admin section, using a display name, an issuer URL and a client ID and secret. Provider groups can be mapped onto Bailey roles; without a mapping, everyone arrives as a member. ### Can an identity-provider outage lock administrators out of Bailey? Not by default, because Bailey keeps Bitswan account sign-in available alongside the organisation's provider. If an organisation turns Bitswan accounts off, an outage at its provider locks everyone out of the console, and an operator with a shell on the server must run `bitswan bailey sso disable` to restore Bitswan sign-in. ### Does a valid login give someone access to Bailey? No. Bailey is deny-by-default: a person who signs in from an unknown device sees nothing until an admin approves that device. A stolen password or a compromised identity-provider account used from an attacker's machine therefore reaches nothing on its own. ### How does Bailey approve a new device? The new device displays a six-digit code that the server never sends to the admin. The person reads the code to an admin in person or on a call, and the admin types it into the "Device awaiting approval" bar in People & roles and presses Trust this device, which enrols the user and trusts the device in one action. ### What happens to unapproved device requests in Bailey? Bailey never admits a device automatically, and there is no "deny" decision to remember. Device requests that no admin approves simply expire. ### How quickly can Bailey cut off a lost laptop or a departing employee? Immediately. An admin removes the device (or the person) in People & roles, and its access to the Bailey console and every workspace app ends instantly, without rotating passwords across applications. ### Who decides who can open an app deployed on Bailey? The owner of each endpoint does. Every Bailey-protected endpoint, including deployed automation frontends, workspace dashboards and gitops, is deny-by-default, and its owner grants access to a person by email or to an identity-provider group at User or Owner level, with each grant recorded with its grantor and time. ### Can Bailey send its audit log to our SIEM? Yes. Bailey streams its security audit log, including device-trust changes, role changes, workspace creation and access approvals, to an external collector over OpenTelemetry using OTLP/HTTP or OTLP/gRPC, with an optional bearer token. Update history and over-reservation alerts also reach the SIEM feed. ### How does Bailey stop experiments from starving production of memory? Each automation declares a memory reservation and a policy, `always-on` or `on-demand`, in `automation.toml`. Always-on services are guaranteed their memory, while on-demand services share a bounded pool, are shut down least-recently-used first under pressure or via a Sleep button, and wake on first access; promotions that would not fit the reserved budget are refused with the exact shortfall. ### How are Bailey updates applied and rolled back? Bailey flags out-of-date workspaces and the server binary, and each can be updated with one button from the Updates view without using a shell. Every update is recorded with who, when and the exact versions, and Roll back restores any of the last three recorded versions in one click, with the rollback itself recorded. ### Can we take our source code out of Bailey if we leave? Yes. An admin can mirror a Bailey workspace to a git remote the organisation controls on GitHub, GitLab or Forgejo over SSH, including each business process's code, specs, CVE waivers, deployment manifests and deployment history tags. The mirror is two-way and continuously updated, so an exit needs no cooperation from the provider. ### What does Bailey do if our mirrored git repository diverges? Bailey never force-pushes main on its own. If the remote's main is no longer a fast-forward or an inbound change conflicts, mirroring of main stops, the affected processes are named, and an admin chooses either Force push to repair or Pause the remote. ## Glossary {#glossary} - **Admin role**: The Bailey role that holds every right on the server, including deploying, managing people, roles and devices, and server admin settings. - **AI application workshop**: BitSwan's name for its product category, a governed place where a company's own people describe what they need in plain language and an AI coding agent writes real software that runs on the company's infrastructure. - **Append-only log**: Bailey's audit history of every build, egress request, approval, sign-off and deployment, which not even the operator can edit and which can be exported for auditors. - **Audit copy**: A Bailey copy of the exact source a frozen image was built from, in which an auditor reads the code and writes the audit report. - **Audit policy**: The Bailey setting for how many auditor sign-offs (at least one) a frozen image needs before Promote to Production unlocks. - **Auditor role**: The Bailey role that can review everything and set governance controls (recovery-test cadence, approval of a production egress host's GDPR data-processing record) but cannot deploy, promote or manage people, roles, devices or server settings. - **Bailey**: BitSwan's private, access-controlled runtime environment owned by the customer, in which everything built with BitSwan runs with access control, audit logs, sealed secrets and separate stages built in. - **Blue-green cutover**: The Bailey promotion mechanism in which the idle slot starts on the live database, ingress repoints to it and the old slot retires, with no downtime. - **Broadway**: BitSwan's metaphor for someone else's cloud (the vendor's rules, no-code ceilings and data that cannot be located), in contrast to a Bailey the customer owns. - **Business process**: The unit that is built, shipped and operated in Bailey, scaffolded with a backend and a frontend automation and scoping its own code, stages, secrets, backups and firewall. - **Coding Agent**: The AI agent that runs inside Bailey in the operator's isolated copy, builds automations from the specification and cannot reach production data. - **Default-deny egress**: Bailey's rule that outbound traffic from staging and production reaches only hosts IT has explicitly approved, with every approval logged. - **Deny-by-default**: The Bailey principle that no person, device or endpoint access is granted until it is explicitly approved or shared. - **Deploy**: The Bailey action that commits a business process's work in progress, fast-forwards main to it and rolls it out to the development stage. - **Deploy this version, overwriting main**: A guarded Bailey option that makes main hold exactly the user's copy, after listing every superseded commit and requiring the business process name to confirm. - **Device approval code**: The six-digit code shown on a waiting device, which the Bailey server never reveals to the admin, so the person must read it out as proof of presence. - **Device trust**: Bailey's hardware-bound access control, under which a signed-in person can reach nothing until an admin approves their specific device. - **DR slot**: The isolated Bailey slot into which a production backup is restored for verification, and which can be made live production by an ingress cutover. - **Edit this version**: A Bailey Inspect action that turns the user's copy into a previously deployed version as a restore commit on top of main. - **Endpoint access**: The Bailey console page listing every protected hostname behind the gate, with its owner and workspace. - **Endpoint sharing**: The owner-driven Bailey mechanism for granting a person or identity-provider group User or Owner access to a protected endpoint, with every grant recorded. - **Experiment**: A throwaway branch off an operator's personal copy in Bailey, scoped to one business process, which can be merged, adopted as the copy, left running or discarded, but can never deploy to main. - **Freeze**: the Bailey step that locks the exact version on staging so it cannot change while an independent auditor reviews and signs it. - **Git remote mirror**: The two-way Bailey feature that keeps a workspace's code, specs, CVE waivers, deployment manifests and deployment tags in a customer-controlled git repository over SSH. - **Independent automation advisor**: an individual with a free public profile in Bailey whom BitSwan matches with companies looking to automate their business processes. - **Link a device**: The Bailey action, under Your devices, in which a trusted user enters the six-digit code shown by a new browser to approve it. - **Live-dev**: The running preview deployment Bailey gives each automation in a copy or experiment, rebuilding automatically as code changes. - **Magic link**: A Bailey link minted from a production endpoint's Share dialog by an owner with the admin or auditor role, which trusts a browser for that one endpoint only and never adds anyone to its access list. - **Member role**: The Bailey role for day-to-day build and ship work, without the right to change governance settings; it is the default role for people arriving through single sign-on. - **Memory reservation policy**: The `automation.toml` setting that marks a Bailey automation as `always-on` (reserved memory, never stopped) or `on-demand` (the default; paused when idle, woken on access). - **Needs review**: The Bailey firewall list of unlisted outbound destinations awaiting an operator's approve or deny decision. - **On-demand pool**: The bounded memory pool Bailey sizes for the largest few on-demand services, from which least-recently-used services are shut down under pressure. - **People & roles**: The Bailey console page holding the roster of people, their roles and their trusted devices, where devices are approved and revoked. - **Personal copy**: The isolated branch of a workspace that Bailey creates automatically for each operator, where all work happens until the operator presses Deploy. - **Promote**: the Bailey step that moves a version from development to staging, or from staging to production, and is allowed only after the required tests pass and, for production, after the version is frozen and the audit is signed. - **Proposed**: The only Bailey requirement status that means "not yet part of the contract"; test runs skip proposed requirements until they are accepted. - **Recovery-tested**: The Bailey mark given to a backup that has actually been loaded into the DR slot and verified. - **Requirement**: A rule of a Bailey business process held as a runnable check in the Requirements & tests tab, with an `AI-` id if the agent proposed it or a `REQ-` id if a person wrote it. - **Restore**: the Bailey button that returns production to the previous signed version in one press. - **Revert dev to this version**: A Bailey Inspect action on the development stage that puts dev back by adding one new commit to main, picked up by everyone on their next Sync. - **Roll back**: The Bailey history action that re-deploys a recorded version's image verbatim and logs a new rolled back entry. - **Root device**: The Bailey device badge for the browser that claimed the server. - **SBOM**: The software bill of materials Bailey attaches to every deployed image, used for the CVE scan. - **Server claim**: The first sign-in to a new Bailey server, in which the operator presses Claim this server, becomes root admin and has their browser enrolled as the first trusted device. - **Shadow AI**: BitSwan's term for any AI tool, or software built with AI, used inside a company without IT's knowledge, approval or controls. - **Shadow IT**: BitSwan's term for ungoverned software outside IT's view, where data leaves freely, nobody audits it and production is one prompt away. - **SIEM forwarding**: The Bailey feature that streams the security audit log to an external OpenTelemetry collector over OTLP/HTTP or OTLP/gRPC in real time. - **Stage**: One of Bailey's three per-process environments, Development, Staging or Production, each with its own database, file store and isolated Docker network. - **Sync**: The Bailey step that replays a user's work on top of commits a colleague published to main, shown as a tab only while that business process is behind. - **Trust cookie**: The per-device credential a Bailey device carries after approval, letting the person return without re-approval. - **Trusted device**: A browser that Bailey has enrolled and approved, whose cookie proves the hardware as well as the user's credentials and which can be revoked across the whole platform at once. - **Version ledger**: The Bailey record of every server and workspace update, with who applied it, when and the exact from and to versions, shown as Update history and streamed to the SIEM. - **Vibe coding**: building software by chatting with an AI, which BitSwan describes as happening everywhere with no rules and no category. - **Waiver (out-of-scope CVE)**: A Bailey record in `cve-waivers.yaml` that excludes a vulnerability finding, stating who marked it, when and why. - **Workspace**: A thematic, isolated tenancy in Bailey with its own business processes, data and member roster, where access and roles are decided. ## Contact and booking a demo {#contact} BitSwan offers a 30-minute demo in English or Czech in which it shows Bailey, the prospect describes their work, and both sides decide whether BitSwan fits. BitSwan describes the demo as "real automations in real operation — no slides, no obligations". **What the demo covers.** - A live walkthrough of Bailey and of automations running in production. - The prospect's own process: BitSwan invites prospects to "bring us a process" and shows how it would be built. - On request, a line-by-line review of the prospect's NIS2 or DORA compliance checklist against the running platform. **How to book.** The "Book a 30-min demo" button on bitswan.ai asks for a phone number. BitSwan then calls that number to arrange a time. **Contact details.** - Address: Pujmanové 1753/10a, 140 00 Praha, Czechia. - Sales: sales@harmonum.ai. - Advisor programme and profile help: support@bitswan.ai. - Named contacts: Tomáš Doležal, CEO (tomas.dolezal@bitswan.ai, +420 602 273 468); Timothy Hobbs, CTO (timothy.hobbs@bitswan.ai, +420 773 501 238); Pavel Šolc, Business Development (pavel.solc@bitswan.ai, +420 737 239 890). **Websites.** - English: [https://bitswan.ai/](https://bitswan.ai/) - Czech: [https://bitswan.ai/cs/](https://bitswan.ai/cs/) - Case studies: [https://bitswan.ai/use-cases.html](https://bitswan.ai/use-cases.html) - Bailey: [https://bitswan.ai/product-bailey.html](https://bitswan.ai/product-bailey.html) - NIS2 and DORA: [https://bitswan.ai/nis2.html](https://bitswan.ai/nis2.html) - Shadow AI guide: [https://bitswan.ai/shadow-ai.html](https://bitswan.ai/shadow-ai.html) - Comparison: [https://bitswan.ai/compare.html](https://bitswan.ai/compare.html) - Team: [https://bitswan.ai/team.html](https://bitswan.ai/team.html) - Advisors: [https://bitswan.ai/advisors.html](https://bitswan.ai/advisors.html)