GLOSSARY

Plain words for Atom9, identity, privacy, security, compliance, and AI.

Atom9 uses product, legal, security, AI, and developer words that can sound technical. This glossary explains the words in the way Atom9 uses them, so customers, admins, developers, and non-technical users can understand what the platform is doing and why it matters.

Identity and access Security and trust Privacy and rights Compliance records AI and agents Projects and workflows Developer terms Operations and storage
Identity and access

Accounts, login methods, sessions, workspaces, roles, and customer-app access.

Account
A personal Atom9 login identity. It belongs to one person and can use password, magic link, passkey, OIDC, app approval, or another approved sign-in method.
Personal account
The person-owned part of Atom9 login. It is separate from a company workspace and can reach different workspaces or customer apps when the person has access.
Atom9 login
Atom9's hosted identity layer. A person can use it to sign in to Atom9 itself and, where enabled, to customer apps that accept Atom9 as a login provider.
Account security
The controls that protect a person's account: email verification, strong login methods, passkeys or MFA where required, recovery handling, provider linking checks, session revocation, and suspicious-activity reporting.
Credential
Something used to prove identity or access, such as a password, passkey, recovery token, API key, private key, provider token, or authenticator code.
Password
A secret phrase used for login when password sign-in is enabled. Atom9 treats passwords as sensitive credentials and never asks users to send them through chat or support messages.
Passkey
A modern sign-in method based on cryptographic keys, often unlocked with Face ID, Touch ID, Windows Hello, a phone, or a hardware security key. Passkeys reduce phishing risk because the private key is not typed into a form.
Email verification
A check that confirms a person controls an email address before Atom9 treats it as verified for account creation, provider linking, recovery, or important notices.
Identity provider
A trusted system that verifies a user, such as Google, Microsoft, GitHub, Apple, an enterprise SSO provider, or Atom9 itself.
OIDC
OpenID Connect. A standard way to sign in with an identity provider and receive verified identity claims such as email, name, and provider subject ID.
OAuth
A standard used to grant limited access between systems. OIDC builds on OAuth to add identity login information.
Single sign-on
A login setup where a person signs in through one trusted identity provider to access several approved apps.
MFA
Multi-factor authentication. A second proof, such as an authenticator app, passkey, security key, or backup code, used to strengthen login security.
Authenticator app
A phone or desktop app that generates short-lived login codes or approves sign-in requests. It is used as a second factor or as part of app-approval login.
Provider linking
Connecting a new sign-in provider to an existing Atom9 account. Atom9 requires proof of control before it links providers so accounts are not silently merged.
Session
The signed-in state after login. A session usually uses secure browser cookies and has an expiry, activity state, device context, and revocation rules.
Session controls
Rules that manage signed-in sessions, including expiry, refresh, revocation, device listing, sign-out, suspicious-session reporting, and stronger controls for higher-risk work.
Remember me
A login choice that can keep a session active longer on a trusted device. It must not weaken security on shared, public, or unmanaged devices.
Signed-in device
A browser, phone, tablet, or computer associated with a session. Users should remove devices they no longer control.
Workspace
The company, team, or product area where projects, files, people, roles, settings, customer apps, and approvals are managed.
Tenant
A separated customer or workspace environment. Tenant separation keeps one customer's users, settings, projects, and data separate from another's.
Membership
The link that gives a personal account access to a workspace or customer app with a specific role and status.
Role
A named access level such as owner, admin, member, operator, reviewer, or viewer. Roles group permissions into understandable responsibilities.
Role boundaries
The separation that prevents a user, app, or agent from acting outside its assigned role. Role boundaries decide what can be viewed, changed, approved, exported, or administered.
Permission
A specific allowed action, such as reading files, editing content, approving launch, managing users, exporting data, or changing login settings.
Least privilege
A security principle: give each person, app, provider, and agent only the access needed for the work, and remove access when it is no longer needed.
Workspace owner
The person or organisation responsible for workspace access, settings, approvals, billing references, connected tools, and customer-app configuration.
Invited user
A person invited into a workspace or customer app. The invite should define the role, scope, and destination before access is granted.
Contact
A known person in the network area, such as a lead, prospect, vendor, or customer contact. A contact does not become a login user unless an invitation or account flow creates access.
User
A person with login access or an app profile. Atom9 distinguishes personal accounts, workspace members, customer-app users, and contacts because they have different rights and data.
Customer app
A website, portal, booking flow, onboarding flow, account area, workflow, or other service built or operated with Atom9 for one of Atom9's customers.
Customer-app user
A person using a customer app. They may also have an Atom9 account, but their service relationship and app-specific data belong to the customer app flow.
Customer KYC
The information a customer app needs to provide its service, such as address, eligibility, booking details, documents, or sector-specific profile fields. Atom9 account data stays minimal unless the user chooses to share more.
Customer-controlled data
Data where the customer decides the purpose, content, retention, access, and lawful basis. Atom9 usually processes this data under customer instructions.
Customer notice
A customer-facing explanation such as privacy text, cookie text, terms, AI disclosure, consent wording, onboarding explanation, or sector-specific notice.
Service purpose
The practical reason a product or customer app exists and the outcome it provides. Service purpose decides which data, notices, roles, and controls are needed.
Product purpose
The Atom9 feature reason for using data, such as login, security, support, project building, billing, rights handling, or customer-app operation.
Control point
A place in a workflow where Atom9 checks access, purpose, consent, approval, security, provider use, or legal requirements before continuing.
Security and trust

