Console Operations Manual

Last updated: June 8, 2026

Numbering follows a multi-level scheme (1 / 1.1 / 1.1.1 …). Cross-references are written as "see X.X.X". UI labels are reproduced exactly as they appear in the console. Click a section heading to expand it.

0 Sign up

0.1 Sign-up page

From the top page of the VATES website (https://vates.standout.jp/), press Sign up in the header to go to the sign-up page (https://console.vates.standout.jp/signup).

0.2 Terms and Privacy Policy

By creating an account, you confirm that you are using the Service for business purposes and that you are authorized to bind the entity you represent. You agree to our Terms and Privacy Policy. Review the Terms (https://vates.standout.jp/legal/terms.html) and Privacy Policy (https://vates.standout.jp/legal/privacy.html) linked at the bottom of the sign-up page, then proceed to account creation.

0.3 Email submission and verification link

Enter the email address you want to register on the sign-up page and press the send button. A welcome email will arrive from VATES (sent from [email protected]). The link expires in 24 hours, and if you do not intend to create an account, the email can be safely ignored.

0.4 Setup

All fields are required.

  • 0.4.1 account ID:The email address used to create the account. It becomes your login ID for all subsequent sign-ins.
  • 0.4.2 workspace ID:A unique ID for each client. It is not the login ID. Once created it cannot be changed, and an ID already in use cannot be chosen. A name related to your company or business name is recommended, but the choice is free. If the entry cannot be registered, an error is shown; if it can be registered, "available" is shown.
  • 0.4.3 Password:At least 8 characters, with at least one lowercase letter, one uppercase letter, and one digit. Weak patterns are also rejected. Symbols are optional.
  • 0.4.4 Confirm Password:Enter the password once more for confirmation.
  • 0.4.5 Continue to payment
  • 0.4.6 Initial deposit:The initial deposit for a new account is a flat 5.00 USD. Pressing Continue to payment takes you to the Stripe screen, where the tax for your country/region is calculated automatically.

0.5 Payment

Pay on the Stripe screen (credit card). The card types and tax rate are reflected automatically by Stripe according to each country/region. After payment, you are taken to the console.

0.6 If you are not taken to the console after payment

A message stating that payment is complete is shown, and our email address is presented ([email protected]). Please notify us of your situation there. After we confirm the payment, we will take appropriate action so that you can log in to the console.

0.7 Payment methods other than credit card

As a rule, the initial account creation uses credit card payment. Enterprises and other corporations wishing to pay by bank transfer should contact [email protected].

1 Login

1.1 Three login methods

There are three login methods: ID/password, passkey, and 2FA.

1.1.1 ID and password rules

  • 1.1.1.1 Client admin:Created at sign-up. The ID is the registered email address, and the password is chosen by the user. The password must be at least 8 characters, with at least one lowercase letter, one uppercase letter, and one digit. Weak patterns are also rejected. Symbols are optional.
  • 1.1.1.2 Other accounts:Delegated admin, instance admin, and instance user accounts are granted by the client admin through Client settings, with permissions managed there. The ID is auto-numbered (in the form {client_id}_0001), and the password is issued by the client admin.
  • 1.1.2 Passkey:Created per account. The highest security level, and recommended.
  • 1.1.3 2FA:Created per account. A second-step verification at login. Security is high — second only to passkeys — but it is unnecessary if a passkey is already in place.

1.2 When you forget your password

  • 1.2.1 Client admin:From Forgot password? on the login screen, proceed to Reset password, and instructions to reset the password are sent to the registered email.
  • 1.2.2 Other accounts:Delegated admin, instance admin, and user accounts are granted by the client admin through Client settings, with permissions managed there. Therefore, please ask your client admin.

1.3 Password reset

The client admin, and delegated admin accounts that have been granted the operate permission, can perform the password reset in the Accounts tab of Client settings.

2 Sidebar / Account menu

2.1 Sidebar

Opened and closed via the hamburger menu. When closed, a reduced version remains on the left on desktop, and on mobile it is stowed into the hamburger. It consists of the hamburger menu, instances, and the account menu.

2.2 Account avatar and account name

The account avatar reflects the initial of the account name. Pressing the avatar opens and closes the user popover.

2.3 User popover

It consists of Client settings, My Security, console theme, and Sign out.

  • 2.3.1 Client settings:Various client settings can be configured. See 4 (Client settings).
  • 2.3.2 My Security:Passkeys and 2FA can be created, deleted, and managed. From + Add passkey and Set up two-factor, registration can be done by various methods using each device, browser, etc.
  • 2.3.3 Console theme:The day/night mode can be selected.
    • Auto:Switches automatically following the OS.
    • Light:Day mode.
    • Samhain:Night mode.
  • 2.3.4 Sign out:Signs out and returns you to the login screen.

3 Instances

3.1.1 vates

A place to test the responses of the instance you have actually built and configured.

3.1.2 bard

A place to generate ES (EchoScript) from natural language, photos, documents, and the like.

  • 3.1.2.1 Source:A source/origin name can be recorded on an ES. This makes it easier to keep track when viewing and managing ES in druid.
  • 3.1.2.2 Enter natural language text:Natural language can be written directly.
  • 3.1.2.3 File attachment:Images and PDFs can be attached.
  • 3.1.2.4 Sing as EchoScript:bard converts the natural language and attached files into ES.

3.1.3 druid

A place to manage the ES generated by bard. Viewing, searching, checking the original text, editing, and deleting are possible.

  • 3.1.3.1 Ask the Druid:For searching, you can ask the Druid with flexible questions (e.g., "list the ES related to XX").
  • 3.1.3.2 Search ESs:ES search by keyword.
  • 3.1.3.3 Show deleted:Can present ES including those that have been logically deleted.
  • 3.1.3.4 View:Selection of the display format.
    • Detail:Lists every ES in full.
    • List:Lists in an accordion format summarized to one line each.
    • Tile:Lists in a card format.
    • Overview:The display format that gives the broadest overview of the largest number.
  • 3.1.3.5 Show:The number displayed at once can be selected.
  • 3.1.3.6 ES:ES = EchoScript.
    • Raw:The original text from which the ES was derived can be viewed.
    • Edit:The ES can be amended and revised.
    • Delete:The ES can be logically deleted.
    • Left-column items:(a) Greek letters α–κ: the basic categories for observing the state of a phenomenon. Not editable. (b) Other items: custom categories outside the basic categories. Editable.

3.1.4 logs

A place to manage conversation logs. Viewing, searching, analyzing, CSV extraction, and deleting are possible.

  • 3.1.4.1 Log retention:The retention policy for logs. Configuration is done in Client settings. For details, see 4.1.1.3 (Log retention).
    • Standard (30 days):Retains logs for 30 days.
    • Zero retention:Does not retain logs.
  • 3.1.4.2 Export CSV:Logs can be exported as CSV.
  • 3.1.4.3 Search keywords:Logs can be searched by keyword.
  • 3.1.4.4 Ask the Druid:Flexible search and analysis requests on logs can be made to the Druid (e.g., "extract conversations related to XX and analyze the trend").
  • 3.1.4.5 Logs:
    • Log detail:Conversation logs can be viewed.
    • Trace ES references:From a conversation log, traces back which ES were referenced and shows them.

3.1.5 settings

Settings for any instance can be configured.

  • 3.1.5.1 Company name:The name of the organization the instance belongs to.
  • 3.1.5.2 Role:The job title of the instance.
  • 3.1.5.3 App name:The name to be reflected when adding to the home screen on a mobile device.
  • 3.1.5.4 Header title:Reflected in the header title pill of the chat UI.
  • 3.1.5.5 Custom prompt:The prompt for adapting the instance to its role.
  • 3.1.5.6 Welcome message:Reflected in the assistant bubble placed initially in the chat UI.
  • 3.1.5.7 Suggested prompts:Reflected in the suggestions of the chat UI. To separate suggestions, enter them on separate lines.
  • 3.1.5.8 Widget label:Reflected in the text placed beneath the widget button. If left blank, there is no label.
  • 3.1.5.9 Widget initial position:The initial position of the widget can be selected in the UI. It can also be adjusted in pixels along the Offset X and Y axes from each anchor point.
  • 3.1.5.10 Bubble font:The font for the user and assistant bubbles and the suggestions in the chat UI can be selected.
    • Serif:Serif typeface.
    • Sans:Sans-serif typeface.
    • Poetic:Garamond.
  • 3.1.5.11 Bubble font size:The font size for the user and assistant bubbles and the suggestions in the chat UI can be selected.
    • Small:Small size. Prioritizes the visual scene.
    • Medium:Medium size. A balance between legibility and the visual scene.
    • Large:Large size. Prioritizes legibility.
  • 3.1.5.12 Display mode:Selection of the day/night mode.
    • Auto (follow OS):Switching by automatic OS detection.
    • Light:Day mode.
    • Samhain:Night mode.
  • 3.1.5.13 Light theme color:The theme color of the widget can be chosen.
  • 3.1.5.14 Standalone background (Light):
    • Color specification:Can be specified in hexadecimal.
    • Ask the Druid:You can ask the Druid for a color and its hex value. In this case, the Druid proposes three options accompanied by poetic Japanese names.
  • 3.1.5.15 Standalone background (Samhain):
    • Color specification:Can be specified in hexadecimal.
    • Ask the Druid:You can ask the Druid for a color and its hex value. In this case, the Druid proposes three options accompanied by poetic Japanese names.
  • 3.1.5.16 Input placeholder:The placeholder inside the input pill of the chat UI can be entered.
  • 3.1.5.17 Recording text:The placeholder shown inside the input pill of the chat UI while listening to voice can be entered.
  • 3.1.5.18 Embed allowlist:The allowlist of URLs where the embedded widget may be embedded.
  • 3.1.5.19 Instance URL:
    • Standalone:The standalone URL.
    • Embed code:The embed code for the embedded widget. This code can be embedded into the target web page (in the footer, etc.).

3.1.6 security

The current status can be grasped in each panel. The color on the left also indicates the health status (green: good, amber: caution, crimson: warning).

  • 3.1.6.1 Audit Log:The audit log viewing function. For details, see 4.3.4 (Audit Log).
  • 3.1.6.2 My Sessions:The sessions currently logged in can be checked. They can be closed with Revoke. For details, see 4.3.5 (Active Sessions).
  • 3.1.6.3 THREATS:A panel that displays the detection results of unauthorized access attempts.
  • 3.1.6.4 Login History:The history of login activity. For details, see 4.3.8 (Login Activity).

3.2 Instructor for vates

An instructor prepared by the developer. An instance residing permanently on the console screen. Always available for questions. The tokens used are deducted from the deposit balance.

4 Client settings

4.1 Instances

A place to create, manage, and delete instances.

  • 4.1.1 Instances:
    • Display name:The instance name.
    • Immutable ID:The unique ID.
    • Log retention:The retention period of conversation logs can be selected. (30 days: Retained for 30 days, then automatically physically deleted. / Zero retention: A setting that does not retain conversation logs at all.)
    • Status:Indicates the status of the instance.
    • Actions:Edit = The Display name of the instance can be edited. Delete = The instance can be logically deleted.
  • 4.1.2 Show deleted:Can list instances including those that have been logically deleted.
  • 4.1.3 Create new instance:An instance can be created.

4.2 Accounts

Accounts can be created. Three types of accounts can be created: instance admin, delegated admin, and instance user.

4.2.1.1 Create new account
With the client admin as the parent, three types of child accounts can be created, customizing the functions required.

  • 4.2.1.1.1 Display name:Enter the account name.
  • 4.2.1.1.2 Role:As a child account of the client admin (the parent account), one of the following three types can be chosen.
    • (a) instance_admin:an account to which instance management permission can be granted.
    • (b) delegated_admin:an account to which permission regarding Client settings can be granted.
    • (c) instance_user:an account to which standalone usage permission can be granted.
  • 4.2.1.1.3 Delegated tabs:Permission can be granted to a delegated_admin. Console login permission, and view or operate permission for each item of Client settings, can be selectively granted.
  • 4.2.1.1.4 Manageable instances:Permission can be granted to a delegated admin and an instance admin. Console login permission and instance setting permission can be granted.
  • 4.2.1.1.5 Usable instances:Permission can be granted to all three types of accounts, including the instance user. Login permission to the standalone can be granted. It does not carry console login permission.
  • 4.2.1.2 Create account:Pressing the Create account button creates the account and presents the ID and password. This password is shown only once, so it must be recorded at that time. If it is lost, Reset password is required to reset and reissue the password.

4.2.2 Registered accounts
All accounts from the client admin down are listed.

  • Edit access:Only Usable instances (standalone login permission) can be edited. Management permissions cannot be modified (not implemented, for reasons of permission entanglement and security).
  • Reset password:Resets the password and displays a new one. This password is shown only once, so it must be recorded at that time.
  • Delete:A child account can be deleted. When deleted, that account is immediately logged out and logically deleted. After 30 days from logical deletion, it is physically deleted.
  • Show deleted:Displays accounts including those that have been logically deleted. Those that have been physically deleted are never shown again.
  • Restore:A logically deleted account can be restored. Those that have been physically deleted can never be restored.

4.3 Security

  • 4.3.1 Security Overview:The various security statuses can be grasped in panels.
  • 4.3.2 Passkeys:Passkeys can be created, deleted, and managed. Registration can be done by various methods using each device, browser, etc. The most recommended login method in terms of security.
  • 4.3.3 Two-Factor Authentication:2FA can be created, deleted, and managed. However, when a passkey is used, it is unnecessary for security purposes.
  • 4.3.4 Audit Log:The audit log. Viewing, searching, and CSV export of the audit log are possible. It is also an audit log given tamper resistance by a hash chain, with the hash recorded alongside in the CSV, making auditing easy. The audit log has 10 categories.
    • 4.3.4.1 CATEGORY:
      • Authentication:Records authentication-related events such as login success/failure, logout, session expiry, country mismatch, and out-of-range login. You can trace "who attempted to log in and when, and whether it succeeded or failed" and "when a session expired".
      • Authorization:Records events where an operation or resource access without permission was denied. Attempts to access settings that should not be touched or another tenant's data remain here. The line that detects signs of unauthorized access.
      • Customer:Records state transitions of the customer account itself: creation, suspension, resumption, logical deletion, restoration, self-withdrawal, and so on. Normally operations by the operator side (saas_admin) are the main ones, but self-withdrawal originates from the customer.
      • Instance:Records instance creation, rename, deletion, and restoration. You can trace which instance was created, deleted, and restored, by whom and when.
      • User:Records operations at the user level: account creation/deletion/restoration, password reissue, passkey registration/deletion, enabling/disabling 2FA (TOTP), sign-up procedures, and so on. The central line of account management.
      • API key:Records the issuance, disabling, and deletion of API keys. You can trace when and by whom a key for programmatic access was issued and stopped.
      • Balance:Records events related to balance and billing: deposits, refunds, adjustments, status changes, monthly-limit changes, auto-recharge setting changes, display-currency changes, SLA credit grants, and so on.
      • Settings:Records various setting changes: usage-limit presets, log retention period, IP restrictions, anomaly-detection thresholds, FX rate, notification settings, and so on. You can trace "who changed what setting and how, and when".
      • Logs:Records operations on the logs themselves: bulk deletion of conversation logs, CSV export, and audit-log export. The line that audits the carrying-out and erasure of logs.
      • System:Records events the system executes automatically: backups, the anomaly-detection batch, the deletion batch, physical deletion, pseudonymization, payment webhook reception, email delivery/suppression, and so on. Records of equipment acting autonomously rather than people, kept independently of customer operations.
    • 4.3.4.2 EVENT TYPE:Narrowing by event type. Whereas CATEGORY is the broad classification, this narrows by the individual event name (e.g., AUTH_LOGIN_SUCCESS, SETTINGS_UPDATED). Partial-match search is possible.
    • 4.3.4.3 ACTOR:Narrowing by the actor. Searches by "who" caused the event. Recorded in the form of role and user name (e.g., client_admin:standout), and partial-match search is possible.
    • 4.3.4.4 FROM (ISO):The start of the search period. Specified in ISO format (YYYY-MM-DD); events on or after that date/time are targeted.
    • 4.3.4.5 TO (ISO):The end of the search period. Specified in ISO format (YYYY-MM-DD); events on or before that date/time are targeted. Combined with FROM to cut out any period.
    • 4.3.4.6 ROWS PER PAGE:The number of rows displayed on one screen. The on-screen display targets a narrowed result of up to 1,000 entries. To obtain all entries, use the CSV export (Export All).
  • 4.3.5 Active Sessions:Lists the live login sessions of the account. They time out and expire automatically 30 days after the last access. Even before the timeout, they can be expired individually via Revoke.
  • 4.3.6 GEOIP:Records the country/region of the login origin. Detects access from a location different from the most recent login country. Presents the status of the last 24 hours in a panel.
  • 4.3.7 IP Restrictions:A place for settings related to IP restriction. The default is no restriction. When checked, an allowlist and a denylist can be created. Each list can specify ranges in CIDR notation. If the allowlist is left empty, all IPs other than those in the denylist are allowed. Also, the denylist takes precedence over the allowlist.
  • 4.3.8 Login Activity:The login history. The most recent 100 entries are shown. In the panel, the number of login successes and failures in the last 24 hours is shown.
  • 4.3.9 Notifications:A place for adjusting and configuring automatic email notifications.
    • Low balance:A notification setting for when the deposit balance falls below a threshold. The threshold changes across three sensitivity levels. High ($500, notify early) / Medium ($50, standard) / Low ($5, notify at the last moment). To set a different threshold, enter a Custom value.
    • Sign-in from new location:A notification for when a sign-in occurs from a country/region not usually used.
    • Blocked by IP restriction:A notification for when access is denied by the configured IP restriction. High (1 or more/h), Medium (10 or more/h), Low (50 or more/h). To set an arbitrary count, enter it in Custom.
    • Repeated sign-in failures:A notification for when sign-in failures occur intensively in a short time. High (3 or more/h), Medium (10 or more/h), Low (30 or more/h). To set an arbitrary count, enter it in Custom.
    • Recipients — where alerts are sent:Registration and deletion of the contacts to which notifications are sent automatically by email. By default, the registered email address of the client account is set. When the notification destination is changed, the previous contact is also notified that a change has occurred (for security).

4.4 API Keys

Issued keys for calling VATES from an external program or an AI agent. Not needed for ordinary browser use.

  • 4.4.1 API keys:Select the instance for which you want to issue an API Key, and create it. The API key is shown only once, so it must be recorded at that time.
  • 4.4.2 Issued keys:The issued API Keys are shown. The API key can also be disabled and deleted.
  • 4.4.3 Connecting from an AI agent (MCP):VATES can be connected to external AI agents as an MCP (Model Context Protocol) server. A connected agent can ask questions against the instance you authorize and receive answers grounded in that instance's material. It cannot change settings, read conversation logs, or reach other instances. There are two ways to connect.
    • 4.4.3.1 Connector (recommended):In your AI agent, add https://vates.standout.jp/mcp as a custom connector. A browser window opens on the VATES sign-in screen; sign in as usual (password, passkey, or two-factor all work), then choose the instance to connect on the authorization screen and allow access. No API key is needed. You can revoke this access at any time from Client settings → Security → Active sessions (see 4.3.5).
    • 4.4.3.2 API key:For editors and other clients without a connector feature. Use https://vates.standout.jp/mcp/{workspace ID}/{immutable instance ID} as the endpoint and authenticate with an Authorization: Bearer {API key} header. The immutable ID appears in the Immutable ID column of the Issued keys table in 4.4.2 (in the form inst_0001 — note that this is not the display name).
    • 4.4.3.3 Available tools:One tool is currently provided: vates_ask, which queries the knowledge base. It is read-only and never modifies data in VATES.
    • 4.4.3.4 Billing and limits:Usage through MCP is metered exactly like normal chat and appears in the Usage breakdown. The limits configured under Controls (4.6) apply in the same way.

4.5 Embed allowlist

The allowlist of URLs (the non-standalone ones) where each instance's embedded widget may be embedded. These are linked to the same item on each instance's own settings screen.

4.6 Controls

4.6.1 Controls
The main aim of these limits is to protect ordinary use from the waste of resources and cost caused by runaway loops and excessive/massive requests — specifically, to deter infinite loops of a maliciously operated AI agent, and balance exhaustion (DoW) and service disruption (DoS) caused by excessive requests. They also include adjustment items related to performance and cost (the response-token cap, the number of ES references, and so on). Adjust each instance to suit its purpose.

4.6.2 Default for new instances
The default values at instance creation can be selected or customized. Basic, Business, and Developer are presets pre-tuned for their purposes; if fine adjustment is required, it can be done with Custom.

  • Basic:For general use.
  • Business:For business use.
  • Developer:For developer use.
  • Custom:Custom.
  • Apply to all existing instances:The selected default values can be applied to all instances.

4.6.3 Per-instance settings
A preset can be selected or customized per instance.

  • Current status:Indicates the current status.
  • Customize:Each item can be adjusted with a slider (a value of 0 means ∞ = unlimited). These limits constitute a defense against Denial of Wallet (a cost attack that exhausts the balance) and Denial of Service (service disruption), both specific to usage-based AI (in line with OWASP GenAI Top 10 "Unbounded Consumption").
  • 4.6.3.2.1 Query length per request:The cap on the number of query characters per request. Suppresses cost inflation from excessive input. Excess is rejected.
  • 4.6.3.2.2 Image size:The cap on image upload size. Suppresses resource exhaustion from huge files. Excess is rejected.
  • 4.6.3.2.3 PDF size:The cap on PDF upload size. Same as above. Excess is rejected.
  • 4.6.3.2.4 Audio size:The cap on audio upload size. Same as above. Excess is rejected.
  • 4.6.3.2.5 Bard text length:The cap on the number of characters bard compresses (natural language → ES) at one time. Defines the cost per compression. Excess is rejected.
  • 4.6.3.2.6 Conversation history (chars):The cap on the total number of characters of conversation history loaded into context. Suppresses cost and latency from unbounded context growth. The excess is automatically trimmed from the oldest history (it does not become an error).
  • 4.6.3.2.7 Conversation history (turns):The cap on the number of turns of conversation history loaded into context. Behaves the same as 4.6.3.2.6 (keeps the latest turns and auto-trims).
  • 4.6.3.2.8 Requests per minute:The cap on the number of requests per minute. A first line of defense against request floods (DoS) and automation abuse (DoW). Excess is temporarily rejected.
  • 4.6.3.2.9 Requests per hour:The cap on the number of requests per hour. Behaves the same as 4.6.3.2.8.
  • 4.6.3.2.10 Concurrent sessions:The cap on the number of simultaneous conversation sessions. Suppresses resource exhaustion from parallel request floods. Excess is rejected.
  • 4.6.3.2.11 Max tokens per response:The cap on the output tokens of a single response. Suppresses output-cost inflation from excessive responses.
  • 4.6.3.2.12 Max ES references (top_k):The maximum number of ES that vates references when responding. This is not an attack defense but a tuning of accuracy and cost: the more references, the higher the accuracy, but the cost increases proportionally. Minimum 20.

4.7 Usage breakdown

The monthly usage charges (USD) can be viewed.

  • 4.7.1 Usage breakdown:The year and month can be specified from a dropdown.
  • 4.7.2 By instance:The usage breakdown per instance.
    • Instance:The instance name.
    • Conversations:The total number of conversations.
    • Chat:The charge for conversations with vates.
    • Bard:The bard usage charge.
    • Druid:The druid usage charge.
    • Fallback:The fallback usage charge for chat. * The backup API (OpenAI) used when the main vates API (Anthropic) is not working.
    • STT:Speech reading (Speech-to-Text, voice → text conversion).
    • TTS:Speech reading-aloud (Text-to-Speech, text → voice synthesis).
    • Total:The total amount.
    • Include instances with 0 conversations:Show/hide instances unused in that month.

4.8 Balance

The deposit balance and its change history can be checked, and payment and payment settings can be configured.

  • 4.8.1 Balance:The current deposit balance.
  • 4.8.2 Top Up Balance:
    • Card:Credit card payment. Powered by Stripe. Card types are displayed automatically according to country/region. At payment, you are taken to the Stripe screen. The amount on the modal indicates the amount that will be reflected in the deposit balance; after you are taken to Stripe, the tax for each country/region is added.
    • International Transfer:Account payment by currency.
    • Domestic Transfer:Account payment by country/region. The amount reflected in the deposit balance is the transfer amount with the tax for each country/region deducted.
  • 4.8.3 Auto Recharge:
    • Auto Recharge:Can be set so that automatic payment (credit card) occurs when the deposit balance falls below a threshold. The default is OFF.
    • Adjust:The threshold, the auto-recharge amount, and the monthly limit amount can be set.
  • 4.8.4 Transactions:The transaction history can be viewed.

4.9 Data lifecycle

4.9.1 Data lifecycle
VATES selects data retention periods by referring to the strictest standard among the regulations of every jurisdiction where your data may be relevant (EU, UK, Japan, California, China, Brazil, Korea, Singapore, Canada, Australia, etc.). Your data is governed by the most protective baseline regardless of your location.

4.9.2 Current status
Indicates the current status of the client account.

4.9.3 State transitions
The list of states the account passes through. The starting point and dwell period of each state are as follows.

  • active:Active. The service is available.
  • suspended:Suspended. The service is paused but can be resumed. Data is retained.
  • logical_deleted:The moment of the deletion request. From this day as the starting point, restoration is possible for 30 days, and data is fully retained. After 30 days, it automatically moves to the pseudonymization phase.
  • pseudonymized:The state 30 days after the deletion request. Information that can identify an individual (user name, display name, etc.) is replaced with an irreversible hash and becomes unrecoverable. From this point on, it remains until each data category's retention period expires.
  • physical_deleted:At the expiry of each data category's retention period. Erased completely from disk, with no possibility of recovery.

4.9.4 Data categories and retention (17)
The data categories and retention periods related to the account. All retention periods take the deletion request (entry into logical_deleted) as their starting point. The exact value for each category is shown in the Retention column on screen.

  • customer_state:The overall state of the customer account (active/suspended, etc.). Pseudonymized 30 days after the deletion request; physical deletion shares the same file as the balance (customer_balance), so it is deleted together at the expiry of the balance's legal retention period (10 years).
  • instance_state:The state per instance. Pseudonymized 30 days after the deletion request (display name only; the unique ID inst_NNNN is retained as an immutable ID), then physically deleted 90 days later.
  • users_with_pii:User account information (including personal information such as ID, display name, and credentials). Pseudonymized 30 days after the deletion request, then physically deleted 90 days later.
  • user_instance_access:The link between a user and usable instances. Deleted together with the account at deletion (no independent retention period).
  • api_keys:Issued API keys (stored as an irreversible hash; the plaintext is not retained). Physically deleted 90 days after the deletion request (no pseudonymization).
  • revoked_sessions:Revoked sessions. An existing batch physically deletes them 90 days after revocation.
  • session_logs:Conversation history. The retention period depends on the customer's plan choice (Standard = 30 days / Secure = not retained at all = immediate deletion).
  • usage_records:The individual event log of usage. Pseudonymized 30 days after the deletion request, then physically deleted 90 days later.
  • usage_aggregates:The aggregated values of usage (the basis for billing). Subject to legal retention. Not pseudonymized; physically deleted 10 years after the last transaction (per Article 432 of the Japanese Companies Act). Cannot be brought forward even by a deletion request.
  • customer_balance:The customer's balance (the settled value of payment). Subject to legal retention. Physically deleted 10 years after the last transaction. Cannot be brought forward even by a deletion request.
  • balance_history:The change history of the balance. Subject to legal retention. The transaction amount, currency, and rate are retained for 10 years (only the operator name is pseudonymized 30 days after the deletion request). Cannot be brought forward even by a deletion request.
  • instance_audit_log:The instance's audit log (a tamper-resistant log). Pseudonymized 30 days after the deletion request, then physically deleted 2 years later. The lower bound of the audit requirements (SOC2 / PCI DSS) is 1 year, but because a shift in the timing of the annual audit means 1 year would miss logs in the audited period, twice that — 2 years — is adopted on the safe side.
  • ip_restrictions:IP restriction settings (Allowlist / Denylist). Physically deleted 30 days after the deletion request (no sensitive information, no pseudonymization needed).
  • e_core_knowledge:ES-IFM knowledge assets (your intellectual property). Physically deleted 30 days after the deletion request (no pseudonymization).
  • instance_settings:Instance settings (branding, limit values, prompts, etc.). Physically deleted 30 days after the deletion request (no sensitive information, no pseudonymization needed).
  • shell_settings:Shell settings (the central master reference setting). Physically deleted 30 days after the deletion request (no sensitive information).
  • client_settings:The client-wide default settings. Physically deleted 30 days after the deletion request (no sensitive information).

4.9.5 Delete account
Puts the account into a deletion-requested state (logical_deleted). Restoration is possible within 30 days of the starting point. After 30 days, data is progressively pseudonymized and physically deleted according to each retention period above. Data subject to legal retention (usage_aggregates, customer_balance, balance_history) is retained even after the deletion request until the legal period (10 years) has elapsed. This action affects all users under this account.

Questions about console operations: [email protected]