Security controls, safe product surfaces, service authentication, and incident handling.

Approved product surface
A visible and supported way to use Atom9, such as the product UI, hosted login, documented SDK, documented public API path, or agreed support channel.
Service authentication
The way Atom9 product services prove that a request came from an approved product path. It includes signed requests, request integrity checks, anti-replay controls, and actor/workspace context. Users do not operate this directly.
Request signing
A security method where one system signs a request so the receiving system can verify who sent it and whether important request parts were changed.
Anti-replay control
A protection that stops an old signed request from being captured and used again later.
Context check
A check that keeps important request context, such as workspace, actor, request, or trace information, attached to the action being performed.
Audit record
A saved record of an important action. It can include who acted, what object changed, when it happened, what kind of action it was, and which request or trace explains it.
Audit trail
A connected history of audit records, decisions, approvals, tool actions, and evidence that explains what happened over time.
Evidence trail
The practical proof chain that connects a user decision, AI suggestion, approval, tool action, compliance result, and final customer-facing change.
Provider controls
Settings and review practices that limit how external providers are used, including identity providers, email delivery, AI models, file storage, search, analytics, payments, monitoring, and support tools.
Operational safeguards
Day-to-day protections that keep Atom9 reliable and safe, such as backups, monitoring, access review, incident handling, provider review, change control, rate limits, and secure configuration.
Safe defaults
Product settings chosen to reduce risk before a user changes anything, such as private workspaces, limited roles, explicit approvals, secure cookies, and minimal data collection.
Product control
A built-in product behaviour that enforces or supports a rule, such as a permission check, approval gate, consent choice, launch check, audit record, or validation step.
Platform integrity
The trustworthiness of Atom9 as a whole: services behave as intended, access boundaries hold, records are reliable, and users cannot quietly bypass important controls.
Material change
A change important enough that it can affect rights, security, cost, data use, availability, compliance, customer trust, or how a service works.
Material fact
A fact important enough that a reasonable user or customer would need it to make an informed decision.
CSRF
Cross-site request forgery. A web attack where another site tries to make a signed-in browser perform an unwanted action.
Input validation
Checking user or system input before using it, so bad, unsafe, missing, unexpected, or malformed values do not become product changes.
Rate limit
A limit on how often an action can happen, used to reduce abuse, brute-force attempts, accidental loops, and excessive provider usage.
Secret
A value that must stay private, such as an API key, client secret, private key, recovery token, password, signing key, or backup code.
API key
A secret used by one system or developer to access an API. API keys should be scoped, protected, rotated when needed, and never placed in public frontend code.
Private key
The secret half of a cryptographic key pair. It must not be shared because it can prove identity, decrypt data, or sign requests.
Token
A temporary or scoped value used to prove a login, authorise a request, verify an email, recover an account, upload a file, or continue a workflow.
Verified domain
A domain that the customer has proven they control before it is used for login, customer apps, email, callbacks, or production traffic.
HTTPS
The secure web protocol used to protect traffic between a browser and a site. Production login and account flows should use HTTPS.
Suspicious session
A login session that looks unexpected, such as a strange device, location, time, browser, failed pattern, or user report.
Security incident
An event that may affect confidentiality, integrity, availability, account safety, platform trust, or customer data. Incidents require containment, evidence preservation, and appropriate notice.
Vulnerability report
A report that describes a possible security weakness. It should be sent through approved channels and must not include passwords, private keys, session cookies, or unnecessary personal data.
Personal data breach
A security breach that leads to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.
Launch safety
The security, privacy, AI, content, cookie, accessibility, and sector checks that must be reviewed before a customer app becomes live.
Vulnerability disclosure
The approved process for reporting a suspected security weakness without exploiting it, exposing data, disrupting service, or publishing details before coordinated handling.
Privacy and rights

GDPR roles, lawful basis, consent, rights, retention, and transfers.

Personal data
Information about an identified or identifiable person, such as name, email, login events, messages, forms, bookings, files, support requests, or customer-app profile fields.
Processing
Any action performed on personal data, including collecting, storing, using, sharing, reading, changing, exporting, deleting, anonymising, or securing it.
Controller
The organisation that decides why and how personal data is processed. Atom9 can be controller for Atom9 account data, while customers are usually controllers for their own customer-app users.
Processor
The organisation that processes personal data for a controller and under documented instructions. Atom9 is often a processor for customer workspace and customer-app data.
Sub-processor
A provider used by a processor, such as hosting, email delivery, AI model APIs, file storage, monitoring, support, or payment systems.
Data processing agreement
A contract that sets processor instructions, security duties, sub-processor rules, incident support, rights assistance, export, deletion, and audit-support terms.
Lawful basis
The legal reason for processing personal data, such as contract, legal obligation, consent, legitimate interests, vital interests, public task, or documented customer instructions.
Contract basis
A lawful basis used when processing is necessary to provide a requested service or perform a contract with the person or customer.
Legitimate interest
A lawful basis used when there is a real need, the use is balanced against people's rights, and the use is explained clearly.
Special-category data
Highly sensitive GDPR data, including health, biometric, political, religious, union, sex life, sexual orientation, racial or ethnic origin data.
Data minimisation
Collecting and using only the personal data needed for a clear purpose. Customer-app KYC should ask for only what the service actually needs.
Purpose limitation
Using personal data only for the purposes explained or lawfully compatible with the original purpose.
Data category
A label for the kind of data being processed, such as account data, contact data, booking data, payment reference, health data, child data, location data, or support data.
Retention
The period data is kept before it is deleted, anonymised, archived, or kept only for legal, security, accounting, backup, or dispute reasons.
Deletion
Removing data when it is no longer needed or when a valid request requires it. Some records may remain where law, security, backups, or evidence duties require retention.
Soft delete
Marking data as deleted so normal product views hide it, while preserving recovery, audit, retention, or legal handling until final deletion or ageing rules apply.
Permanent delete
An exceptional physical deletion path. It must be restricted, justified, and preserve the necessary deletion evidence outside the removed record.
Anonymisation
Changing data so it can no longer identify a person, directly or indirectly, using reasonably available means.
Pseudonymisation
Separating identifying details from other data so extra information is needed to link it back to a person. It reduces risk but is still personal data under GDPR.
Data subject request
A privacy-rights request from a person, such as access, export, rectification, erasure, restriction, objection, or portability.
Access request
A request to know what personal data is processed and receive a copy or explanation where the law requires it.
Rectification
Correcting inaccurate or incomplete personal data and keeping enough evidence to explain the correction.
Portability
A right to receive certain personal data in a structured, commonly used, machine-readable format where the legal conditions apply.
Restriction
Limiting processing of personal data while a request, dispute, legal condition, or data-quality issue is handled.
Objection
A person's right to object to certain processing, especially processing based on legitimate interests or direct marketing.
DPIA
Data Protection Impact Assessment. A structured risk review required for processing likely to create high risk to people's rights and freedoms.
Standard Contractual Clauses
EU-approved contract terms used as a transfer safeguard when personal data moves outside the EU/EEA.
Transfer safeguard
A legal, contractual, technical, or organisational protection used when personal data is processed outside the EU/EEA.
EEA
The European Economic Area. It includes EU countries plus Iceland, Liechtenstein, and Norway.
Local storage
Browser storage used by a website to remember choices such as privacy preferences or theme. It is not sent with every request like a cookie.
Workspace data
Data inside a workspace, such as company settings, team access, projects, files, boards, content, approvals, provider settings, contacts, and activity records.
Project data
Data attached to a project, such as prompts, plans, atoms, tasks, boards, pages, files, approvals, launch checks, activity, and tool results.
Operational data
Data produced while operating the service, such as logs, errors, delivery events, performance data, monitoring signals, support records, and provider events.
Automated processing
Processing performed by software according to rules, models, workflows, or agent actions. It can still require human review depending on risk and law.
Automated action
An action carried out by software or an AI agent, such as sending a notification, moving a task, creating content, running a check, or calling a tool.
Compliance records

How Atom9 proves decisions, consent, data access, requirements, and review gates.

Compliance record
A platform record used to answer audit, GDPR, AI-governance, security, or legal questions later. It describes what happened, who caused it, which workspace it belongs to, and what evidence applies.
Compliance event
An important event recorded for compliance purposes, such as a data change, approval, consent decision, rectification, export, gate review, or launch decision.
Trace
A correlation chain that connects related product actions, service work, agent steps, and compliance records so Atom9 can explain what caused what.
Request ID
A unique label for one technical request. It helps support and compliance review connect logs, product events, and user-visible results without relying on guesswork.
Actor
The person, agent, customer app, provider, or system component responsible for an action. Audit records need actor context so accountability is clear.
Read audit
A record that sensitive identifiable data was viewed or accessed. Atom9 uses read audit where the data-source policy requires proof of access.
Write audit
A record that data or configuration changed. Write audit helps explain who changed what and why.
Data-source policy
A governance rule for a source of identifiable data. It can describe data categories, legal basis, consent needs, retention, read audit, AI access gates, export behaviour, and anonymisation behaviour.
Read gate
A compliance checkpoint before viewing sensitive identifiable data. It can allow access, deny access, or require review depending on the configured data-source policy.
Compliance gate
A checkpoint that evaluates whether an operation is allowed, denied, or needs review. A gate stores the reason and resolution so the decision can be explained later.
Approval gate
A visible stop point where a human must approve, reject, or request changes before Atom9 continues. Approval gates are used for plans, launches, sensitive changes, and regulated workflows.
Review queue
A work list of unresolved compliance items, such as gates that need a decision, open data subject requests, failed exports, or evidence tasks.
Evidence record
A saved proof item, such as a decision, reason, consent grant, revocation, export result, tool action, launch check, document, or user approval.
Export package
A collected package of records produced for a rights request, audit, trust review, or legal workflow. Sensitive credentials and secrets are not exported as ordinary subject data.
Regulation
A law or rule set that may apply to a customer, project, or workflow, such as GDPR, ePrivacy, the EU AI Act, DORA, PCI DSS, ISO 27001, or sector-specific rules.
DORA
Digital Operational Resilience Act. The EU financial-sector regulation focused on making digital services able to withstand, respond to, and recover from ICT disruptions.
NIS2
The EU cybersecurity directive for important and essential services. It focuses on cybersecurity risk management, incident handling, business continuity, supply-chain security, and reporting.
ePrivacy
The EU privacy rules for electronic communications, cookies, tracking, and similar browser or device storage. It works alongside GDPR.
Cyber Resilience Act
The EU cybersecurity framework for products with digital elements. It is relevant when software or connected products are made available on the EU market.
Data Act
The EU data economy law that can affect data access, sharing, cloud switching, and use of data from connected products or related services.
European Accessibility Act
The EU accessibility law for certain products and services, including important digital services. It supports accessibility for people with disabilities.
Digital Services Act
The EU law for online intermediary services and platforms. It can matter when a customer app hosts, indexes, moderates, or distributes user-provided content at platform scale.
Operational resilience
The ability of a service to keep operating, fail safely, recover, and learn from disruptions while protecting customers and data.
ICT risk management
The process for identifying, protecting, detecting, responding to, recovering from, and improving risks in digital systems, providers, data, access, and workflows.
Third-party ICT risk
Risk created by relying on external technology providers for important digital services, including provider failure, concentration, security weakness, location, support, and exit concerns.
Resilience testing
Testing that checks whether a service can keep operating, recover, or fail safely during disruption, provider failure, configuration mistakes, or workflow errors.
Business continuity
Plans and controls that help a service keep operating or recover after disruption, including backups, recovery steps, provider fallback, communication, and priority decisions.
Incident classification
Sorting an incident by type, severity, data impact, service impact, customer impact, provider involvement, and required notification or recovery path.
Financial-sector service
A service connected to banking, payments, insurance, investments, credit, financial advice, regulated finance operations, or other financial-sector activity.
Regulated workflow
A workflow where law, sector rules, contract terms, or customer policy require stronger controls, review, evidence, or approval before use.
High-impact decision
A decision or recommendation that can materially affect a person's access, rights, money, work, health, safety, education, housing, or essential services.
Critical or important function
A function whose disruption would materially affect a regulated service, customer operation, legal duty, or user outcome.
Outsourcing
Using another provider to perform a function that supports a customer service. In regulated sectors, outsourcing can trigger extra review, contract, and exit requirements.
Supervisory authority
A regulator or public authority responsible for supervising compliance with a law or sector rule, such as data protection or financial supervision.
Regulation edition
A specific version or source edition of a regulation or framework. Customers can be measured against one edition while planning work toward another.
Requirement
A concrete compliance need for a customer, project, workflow, data source, AI decision, or customer app. It should be actionable and traceable to a source reason.
Requirement task
A task created to close a compliance requirement, such as drafting a notice, adding consent, reviewing a data source, setting retention, or collecting evidence.
Compliance document
A document that proves or explains compliance, such as a DPA, policy, certificate, insurance record, DPIA, privacy notice, cookie notice, or AI risk review.
Document expiry
A date when a compliance document needs renewal, review, or replacement. Expiry should create visible work before the document becomes stale.
Trust center
A customer-facing area that can collect and present security, privacy, AI, compliance, provider, and document evidence for buyers or auditors.
AI and agents

Agents, prompts, tools, models, memory, approvals, and AI Act concepts.

AI agent
A software assistant that can chat, ask questions, use approved tools, draft work, create tasks, inspect project data, and move a project forward under workspace controls.
A9 agent
Atom9's built-in assistant. It helps operate and build inside the platform by using chat, project context, focused tool domains, and approval gates.
Agent run
A single turn or work loop where an agent receives context, may call tools, records tool results, and returns a visible answer or next approval step.
Agent loop
The repeated process where an agent asks, drafts, uses tools, verifies, explains, requests approval, and continues until the project reaches the next valid state.
Prompt
The instruction, question, file, project context, or user message given to an AI system.
Prompt safety
Rules that stop users from placing secrets, unnecessary personal data, regulated data, or unrelated confidential material into prompts unless the workspace is configured and authorised for it.
Context
The information the agent is allowed to use for a task, such as the current page, selected project, prior chat, atoms, files, tool results, settings, and approved decisions.
Model
The AI system that generates text, plans, code, images, classifications, or tool calls based on prompts and context.
Model provider
The company or system that runs the AI model used by Atom9 or a configured workspace.
Provider identity
The visible record of which external provider is used for a function, such as identity, AI, email, files, search, support, monitoring, or payments.
Model identity
The visible record of which AI model or model family was used for a task, where the workflow requires accountability or repeatability.
Model settings
Configuration that affects AI behaviour, such as model name, tool access, reasoning mode, output limits, provider endpoint, or workspace policy.
Thinking view
An optional product view that can show extra reasoning or work notes when the configured model and workspace allow it. It is a display choice and not a replacement for approval.
Tool use
An AI agent calling an approved function, such as reading project data, creating a task, generating a page, searching, uploading a file reference, or sending a notification.
Tool invocation
A recorded tool run. Atom9 can track the tool key, input, output or error, duration, policy decision, related conversation, and result status.
Tool-access snapshot
A record of which tools an agent could use for a customer context at a point in time. It helps keep agent access explainable and reviewable.
MCP tool
A controlled tool interface that lets an AI agent access approved systems, data, or functions.
RAG
Retrieval-augmented generation. An AI pattern where relevant documents or data are retrieved before the AI answers or creates work.
Agent memory
Saved agent context, summary, or reference material that can help future work. Memory must respect workspace controls, retention, deletion, and user rights.
Vector index
A search index used to find semantically similar content. It helps retrieval, but it is not the authority for permissions, tenancy, or original data.
Human oversight
A person stays able to review, approve, reject, correct, or stop important AI-assisted work.
AI-generated content
Text, images, pages, plans, workflows, tasks, code-like configuration, or explanations created or materially changed by an AI system.
EU AI Act
The EU regulation for artificial intelligence systems. It sets duties around risk, transparency, governance, human oversight, prohibited practices, and high-risk uses.
AI literacy
Practical understanding of what AI can do, what it cannot do, what risks exist, when human review is required, and how to use AI responsibly.
High-risk AI
AI used in areas where errors or misuse can significantly affect people, such as employment, education, finance, health, safety, public services, or access to essential opportunities.
Prohibited AI practice
An AI use that Atom9 does not support because applicable law prohibits it, such as unlawful manipulation, social scoring, prohibited biometric use, or unlawful discriminatory profiling.
Transparency risk
A situation where people need to know that AI is being used, that content is AI-generated, or that automated assistance affected a workflow.
Risk classification
The process of deciding which level of AI, privacy, security, or sector controls apply to a project or workflow.
Data governance
The rules for data quality, source, purpose, retention, access, consent, AI use, documentation, and review.
Robustness
The ability of a system or AI workflow to work reliably, handle expected errors, resist misuse, and fail safely.
Serious incident
A significant event involving AI, privacy, security, safety, or service integrity that requires escalation, evidence preservation, and possible notice to customers, users, or authorities.
AI provider
The party that provides or runs an AI model or AI system. The provider may be Atom9, a customer, or an external model provider depending on the workflow.
AI deployer
The organisation that uses an AI system in a real service or workflow. Customers are often deployers for their own customer apps.
AI governance
The controls that keep AI use accountable, including risk classification, data governance, provider records, human oversight, transparency, testing, incident handling, and change review.
Projects and workflows

Project building, atoms, boards, cards, pages, flows, and launch work.

Project
A container for one outcome, such as a website, booking system, onboarding flow, customer app, automation, internal tool, or compliance package.
Project overview
The main page for a project. It should show phase, next action, approvals, agent work, boards, recent changes, system overview, and what the customer needs to review.
Atom
An Atom9 document or structured note that can hold plans, specs, diagrams, charts, fetched data, tool results, or reusable project knowledge.
Spec atom
The readable project specification. It explains what the system does, who uses it, what data is involved, what components are needed, and what compliance questions apply.
Plan atom
The build plan for a project. It lists the ordered work, components, approvals, dependencies, and verification steps before the agent builds.
Change log
A record inside an atom or product history that says who changed what, when, and why. It helps explain configuration changes that do not live in source code.
Board
A visual work area for tasks and cards, usually grouped by status such as To do, In progress, In review, and Done.
Card
A single task, decision, approval, issue, feature, customer item, booking item, or piece of work on a board.
Task
A concrete action that should be done by Atom9, a user, an agent, or a customer team member.
Work board
The board attached to a project so tasks, approvals, agent work, review items, and launch work can be managed in one place.
Workflow
A sequence of steps that moves work or data from start to finish, such as booking a table, onboarding a customer, approving a launch, or sending a reminder.
Flow
A configured workflow path. A flow can react to a form, schedule, approval, project state, external event, or customer-app action.
Automation
A rule or process that performs a repeated action, such as sending an email, creating a task, moving a card, or notifying a user.
Scheduler
A timed workflow tool that can create reminders, booking slots, delayed actions, recurring jobs, or scheduled notifications.
Booking flow
A workflow where a person selects a time, enters required details, receives confirmation, and creates a booking record for a service such as a restaurant, clinic, or meeting.
Form
A set of fields used to collect information. Forms should ask for only the data needed and should show required privacy, consent, or service notices.
Content page
A website or app page managed through Atom9's content tools.
Template
A reusable structure for a page, form, workflow, board, or customer-app pattern. Templates should be easy for the agent to adapt safely.
Change pack
A grouped set of related changes, usually tied to a milestone, build phase, fix, or customer-approved update.
Notification
A visible or sent message that tells a user something needs attention, such as an approval, failed job, security issue, new task, or agent question.
Launch check
A review before something goes live, covering privacy, cookies, AI, accessibility, security, content, workflows, provider settings, and customer responsibilities.
Safety check
A review that asks whether a project, workflow, data request, AI output, or connected tool introduces avoidable harm, legal risk, or security risk.
Public ID
A stable external identifier that frontend users and integrations can safely see. It is different from internal database IDs.
Internal ID
A backend identifier used by the system. Atom9 avoids exposing internal IDs in frontend views when a public ID is available.
Public vs internal ID
Public IDs are safe references for UI, links, support, and integrations. Internal IDs are implementation details and should stay behind the product boundary.
Package
A reusable bundle of pages, settings, boards, workflows, content, or compliance setup that helps the agent build common project types faster.
Waste bin
A recovery area for soft-deleted items. It should help users restore mistakes without exposing destructive permanent-delete controls too early.
Developer terms

Public integration concepts for login, APIs, callbacks, files, and connected apps.

API
An application programming interface. It lets one system talk to another in a controlled way.
SDK
A software development kit. It gives developers ready-made helpers for using Atom9 features such as hosted login, session checks, or customer-app integration.
Webhook
A message sent from one system to another when something happens, such as a login, invite, payment, consent, project event, or security change.
Callback URL
The URL a login provider sends the user back to after sign-in, consent, or verification. Callback URLs must be approved before production use.
Redirect URI
The standards term often used by OAuth and OIDC providers for a callback URL.
Integration
A connection between Atom9 and another system, such as email, payments, analytics, search, files, CRM, AI models, or an external customer service.
Connected app
An external app or provider connected to a workspace. It should have clear purpose, limited permissions, owner, and removal path.
Provider account
The account with an external provider that Atom9 uses for a configured service, such as email, identity, AI, payment, file storage, or search.
Service provider
An external organisation or system used to provide part of Atom9 or a customer app, such as hosting, email, files, identity, AI, search, analytics, support, or payment processing.
Configured service
The specific product setup chosen for a workspace or customer app, including enabled features, providers, roles, regions, notices, data fields, and workflows.
Product flow
The visible sequence a user follows in Atom9 or a customer app, such as account creation, login, onboarding, approval, booking, checkout, export, or support.
Sync job
A repeated or one-time process that imports, updates, or reconciles data between Atom9 and another system.
External object
A record that belongs to another system but is referenced or mirrored in Atom9, such as a payment, provider user, calendar event, file, issue, or message.
Mapping
The rule that connects fields, IDs, statuses, or categories between Atom9 and another system.
Presigned URL
A temporary URL that allows upload or download of a file without giving broad storage access.
Object key
The storage path-like name of a file object inside file storage. Product permissions decide who may use it.
Bucket
A storage container used by S3-compatible file storage. Product software can still present friendly areas such as "My files" or "Company shared" on top of it.
Email delivery
The process of sending account, magic link, invite, notification, support, or customer-app emails through an approved mail provider.
SMTP
A standard protocol for sending email. Atom9 can use an SMTP provider to deliver account and product messages.
JWT
JSON Web Token. A signed token format often used to pass claims between a login system and an app. JWTs must be scoped, time-limited, and verified by the receiving app.
Claim
A piece of identity information sent to an app, such as subject ID, email, email verification status, name, role, or workspace access.
Post-login URL
The destination a user is sent to after successful login, account creation, or customer-app onboarding.
Operations and storage

Files, backups, monitoring, provider boundaries, resilience, support, and service scope.

Data residency
Keeping data in a specific country or region, such as the EU, according to customer, legal, or operational requirements.
Digital sovereignty
The ability to control where systems run, who operates them, what laws apply, which providers are used, and who can access data and infrastructure.
Operational autonomy
The ability to run, secure, support, and recover a system without relying on uncontrolled external operations.
Confidentiality
Keeping data, credentials, and operational information available only to people, systems, and providers with an approved need to access it.
Integrity
Keeping data, records, workflows, and configuration accurate, complete, and protected against unauthorised or accidental change.
Availability
The ability of a service, feature, or workflow to be reachable and usable when expected.
Service availability
Availability for the Atom9 service or a customer app, including whether users can log in, complete workflows, access data, and receive required messages.
Private operational route
An internal or operational path used by Atom9 to run the platform. It is not a supported integration path and should not be exposed or relied on by users.
File storage
A controlled place for uploaded documents, images, generated files, exports, media, and customer-app assets.
My files
A user-facing file area for a person's own uploaded or generated files, enforced by product permissions and workspace rules.
Company shared files
A workspace file area shared with permitted team members. It should be separated by workspace and controlled through roles and permissions.
Backup
A protected copy of data used for recovery after mistakes, outages, corruption, or incidents.
Restore
Recovering data, files, settings, or service state from a backup, waste bin, version history, or other recovery path.
Monitoring
Observing service health, errors, performance, security signals, provider failures, queues, and important operational events.
Uptime
The amount of time a service is available and operating as expected.
Service level
A defined support, uptime, response, or operational commitment, usually set in a paid agreement.
Subscription
The commercial plan or agreement that controls paid access, limits, support, billing, and service scope.
Billing reference
Information used to connect workspace usage or commercial agreements to invoices, plans, payments, or customer records.
Customer agreement
A signed or accepted agreement between Atom9 and a customer that can define service scope, responsibilities, billing, support, security, data processing, or special terms.
Order form
A customer-specific commercial document that defines purchased services, plan, scope, price, term, limits, or special service details.
Security addendum
A customer-specific security document that can define stronger controls, support expectations, reporting, evidence, testing, or operational commitments.
Signed document
A document accepted or signed by the relevant parties. Signed customer documents can override public pages when they are stricter or more specific.
Production customer
A customer using Atom9 or a customer app for real users or live operations, not only demos, internal tests, or temporary experiments.
Support channel
The approved way to ask for help, report an issue, request a data action, or raise a security concern.
Export
A produced copy of selected data or records for a user, customer, audit, rights request, migration, or operational handoff.
Incident response
The process for detecting, triaging, containing, investigating, fixing, documenting, and communicating a security, privacy, AI, or availability incident.
Provider boundary
The line between what Atom9 controls directly and what an external provider controls. Good provider boundaries make responsibilities, access, location, and security duties clear.
Data export
An export focused on data records, often for GDPR rights, customer migration, audit, compliance review, or backup-like handoff.
Deletion request
A user, customer, or legal request to delete data. Atom9 must verify authority, identify the correct data, apply retention exceptions, and preserve required evidence.