კონსოლის ექსპლუატაციის სახელმძღვანელო

VATES-ის ვებსაიტის მთავარი გვერდიდან (https://vates.standout.jp/ka/) დააჭირეთ ჰედერში Sign up-ს, რათა გადახვიდეთ რეგისტრაციის გვერდზე (https://console.vates.standout.jp/signup).

ანგარიშის შექმნით თქვენ ადასტურებთ, რომ სერვისს იყენებთ ბიზნეს მიზნებისთვის და გაქვთ უფლებამოსილება წარმოადგინოთ თქვენი ორგანიზაცია. თქვენ ეთანხმებით ჩვენს მომსახურების პირობებსა და კონფიდენციალურობის პოლიტიკას. გადახედეთ მომსახურების პირობებსა (https://vates.standout.jp/ka/legal/terms.html) და კონფიდენციალურობის პოლიტიკას (https://vates.standout.jp/ka/legal/privacy.html), რომლებიც მითითებულია რეგისტრაციის გვერდის ბოლოში, შემდეგ კი გააგრძელეთ ანგარიშის შექმნა.

შეიყვანეთ რეგისტრაციის გვერდზე ის ელფოსტის მისამართი, რომლის რეგისტრაციაც გსურთ, და დააჭირეთ გაგზავნის ღილაკს. VATES-დან მოვა მისასალმებელი ელფოსტა (იგზავნება [email protected]-დან). ბმული მოქმედებას შეწყვეტს 24 საათში და თუ ანგარიშის შექმნა არ გსურთ, ამ ელფოსტის უგულებელყოფა უსაფრთხოა.

ყველა ველი სავალდებულოა.

• 0.4.1　account ID：ანგარიშის შესაქმნელად გამოყენებული ელფოსტის მისამართი. ის ხდება თქვენი შესვლის ID ყველა შემდგომი შესვლისთვის.
• 0.4.2　workspace ID：თითოეული კლიენტის უნიკალური ID. ეს არ არის შესვლის ID. ერთხელ შექმნის შემდეგ ვერ შეიცვლება, ხოლო უკვე გამოყენებული ID ვერ აირჩევა. რეკომენდებულია თქვენი კომპანიის ან ბიზნესის სახელთან დაკავშირებული სახელი, თუმცა არჩევანი თავისუფალია. თუ ჩანაწერი ვერ რეგისტრირდება, ნაჩვენებია შეცდომა; თუ რეგისტრირდება, ნაჩვენებია „available“.
• 0.4.3　Password：მინიმუმ 8 სიმბოლო, სულ მცირე ერთი პატარა ასო, ერთი დიდი ასო და ერთი ციფრი. სუსტი შაბლონებიც უარყოფილია. სიმბოლოები არჩევითია.
• 0.4.4　Confirm Password：დასადასტურებლად კიდევ ერთხელ შეიყვანეთ პაროლი.
• 0.4.5　Continue to payment
• 0.4.6　Initial deposit：ახალი ანგარიშის საწყისი დეპოზიტი ფიქსირებული 5.00 USD-ია. Continue to payment-ზე დაჭერით გადახვალთ Stripe-ის ეკრანზე, სადაც თქვენი ქვეყნის/რეგიონის გადასახადი ავტომატურად ითვლება.

გადაიხადეთ Stripe-ის ეკრანზე (საკრედიტო ბარათით). ბარათის ტიპები და გადასახადის განაკვეთი ავტომატურად აისახება Stripe-ის მიერ თითოეული ქვეყნის/რეგიონის შესაბამისად. გადახდის შემდეგ გადახვალთ კონსოლზე.

ნაჩვენებია შეტყობინება, რომ გადახდა დასრულდა, და მოცემულია ჩვენი ელფოსტის მისამართი ([email protected]). გთხოვთ, იქ შეგვატყობინოთ თქვენი მდგომარეობა. გადახდის დადასტურების შემდეგ მივიღებთ შესაბამის ზომებს, რათა შეძლოთ კონსოლზე შესვლა.

როგორც წესი, ანგარიშის საწყისი შექმნა საკრედიტო ბარათით ხდება. საწარმოებმა და სხვა იურიდიულმა პირებმა, რომელთაც საბანკო გადარიცხვით გადახდა სურთ, უნდა დაუკავშირდნენ [email protected]-ს.

შესვლის სამი მეთოდია: ID/password, passkey და 2FA.

1.1.1　ID-ისა და password-ის წესები

• 1.1.1.1　Client admin：იქმნება რეგისტრაციისას. ID არის რეგისტრირებული ელფოსტის მისამართი, ხოლო პაროლს ირჩევს მომხმარებელი. პაროლი უნდა იყოს მინიმუმ 8 სიმბოლო, სულ მცირე ერთი პატარა ასო, ერთი დიდი ასო და ერთი ციფრი. სუსტი შაბლონებიც უარყოფილია. სიმბოლოები არჩევითია.
• 1.1.1.2　სხვა ანგარიშები：delegated admin, instance admin და instance user ანგარიშებს ანიჭებს client admin Client settings-ის გავლით, სადაც იმართება უფლებები. ID ავტომატურად ინომრება (ფორმით {client_id}_0001), ხოლო პაროლს გასცემს client admin.

• 1.1.2　Passkey：იქმნება თითო ანგარიშზე. უსაფრთხოების უმაღლესი დონე და რეკომენდებული.
• 1.1.3　2FA：იქმნება თითო ანგარიშზე. შესვლისას მეორე საფეხურის დადასტურება. უსაფრთხოება მაღალია — passkey-ის შემდეგ მეორე — მაგრამ ის ზედმეტია, თუ passkey უკვე გაქვთ.

• 1.2.1　Client admin：შესვლის ეკრანზე Forgot password?-დან გადადით Reset password-ზე და პაროლის აღსადგენი ინსტრუქცია გამოიგზავნება რეგისტრირებულ ელფოსტაზე.
• 1.2.2　სხვა ანგარიშები：delegated admin, instance admin და user ანგარიშებს ანიჭებს client admin Client settings-ის გავლით, სადაც იმართება უფლებები. ამიტომ, გთხოვთ, მიმართოთ თქვენს client admin-ს.

client admin-ს და delegated admin ანგარიშებს, რომელთაც მინიჭებული აქვთ operate უფლება, შეუძლიათ password reset-ის შესრულება Client settings-ის Accounts ჩანართში.

იხსნება და იხურება hamburger menu-ს მეშვეობით. დახურულ მდგომარეობაში, დესკტოპზე მარცხნივ რჩება შემცირებული ვერსია, ხოლო მობილურზე ის იკეცება hamburger-ში. შედგება hamburger menu-სგან, instance-ებისგან და account menu-სგან.

account avatar ასახავს account name-ის პირველ ასოს. avatar-ზე დაჭერა ხსნის და ხურავს user popover-ს.

შედგება Client settings-ისგან, My Security-ისგან, console theme-ისგან და Sign out-ისგან.

• 2.3.1　Client settings：კლიენტის სხვადასხვა პარამეტრის კონფიგურაცია შესაძლებელია. იხ. 4 (Client settings).
• 2.3.2　My Security：passkey-ებისა და 2FA-ის შექმნა, წაშლა და მართვა შესაძლებელია. + Add passkey-დან და Set up two-factor-დან რეგისტრაცია შესაძლებელია სხვადასხვა მეთოდით, თითოეული მოწყობილობის, ბრაუზერის და სხვ. გამოყენებით.
• 2.3.3　Console theme：დღის/ღამის რეჟიმის არჩევა შესაძლებელია.
  • Auto：გადაირთვება ავტომატურად, OS-ის მიხედვით.
  • Light：დღის რეჟიმი.
  • Samhain：ღამის რეჟიმი.
• 2.3.4　Sign out：გამოგიყვანთ სისტემიდან და დაგაბრუნებთ შესვლის ეკრანზე.

ადგილი, სადაც შეგიძლიათ ფაქტობრივად აშენებული და კონფიგურირებული instance-ის პასუხების ტესტირება.

ადგილი, სადაც ბუნებრივი ენიდან, ფოტოებიდან, დოკუმენტებიდან და მსგავსიდან იქმნება ES (EchoScript).

• 3.1.2.1　Source：ES-ზე შესაძლებელია წყაროს/წარმოშობის სახელის ჩაწერა. ეს აიოლებს თვალყურის დევნებას, როცა ES-ებს ათვალიერებთ და მართავთ druid-ში.
• 3.1.2.2　ბუნებრივ ენაზე ტექსტის შეყვანა：ბუნებრივი ენის პირდაპირ ჩაწერა შესაძლებელია.
• 3.1.2.3　ფაილის მიმაგრება：სურათებისა და PDF-ების მიმაგრება შესაძლებელია.
• 3.1.2.4　Sing as EchoScript：bard გარდაქმნის ბუნებრივ ენასა და მიმაგრებულ ფაილებს ES-ად.

ადგილი, სადაც იმართება bard-ის მიერ შექმნილი ES. შესაძლებელია ნახვა, ძიება, ორიგინალი ტექსტის შემოწმება, რედაქტირება და წაშლა.

• 3.1.3.1　Ask the Druid：ძიებისთვის შეგიძლიათ Druid-ს დაუსვათ მოქნილი შეკითხვები (მაგ., „ჩამოთვალე XX-თან დაკავშირებული ES“).
• 3.1.3.2　Search ESs：ES-ის ძიება საკვანძო სიტყვით.
• 3.1.3.3　Show deleted：შეუძლია ES-ების ჩვენება, მათ შორის ლოგიკურად წაშლილების.
• 3.1.3.4　View：ჩვენების ფორმატის არჩევა.
  • Detail：თითოეულ ES-ს ჩამოთვლის სრულად.
  • List：ჩამოთვლის აკორდეონის ფორმატით, თითოეული ერთ ხაზად შეჯამებული.
  • Tile：ჩამოთვლის ბარათის ფორმატით.
  • Overview：ჩვენების ფორმატი, რომელიც ყველაზე ფართო მიმოხილვას იძლევა უდიდესი რაოდენობისთვის.
• 3.1.3.5　Show：ერთდროულად ნაჩვენები რაოდენობის არჩევა შესაძლებელია.
• 3.1.3.6　ES：ES = EchoScript.
  • Raw：შესაძლებელია იმ ორიგინალი ტექსტის ნახვა, საიდანაც ES მიიღება.
  • Edit：ES-ის შესწორება და გადახედვა შესაძლებელია.
  • Delete：ES-ის ლოგიკურად წაშლა შესაძლებელია.
  • მარცხენა სვეტის ელემენტები：(a) ბერძნული ასოები α–κ: ფენომენის მდგომარეობის დასაკვირვებლი ბაზისური კატეგორიები. არ რედაქტირდება. (b) სხვა ელემენტები: ბაზისური კატეგორიების გარეთ მყოფი მორგებული კატეგორიები. რედაქტირდება.

ადგილი, სადაც იმართება საუბრის ლოგები. შესაძლებელია ნახვა, ძიება, ანალიზი, CSV-ად ამოღება და წაშლა.

• 3.1.4.1　Log retention：ლოგების შენახვის პოლიტიკა. კონფიგურაცია ხდება Client settings-ში. დეტალებისთვის იხ. 4.1.1.3 (Log retention).
  • Standard (30 days)：ინახავს ლოგებს 30 დღის განმავლობაში.
  • Zero retention：არ ინახავს ლოგებს.
• 3.1.4.2　Export CSV：ლოგების ექსპორტი CSV-ად შესაძლებელია.
• 3.1.4.3　Search keywords：ლოგების ძიება საკვანძო სიტყვით შესაძლებელია.
• 3.1.4.4　Ask the Druid：ლოგებზე მოქნილი ძიებისა და ანალიზის მოთხოვნები შესაძლებელია Druid-ს მიმართოთ (მაგ., „ამოიღე XX-თან დაკავშირებული საუბრები და გააანალიზე ტენდენცია“).
• 3.1.4.5　Logs：
  • Log detail：საუბრის ლოგების ნახვა შესაძლებელია.
  • Trace ES references：საუბრის ლოგიდან მიჰყვება უკან, რომელი ES იყო მითითებული, და აჩვენებს მათ.

ნებისმიერი instance-ის პარამეტრების კონფიგურაცია შესაძლებელია.

• 3.1.5.1　Company name：ორგანიზაციის სახელი, რომელსაც instance ეკუთვნის.
• 3.1.5.2　Role：instance-ის თანამდებობა.
• 3.1.5.3　App name：სახელი, რომელიც აისახება მობილურ მოწყობილობაზე მთავარ ეკრანზე დამატებისას.
• 3.1.5.4　Header title：აისახება chat UI-ის header title pill-ში.
• 3.1.5.5　Custom prompt：prompt, რომელიც instance-ს მის როლზე არგებს.
• 3.1.5.6　Welcome message：აისახება chat UI-ში თავდაპირველად განთავსებულ assistant bubble-ში.
• 3.1.5.7　Suggested prompts：აისახება chat UI-ის suggestions-ში. შემოთავაზებების გასაყოფად შეიყვანეთ ისინი ცალკეულ ხაზებზე.
• 3.1.5.8　Widget label：აისახება widget ღილაკის ქვემოთ განთავსებულ ტექსტში. თუ ცარიელია, ლეიბლი არ ჩანს.
• 3.1.5.9　Widget initial position：widget-ის საწყისი პოზიცია UI-ში აირჩევა. ასევე შესაძლებელია მისი მორგება პიქსელებში Offset X და Y ღერძების გასწვრივ თითოეული anchor წერტილიდან.
• 3.1.5.10　Bubble font：chat UI-ში user და assistant bubble-ებისა და suggestions-ის ფონტის არჩევა შესაძლებელია.
  • Serif：serif შრიფტი.
  • Sans：sans-serif შრიფტი.
  • Poetic：Garamond.
• 3.1.5.11　Bubble font size：chat UI-ში user და assistant bubble-ებისა და suggestions-ის ფონტის ზომის არჩევა შესაძლებელია.
  • Small：პატარა ზომა. პრიორიტეტს ანიჭებს ვიზუალურ სცენას.
  • Medium：საშუალო ზომა. ბალანსი წაკითხვადობასა და ვიზუალურ სცენას შორის.
  • Large：დიდი ზომა. პრიორიტეტს ანიჭებს წაკითხვადობას.
• 3.1.5.12　Display mode：დღის/ღამის რეჟიმის არჩევა.
  • Auto (follow OS)：გადართვა OS-ის ავტომატური ამოცნობით.
  • Light：დღის რეჟიმი.
  • Samhain：ღამის რეჟიმი.
• 3.1.5.13　Light theme color：widget-ის თემის ფერის არჩევა შესაძლებელია.
• 3.1.5.14　Standalone background (Light)：
  • ფერის მითითება：შესაძლებელია მითითება თექვსმეტობით (hex).
  • Ask the Druid：Druid-ს შეგიძლიათ ჰკითხოთ ფერი და მისი hex მნიშვნელობა. ამ შემთხვევაში Druid სთავაზობს სამ ვარიანტს პოეტური იაპონური სახელებით.
• 3.1.5.15　Standalone background (Samhain)：
  • ფერის მითითება：შესაძლებელია მითითება თექვსმეტობით (hex).
  • Ask the Druid：Druid-ს შეგიძლიათ ჰკითხოთ ფერი და მისი hex მნიშვნელობა. ამ შემთხვევაში Druid სთავაზობს სამ ვარიანტს პოეტური იაპონური სახელებით.
• 3.1.5.16　Input placeholder：chat UI-ის input pill-ის შიგნით placeholder-ის შეყვანა შესაძლებელია.
• 3.1.5.17　Recording text：placeholder, რომელიც ხმის მოსმენისას chat UI-ის input pill-ის შიგნით ჩანს, შესაძლებელია შეიყვანოთ.
• 3.1.5.18　Embed allowlist：იმ URL-ების allowlist, სადაც ჩაშენებული widget-ის ჩაშენებაა დაშვებული.
• 3.1.5.19　Instance URL：
  • Standalone：standalone URL.
  • Embed code：ჩაშენებული widget-ის embed code. ეს კოდი შესაძლებელია ჩაშენდეს სამიზნე ვებგვერდში (ფუტერში და სხვ.).

მიმდინარე სტატუსის აღქმა შესაძლებელია თითოეულ panel-ში. მარცხნივ ფერი ასევე მიუთითებს ჯანმრთელობის სტატუსს (green: კარგი, amber: გაფრთხილება, crimson: საფრთხე).

• 3.1.6.1　Audit Log：audit log-ის ნახვის ფუნქცია. დეტალებისთვის იხ. 4.3.4 (Audit Log).
• 3.1.6.2　My Sessions：ამჟამად შესული სესიების შემოწმება შესაძლებელია. მათი დახურვა შესაძლებელია Revoke-ით. დეტალებისთვის იხ. 4.3.5 (Active Sessions).
• 3.1.6.3　THREATS：panel, რომელიც აჩვენებს არასანქცირებული წვდომის მცდელობების აღმოჩენის შედეგებს.
• 3.1.6.4　Login History：შესვლის აქტივობის ისტორია. დეტალებისთვის იხ. 4.3.8 (Login Activity).

დეველოპერის მიერ მომზადებული instructor. instance, რომელიც მუდმივად მკვიდრობს კონსოლის ეკრანზე. ყოველთვის ხელმისაწვდომია შეკითხვებისთვის. გამოყენებული token-ები აკლდება დეპოზიტის ბალანსს.

ადგილი instance-ების შესაქმნელად, სამართავად და წასაშლელად.

• 4.1.1　Instances：
  • Display name：instance-ის სახელი.
  • Immutable ID：უნიკალური ID.
  • Log retention：საუბრის ლოგების შენახვის ვადის არჩევა შესაძლებელია. (30 days: ინახება 30 დღე, შემდეგ ავტომატურად ფიზიკურად იშლება. / Zero retention: პარამეტრი, რომელიც საუბრის ლოგებს საერთოდ არ ინახავს.)
  • Status：მიუთითებს instance-ის სტატუსს.
  • Actions：Edit = instance-ის Display name-ის რედაქტირება შესაძლებელია. Delete = instance-ის ლოგიკურად წაშლა შესაძლებელია.
• 4.1.2　Show deleted：შეუძლია instance-ების ჩამოთვლა, მათ შორის ლოგიკურად წაშლილების.
• 4.1.3　Create new instance：instance-ის შექმნა შესაძლებელია.

ანგარიშების შექმნა შესაძლებელია. სამი ტიპის ანგარიშის შექმნაა შესაძლებელი: instance admin, delegated admin და instance user.

4.2.1.1　Create new account
client admin-ის, როგორც მშობელი ანგარიშის, ქვეშ შესაძლებელია სამი ტიპის შვილი ანგარიშის შექმნა, საჭირო ფუნქციების მორგებით.

• 4.2.1.1.1　Display name：შეიყვანეთ account name.
• 4.2.1.1.2　Role：client admin-ის (მშობელი ანგარიში) შვილ ანგარიშად, შესაძლებელია არჩევა ქვემოთ ჩამოთვლილი სამიდან ერთის.
  • (a) instance_admin：ანგარიში, რომელსაც instance-ის მართვის უფლება ენიჭება.
  • (b) delegated_admin：ანგარიში, რომელსაც Client settings-თან დაკავშირებული უფლება ენიჭება.
  • (c) instance_user：ანგარიში, რომელსაც standalone-ის გამოყენების უფლება ენიჭება.
• 4.2.1.1.3　Delegated tabs：უფლების მინიჭება delegated_admin-ისთვის შესაძლებელია. console login-ის უფლება და Client settings-ის თითოეული ელემენტისთვის view ან operate უფლება, შესაძლებელია შერჩევით მიენიჭოს.
• 4.2.1.1.4　Manageable instances：უფლების მინიჭება delegated admin-ისა და instance admin-ისთვის შესაძლებელია. console login-ის უფლება და instance-ის პარამეტრების უფლება შესაძლებელია მიენიჭოს.
• 4.2.1.1.5　Usable instances：უფლების მინიჭება სამივე ტიპის ანგარიშისთვის შესაძლებელია, instance user-ის ჩათვლით. standalone-ში შესვლის უფლება შესაძლებელია მიენიჭოს. ის არ მოიცავს console login-ის უფლებას.
• 4.2.1.2　Create account：Create account ღილაკზე დაჭერა ქმნის ანგარიშს და აჩვენებს ID-სა და პაროლს. ეს პაროლი მხოლოდ ერთხელ ჩანს, ამიტომ ის უნდა ჩაიწეროს იმ მომენტში. დაკარგვის შემთხვევაში საჭიროა Reset password პაროლის ხელახლა დასაყენებლად და გასაცემად.

4.2.2　Registered accounts
client admin-დან ქვემოთ ყველა ანგარიში ჩამოთვლილია.

• Edit access：მხოლოდ Usable instances (standalone login-ის უფლება) რედაქტირდება. მართვის უფლებები ვერ შეიცვლება (არ არის რეალიზებული, უფლებების გადახლართვისა და უსაფრთხოების მიზეზებით).
• Reset password：აღადგენს პაროლს და აჩვენებს ახალს. ეს პაროლი მხოლოდ ერთხელ ჩანს, ამიტომ ის უნდა ჩაიწეროს იმ მომენტში.
• Delete：შვილი ანგარიში შესაძლებელია წაიშალოს. წაშლისას ის ანგარიში მაშინვე გამოდის სისტემიდან და ლოგიკურად იშლება. ლოგიკური წაშლიდან 30 დღის შემდეგ ის ფიზიკურად იშლება.
• Show deleted：აჩვენებს ანგარიშებს, მათ შორის ლოგიკურად წაშლილების. ფიზიკურად წაშლილები აღარასოდეს ჩანს.
• Restore：ლოგიკურად წაშლილი ანგარიში შესაძლებელია აღდგეს. ფიზიკურად წაშლილები ვერასოდეს აღდგება.

• 4.3.1　Security Overview：უსაფრთხოების სხვადასხვა სტატუსის აღქმა შესაძლებელია panel-ებში.
• 4.3.2　Passkeys：passkey-ების შექმნა, წაშლა და მართვა შესაძლებელია. რეგისტრაცია შესაძლებელია სხვადასხვა მეთოდით, თითოეული მოწყობილობის, ბრაუზერის და სხვ. გამოყენებით. უსაფრთხოების თვალსაზრისით ყველაზე რეკომენდებული შესვლის მეთოდი.
• 4.3.3　Two-Factor Authentication：2FA-ის შექმნა, წაშლა და მართვა შესაძლებელია. თუმცა, როცა passkey გამოიყენება, ის ზედმეტია უსაფრთხოების მიზნებისთვის.
• 4.3.4　Audit Log：audit log. audit log-ის ნახვა, ძიება და CSV ექსპორტი შესაძლებელია. ეს ასევე audit log-ია, რომელსაც hash chain-ის მეშვეობით გააჩნია გაყალბების მიმართ მდგრადობა, hash CSV-ში გვერდით ჩაწერით, რაც აუდიტს აიოლებს. audit log-ს აქვს 10 კატეგორია.
  • 4.3.4.1　CATEGORY：
    • Authentication：ჩაიწერს ავთენტიფიკაციასთან დაკავშირებულ მოვლენებს, როგორიცაა login წარმატება/წარუმატებლობა, logout, session-ის ვადის გასვლა, country mismatch და out-of-range login. შეგიძლიათ მიჰყვეთ „ვინ და როდის სცადა შესვლა და წარმატებული იყო თუ წარუმატებელი“ და „როდის გავიდა session-ის ვადა“.
    • Authorization：ჩაიწერს მოვლენებს, სადაც უფლების გარეშე ოპერაცია ან რესურსზე წვდომა უარყოფილ იქნა. შეუხებელი პარამეტრებზე ან სხვა tenant-ის მონაცემებზე წვდომის მცდელობები აქ რჩება. ხაზი, რომელიც არასანქცირებული წვდომის ნიშნებს აღმოაჩენს.
    • Customer：ჩაიწერს თავად მომხმარებლის ანგარიშის მდგომარეობის გადასვლებს: შექმნა, შეჩერება, განახლება, ლოგიკური წაშლა, აღდგენა, თვითგამოსვლა და სხვ. ჩვეულებრივ მთავარია ოპერატორის მხარის (saas_admin) ოპერაციები, მაგრამ თვითგამოსვლა მომხმარებლისგან მოდის.
    • Instance：ჩაიწერს instance-ის შექმნას, გადარქმევას, წაშლასა და აღდგენას. შეგიძლიათ მიჰყვეთ, რომელი instance შეიქმნა, წაიშალა და აღდგა, ვის მიერ და როდის.
    • User：ჩაიწერს ოპერაციებს user დონეზე: ანგარიშის შექმნა/წაშლა/აღდგენა, პაროლის ხელახლა გაცემა, passkey-ის რეგისტრაცია/წაშლა, 2FA-ის (TOTP) ჩართვა/გათიშვა, რეგისტრაციის პროცედურები და სხვ. ანგარიშის მართვის ცენტრალური ხაზი.
    • API key：ჩაიწერს API key-ების გაცემას, გათიშვასა და წაშლას. შეგიძლიათ მიჰყვეთ, როდის და ვის მიერ გაიცა და შეჩერდა programmatic წვდომის გასაღები.
    • Balance：ჩაიწერს ბალანსსა და ბილინგთან დაკავშირებულ მოვლენებს: დეპოზიტები, დაბრუნებები, კორექტირებები, სტატუსის ცვლილებები, monthly-limit ცვლილებები, auto-recharge პარამეტრის ცვლილებები, ჩვენების ვალუტის ცვლილებები, SLA credit-ის მინიჭება და სხვ.
    • Settings：ჩაიწერს სხვადასხვა პარამეტრის ცვლილებას: usage-limit preset-ები, ლოგების შენახვის ვადა, IP restrictions, anomaly-detection ზღვრები, FX rate, notification settings და სხვ. შეგიძლიათ მიჰყვეთ „ვინ შეცვალა რომელი პარამეტრი, როგორ და როდის“.
    • Logs：ჩაიწერს ოპერაციებს თავად ლოგებზე: საუბრის ლოგების მასობრივი წაშლა, CSV ექსპორტი და audit-log ექსპორტი. ხაზი, რომელიც ლოგების გატანასა და წაშლას აუდიტირებს.
    • System：ჩაიწერს მოვლენებს, რომელთაც სისტემა ავტომატურად ასრულებს: backup-ები, anomaly-detection batch, deletion batch, ფიზიკური წაშლა, ფსევდონიმიზაცია, payment webhook-ის მიღება, ელფოსტის მიწოდება/ჩახშობა და სხვ. ჩანაწერები აპარატურის, რომელიც ადამიანების ნაცვლად დამოუკიდებლად მოქმედებს, ინახება მომხმარებლის ოპერაციებისგან დამოუკიდებლად.
  • 4.3.4.2　EVENT TYPE：დავიწროება event type-ით. სადაც CATEGORY ფართო კლასიფიკაციაა, ეს ავიწროებს ცალკეული მოვლენის სახელით (მაგ., AUTH_LOGIN_SUCCESS, SETTINGS_UPDATED). ნაწილობრივი თანხვედრით ძიება შესაძლებელია.
  • 4.3.4.3　ACTOR：დავიწროება actor-ით. ეძებს „ვინ“ გამოიწვია მოვლენა. ჩაწერილია role-ისა და user name-ის ფორმით (მაგ., client_admin:standout), და ნაწილობრივი თანხვედრით ძიება შესაძლებელია.
  • 4.3.4.4　FROM (ISO)：ძიების პერიოდის დასაწყისი. მითითებულია ISO ფორმატით (YYYY-MM-DD); სამიზნეა ის მოვლენები, რომლებიც ამ თარიღზე ან მის შემდეგაა.
  • 4.3.4.5　TO (ISO)：ძიების პერიოდის დასასრული. მითითებულია ISO ფორმატით (YYYY-MM-DD); სამიზნეა ის მოვლენები, რომლებიც ამ თარიღზე ან მის წინაა. FROM-თან ერთად ნებისმიერი პერიოდის ამოჭრა შესაძლებელია.
  • 4.3.4.6　ROWS PER PAGE：ერთ ეკრანზე ნაჩვენები მწკრივების რაოდენობა. ეკრანზე ჩვენება მიზნად ისახავს დავიწროებულ შედეგს მაქს. 1,000 ჩანაწერამდე. ყველა ჩანაწერის მისაღებად გამოიყენეთ CSV ექსპორტი (Export All).
• 4.3.5　Active Sessions：ჩამოთვლის ანგარიშის ცოცხალ login session-ებს. ისინი ავტომატურად იწურება ბოლო წვდომიდან 30 დღის შემდეგ. ვადის გასვლამდეც, მათი ცალ-ცალკე გაუქმება შესაძლებელია Revoke-ით.
• 4.3.6　GEOIP：ჩაიწერს login-ის წარმოშობის ქვეყანას/რეგიონს. აღმოაჩენს წვდომას ბოლო login-ის ქვეყნისგან განსხვავებული ადგილიდან. ბოლო 24 საათის სტატუსს აჩვენებს panel-ში.
• 4.3.7　IP Restrictions：ადგილი IP restriction-თან დაკავშირებული პარამეტრებისთვის. ნაგულისხმევია შეზღუდვის გარეშე. მონიშვნისას, allowlist-ისა და denylist-ის შექმნა შესაძლებელია. თითოეულ სიას შეუძლია დიაპაზონების მითითება CIDR ნოტაციით. თუ allowlist ცარიელია, დაშვებულია ყველა IP, გარდა denylist-ში მყოფისა. ასევე, denylist უპირატესობს allowlist-ს.
• 4.3.8　Login Activity：login-ის ისტორია. ნაჩვენებია ბოლო 100 ჩანაწერი. panel-ში ნაჩვენებია ბოლო 24 საათში login წარმატებებისა და წარუმატებლობების რაოდენობა.
• 4.3.9　Notifications：ადგილი ავტომატური ელფოსტის შეტყობინებების მოსარგებად და კონფიგურაციისთვის.
  • Low balance：შეტყობინების პარამეტრი, როცა დეპოზიტის ბალანსი ზღვარს ქვემოთ ჩამოვა. ზღვარი იცვლება მგრძნობელობის სამ დონეზე. High ($500, ადრე შეტყობინება) / Medium ($50, სტანდარტული) / Low ($5, ბოლო მომენტში შეტყობინება). განსხვავებული ზღვრის დასაყენებლად შეიყვანეთ Custom მნიშვნელობა.
  • Sign-in from new location：შეტყობინება, როცა შესვლა ხდება ჩვეულებრივ გამოუყენებელი ქვეყნიდან/რეგიონიდან.
  • Blocked by IP restriction：შეტყობინება, როცა წვდომა იბლოკება კონფიგურირებული IP restriction-ით. High (1 ან მეტი/სთ), Medium (10 ან მეტი/სთ), Low (50 ან მეტი/სთ). თვითნებური რაოდენობის დასაყენებლად შეიყვანეთ Custom-ში.
  • Repeated sign-in failures：შეტყობინება, როცა შესვლის წარუმატებლობები მცირე დროში ინტენსიურად ხდება. High (3 ან მეტი/სთ), Medium (10 ან მეტი/სთ), Low (30 ან მეტი/სთ). თვითნებური რაოდენობის დასაყენებლად შეიყვანეთ Custom-ში.
  • Recipients — where alerts are sent：იმ კონტაქტების რეგისტრაცია და წაშლა, რომლებზეც შეტყობინებები ავტომატურად იგზავნება ელფოსტით. ნაგულისხმევად დაყენებულია client ანგარიშის რეგისტრირებული ელფოსტის მისამართი. შეტყობინების მიმღების შეცვლისას, წინა კონტაქტსაც ეცნობება, რომ ცვლილება მოხდა (უსაფრთხოების მიზნით).

გასაღებები, რომლებიც გამოიცემა VATES-ის გარე პროგრამიდან ან AI აგენტიდან გამოსაძახებლად. ბრაუზერით ჩვეულებრივი გამოყენებისთვის საჭირო არ არის.

• 4.4.1　API keys：აირჩიეთ instance, რომლისთვისაც გსურთ API Key-ის გაცემა, და შექმენით. API key მხოლოდ ერთხელ ჩანს, ამიტომ ის უნდა ჩაიწეროს იმ მომენტში.
• 4.4.2　Issued keys：ნაჩვენებია გაცემული API Key-ები. API key-ის გათიშვა და წაშლაც შესაძლებელია.
• 4.4.3　დაკავშირება AI აგენტიდან (MCP)：VATES შეიძლება დაუკავშირდეს გარე AI აგენტებს როგორც MCP (Model Context Protocol) სერვერი. დაკავშირებულ აგენტს შეუძლია დასვას შეკითხვები თქვენ მიერ ავტორიზებულ instance-ზე და მიიღოს პასუხები, რომლებიც ეყრდნობა ამ instance-ის მასალას. მას არ შეუძლია შეცვალოს პარამეტრები, წაიკითხოს საუბრის log-ები ან წვდომა მიიღოს სხვა instance-ებზე. დაკავშირების ორი გზა არსებობს.
  • 4.4.3.1　დაკავშირება connector-ით (რეკომენდებული)：თქვენს AI აგენტში დაამატეთ https://vates.standout.jp/mcp როგორც მორგებული connector. გაიხსნება ბრაუზერი VATES-ის შესვლის ეკრანზე; შედით ჩვეულებრივად (ID და პაროლი, passkey ან 2FA — ყველა მუშაობს), შემდეგ ავტორიზაციის ეკრანზე აირჩიეთ დასაკავშირებელი instance და დაუშვით წვდომა. API key-ის გამოშვება საჭირო არ არის. ამ წვდომის გაუქმება ნებისმიერ დროს შეგიძლიათ Client settings → Security → Active sessions-იდან (იხ. 4.3.5).
  • 4.4.3.2　დაკავშირება API key-ით：რედაქტორებისა და სხვა კლიენტებისთვის, რომლებსაც connector-ის ფუნქცია არ აქვთ. გამოიყენეთ https://vates.standout.jp/mcp/{workspace ID}/{instance-ის უცვლელი ID} როგორც დაკავშირების წერტილი და ავტორიზაცია გაიარეთ Authorization: Bearer {API key} სათაურით. უცვლელი ID ჩანს 4.4.2-ის Issued keys ცხრილის Immutable ID სვეტში (inst_0001 ფორმით — გაითვალისწინეთ, რომ ეს არ არის საჩვენებელი სახელი).
  • 4.4.3.3　ხელმისაწვდომი ხელსაწყოები：ამჟამად მოწოდებულია ერთი ხელსაწყო: vates_ask (მოთხოვნა ცოდნის ბაზისადმი). ის მხოლოდ წასაკითხია და არასოდეს ცვლის მონაცემებს VATES-ში.
  • 4.4.3.4　ანგარიშსწორება და შეზღუდვები：MCP-ის მეშვეობით გამოყენება ისევე ითვლება, როგორც ჩვეულებრივი საუბარი, და აისახება Usage breakdown-ში. Controls (4.6)-ში დაყენებული შეზღუდვები იმავე წესით მოქმედებს.

იმ URL-ების allowlist (არა-standalone-ების), სადაც თითოეული instance-ის ჩაშენებული widget-ის ჩაშენებაა დაშვებული. ეს დაკავშირებულია იმავე ელემენტთან თითოეული instance-ის საკუთარ settings ეკრანზე.

4.6.1　Controls
ამ ლიმიტების მთავარი მიზანია ჩვეულებრივი გამოყენების დაცვა რესურსისა და ხარჯის ფლანგვისგან, რომელსაც იწვევს უკონტროლო ციკლები და გადაჭარბებული/მასობრივი მოთხოვნები — კერძოდ, მავნედ ოპერირებული AI agent-ის უსასრულო ციკლების შეკავება და ბალანსის ამოწურვა (DoW) და სერვისის შეფერხება (DoS), რომელსაც გადაჭარბებული მოთხოვნები იწვევს. ისინი ასევე მოიცავს მწარმოებლურობასა და ხარჯთან დაკავშირებულ მორგების ელემენტებს (response-token cap, ES references-ის რაოდენობა და სხვ.). მოარგეთ თითოეული instance მის დანიშნულებას.

4.6.2　Default for new instances
instance-ის შექმნისას ნაგულისხმევი მნიშვნელობების არჩევა ან მორგება შესაძლებელია. Basic, Business და Developer არის preset-ები, წინასწარ მორგებული თავიანთი დანიშნულებისთვის; თუ ზუსტი მორგებაა საჭირო, ის Custom-ით შესაძლებელია.

• Basic：ზოგადი გამოყენებისთვის.
• Business：ბიზნეს გამოყენებისთვის.
• Developer：დეველოპერული გამოყენებისთვის.
• Custom：მორგებული.
• Apply to all existing instances：არჩეული ნაგულისხმევი მნიშვნელობების გავრცელება ყველა instance-ზე შესაძლებელია.

4.6.3　Per-instance settings
preset-ის არჩევა ან მორგება შესაძლებელია თითო instance-ზე.

• Current status：მიუთითებს მიმდინარე სტატუსს.
• Customize：თითოეული ელემენტი შესაძლებელია მოირგოს slider-ით (მნიშვნელობა 0 ნიშნავს ∞ = შეუზღუდავი). ეს ლიმიტები ქმნის დაცვას Denial of Wallet-ის (ხარჯის შეტევა, რომელიც ბალანსს ამოწურავს) და Denial of Service-ის (სერვისის შეფერხება) წინააღმდეგ, ორივე usage-based AI-სთვის სპეციფიკური (OWASP GenAI Top 10 „Unbounded Consumption“-ის შესაბამისად).

• 4.6.3.2.1　Query length per request：query სიმბოლოების რაოდენობის cap თითო მოთხოვნაზე. ახშობს ხარჯის ზრდას გადაჭარბებული შეყვანისგან. ჭარბი უარყოფილია.
• 4.6.3.2.2　Image size：image ატვირთვის ზომის cap. ახშობს რესურსის ამოწურვას უზარმაზარი ფაილებისგან. ჭარბი უარყოფილია.
• 4.6.3.2.3　PDF size：PDF ატვირთვის ზომის cap. იგივე, რაც ზემოთ. ჭარბი უარყოფილია.
• 4.6.3.2.4　Audio size：audio ატვირთვის ზომის cap. იგივე, რაც ზემოთ. ჭარბი უარყოფილია.
• 4.6.3.2.5　Bard text length：სიმბოლოების რაოდენობის cap, რომელსაც bard ერთდროულად შეკუმშავს (ბუნებრივი ენა → ES). განსაზღვრავს ხარჯს თითო შეკუმშვაზე. ჭარბი უარყოფილია.
• 4.6.3.2.6　Conversation history (chars)：context-ში ჩატვირთული საუბრის ისტორიის სიმბოლოების საერთო რაოდენობის cap. ახშობს ხარჯსა და დაყოვნებას context-ის შეუზღუდავი ზრდისგან. ჭარბი ავტომატურად იჭრება უძველესი ისტორიიდან (არ ხდება შეცდომა).
• 4.6.3.2.7　Conversation history (turns)：context-ში ჩატვირთული საუბრის ისტორიის turn-ების რაოდენობის cap. იქცევა ისევე, როგორც 4.6.3.2.6 (ინახავს უახლეს turn-ებს და ავტომატურად ჭრის).
• 4.6.3.2.8　Requests per minute：მოთხოვნების რაოდენობის cap წუთში. პირველი თავდაცვის ხაზი request flood-ის (DoS) და ავტომატიზაციის ბოროტად გამოყენების (DoW) წინააღმდეგ. ჭარბი დროებით უარყოფილია.
• 4.6.3.2.9　Requests per hour：მოთხოვნების რაოდენობის cap საათში. იქცევა ისევე, როგორც 4.6.3.2.8.
• 4.6.3.2.10　Concurrent sessions：ერთდროული საუბრის session-ების რაოდენობის cap. ახშობს რესურსის ამოწურვას პარალელური request flood-ისგან. ჭარბი უარყოფილია.
• 4.6.3.2.11　Max tokens per response：ერთი პასუხის output token-ების cap. ახშობს output-ხარჯის ზრდას გადაჭარბებული პასუხებისგან.
• 4.6.3.2.12　Max ES references (top_k)：ES-ის მაქსიმალური რაოდენობა, რომელსაც vates პასუხისას მიმართავს. ეს არ არის შეტევის დაცვა, არამედ სიზუსტისა და ხარჯის მორგება: რაც მეტი მითითებაა, მით მაღალია სიზუსტე, მაგრამ ხარჯიც პროპორციულად იზრდება. მინიმუმ 20.

ყოველთვიური გამოყენების საფასურის (USD) ნახვა შესაძლებელია.

• 4.7.1　Usage breakdown：წელი და თვე შესაძლებელია მიეთითოს dropdown-იდან.
• 4.7.2　By instance：გამოყენების დაშლა თითო instance-ზე.
  • Instance：instance-ის სახელი.
  • Conversations：საუბრების საერთო რაოდენობა.
  • Chat：vates-თან საუბრების საფასური.
  • Bard：bard-ის გამოყენების საფასური.
  • Druid：druid-ის გამოყენების საფასური.
  • Fallback：chat-ის fallback გამოყენების საფასური. * სარეზერვო API (OpenAI), რომელიც გამოიყენება, როცა მთავარი vates API (Anthropic) არ მუშაობს.
  • STT：მეტყველების წაკითხვა (Speech-to-Text, ხმა → ტექსტი გარდაქმნა).
  • TTS：მეტყველების ხმამაღლა წაკითხვა (Text-to-Speech, ტექსტი → ხმა სინთეზი).
  • Total：საერთო ოდენობა.
  • Include instances with 0 conversations：იმ თვეში გამოუყენებელი instance-ების ჩვენება/დამალვა.

დეპოზიტის ბალანსისა და მისი ცვლილების ისტორიის შემოწმება შესაძლებელია, ხოლო გადახდისა და გადახდის პარამეტრების კონფიგურაცია შესაძლებელია.

• 4.8.1　Balance：მიმდინარე დეპოზიტის ბალანსი.
• 4.8.2　Top Up Balance：
  • Card：საკრედიტო ბარათით გადახდა. Powered by Stripe. ბარათის ტიპები ნაჩვენებია ავტომატურად ქვეყნის/რეგიონის მიხედვით. გადახდისას გადახვალთ Stripe-ის ეკრანზე. modal-ზე მოცემული ოდენობა მიუთითებს იმ ოდენობას, რომელიც აისახება დეპოზიტის ბალანსში; Stripe-ზე გადასვლის შემდეგ ემატება თითოეული ქვეყნის/რეგიონის გადასახადი.
  • International Transfer：ანგარიშით გადახდა ვალუტის მიხედვით.
  • Domestic Transfer：ანგარიშით გადახდა ქვეყნის/რეგიონის მიხედვით. დეპოზიტის ბალანსში ასახული ოდენობა არის გადარიცხვის ოდენობა თითოეული ქვეყნის/რეგიონის გადასახადის გამოკლებით.
• 4.8.3　Auto Recharge：
  • Auto Recharge：შესაძლებელია დაყენდეს ისე, რომ ავტომატური გადახდა (საკრედიტო ბარათი) მოხდეს, როცა დეპოზიტის ბალანსი ზღვარს ქვემოთ ჩამოვა. ნაგულისხმევია OFF.
  • Adjust：ზღვარი, auto-recharge ოდენობა და monthly limit ოდენობა შესაძლებელია დაყენდეს.
• 4.8.4　Transactions：ტრანზაქციების ისტორიის ნახვა შესაძლებელია.

4.9.1　Data lifecycle
VATES ირჩევს მონაცემთა შენახვის ვადებს ყველაზე მკაცრ სტანდარტზე მითითებით, ყველა იურისდიქციის რეგულაციებს შორის, სადაც თქვენი მონაცემები შეიძლება იყოს რელევანტური (EU, UK, იაპონია, კალიფორნია, ჩინეთი, ბრაზილია, კორეა, სინგაპური, კანადა, ავსტრალია და სხვ.). თქვენი მონაცემები იმართება ყველაზე დამცავი საბაზისო სტანდარტით, თქვენი მდებარეობის მიუხედავად.

4.9.2　Current status
მიუთითებს client ანგარიშის მიმდინარე სტატუსს.

4.9.3　State transitions
მდგომარეობების სია, რომელთაც ანგარიში გადის. თითოეული მდგომარეობის საწყისი წერტილი და ყოვნების პერიოდი შემდეგია.

• active：აქტიური. სერვისი ხელმისაწვდომია.
• suspended：შეჩერებული. სერვისი დაპაუზებულია, მაგრამ შესაძლებელია განახლება. მონაცემები ინახება.
• logical_deleted：წაშლის მოთხოვნის მომენტი. ამ დღიდან, როგორც საწყისი წერტილიდან, აღდგენა შესაძლებელია 30 დღის განმავლობაში და მონაცემები სრულად ინახება. 30 დღის შემდეგ ის ავტომატურად გადადის ფსევდონიმიზაციის ფაზაში.
• pseudonymized：მდგომარეობა წაშლის მოთხოვნიდან 30 დღის შემდეგ. ინფორმაცია, რომელსაც პიროვნების იდენტიფიცირება შეუძლია (user name, display name და სხვ.), იცვლება შეუქცევადი hash-ით და ხდება აღუდგენელი. ამ წერტილიდან ის რჩება, სანამ თითოეული მონაცემთა კატეგორიის შენახვის ვადა არ ამოიწურება.
• physical_deleted：თითოეული მონაცემთა კატეგორიის შენახვის ვადის ამოწურვისას. წაიშლება დისკიდან მთლიანად, აღდგენის შესაძლებლობის გარეშე.

4.9.4　Data categories and retention (17)
ანგარიშთან დაკავშირებული მონაცემთა კატეგორიები და შენახვის ვადები. ყველა შენახვის ვადა საწყის წერტილად იღებს წაშლის მოთხოვნას (logical_deleted-ში შესვლას). თითოეული კატეგორიის ზუსტი მნიშვნელობა ნაჩვენებია ეკრანზე Retention სვეტში.

• customer_state：მომხმარებლის ანგარიშის საერთო მდგომარეობა (active/suspended და სხვ.). ფსევდონიმიზდება წაშლის მოთხოვნიდან 30 დღის შემდეგ; ფიზიკური წაშლა იზიარებს იმავე ფაილს, რასაც ბალანსი (customer_balance), ამიტომ ის წაიშლება ერთად ბალანსის სამართლებრივი შენახვის ვადის ამოწურვისას (10 წელი).
• instance_state：მდგომარეობა თითო instance-ზე. ფსევდონიმიზდება წაშლის მოთხოვნიდან 30 დღის შემდეგ (მხოლოდ display name; უნიკალური ID inst_NNNN ინახება როგორც immutable ID), შემდეგ ფიზიკურად იშლება 90 დღის შემდეგ.
• users_with_pii：user ანგარიშის ინფორმაცია (პერსონალური ინფორმაციის ჩათვლით, როგორიცაა ID, display name და credentials). ფსევდონიმიზდება წაშლის მოთხოვნიდან 30 დღის შემდეგ, შემდეგ ფიზიკურად იშლება 90 დღის შემდეგ.
• user_instance_access：კავშირი user-სა და usable instance-ებს შორის. იშლება ანგარიშთან ერთად წაშლისას (დამოუკიდებელი შენახვის ვადის გარეშე).
• api_keys：გაცემული API key-ები (ინახება როგორც შეუქცევადი hash; ღია ტექსტი არ ინახება). ფიზიკურად იშლება წაშლის მოთხოვნიდან 90 დღის შემდეგ (ფსევდონიმიზაციის გარეშე).
• revoked_sessions：გაუქმებული session-ები. არსებული batch მათ ფიზიკურად შლის გაუქმებიდან 90 დღის შემდეგ.
• session_logs：საუბრის ისტორია. შენახვის ვადა დამოკიდებულია მომხმარებლის გეგმის არჩევანზე (Standard = 30 დღე / Secure = საერთოდ არ ინახება = დაუყოვნებლივი წაშლა).
• usage_records：გამოყენების ცალკეული მოვლენის ლოგი. ფსევდონიმიზდება წაშლის მოთხოვნიდან 30 დღის შემდეგ, შემდეგ ფიზიკურად იშლება 90 დღის შემდეგ.
• usage_aggregates：გამოყენების აგრეგირებული მნიშვნელობები (ბილინგის საფუძველი). ექვემდებარება სამართლებრივ შენახვას. არ ფსევდონიმიზდება; ფიზიკურად იშლება ბოლო ტრანზაქციიდან 10 წლის შემდეგ (იაპონიის კომპანიების კანონის 432-ე მუხლის შესაბამისად). ვერ დაჩქარდება წაშლის მოთხოვნითაც კი.
• customer_balance：მომხმარებლის ბალანსი (გადახდის დადგენილი მნიშვნელობა). ექვემდებარება სამართლებრივ შენახვას. ფიზიკურად იშლება ბოლო ტრანზაქციიდან 10 წლის შემდეგ. ვერ დაჩქარდება წაშლის მოთხოვნითაც კი.
• balance_history：ბალანსის ცვლილების ისტორია. ექვემდებარება სამართლებრივ შენახვას. ტრანზაქციის ოდენობა, ვალუტა და rate ინახება 10 წელი (მხოლოდ ოპერატორის სახელი ფსევდონიმიზდება წაშლის მოთხოვნიდან 30 დღის შემდეგ). ვერ დაჩქარდება წაშლის მოთხოვნითაც კი.
• instance_audit_log：instance-ის audit log (გაყალბების მიმართ მდგრადი ლოგი). ფსევდონიმიზდება წაშლის მოთხოვნიდან 30 დღის შემდეგ, შემდეგ ფიზიკურად იშლება 2 წლის შემდეგ. აუდიტის მოთხოვნების (SOC2 / PCI DSS) ქვედა ზღვარი 1 წელია, მაგრამ რადგან ყოველწლიური აუდიტის დროის გადაწევა ნიშნავს, რომ 1 წელი გამოტოვებდა ლოგებს აუდიტირებულ პერიოდში, უსაფრთხო მხარეს მიღებულია მისი ორმაგი — 2 წელი.
• ip_restrictions：IP restriction-ის პარამეტრები (Allowlist / Denylist). ფიზიკურად იშლება წაშლის მოთხოვნიდან 30 დღის შემდეგ (მგრძნობიარე ინფორმაცია არ არის, ფსევდონიმიზაცია არ სჭირდება).
• e_core_knowledge：ES-IFM ცოდნის აქტივები (თქვენი ინტელექტუალური საკუთრება). ფიზიკურად იშლება წაშლის მოთხოვნიდან 30 დღის შემდეგ (ფსევდონიმიზაციის გარეშე).
• instance_settings：instance-ის პარამეტრები (branding, ლიმიტის მნიშვნელობები, prompt-ები და სხვ.). ფიზიკურად იშლება წაშლის მოთხოვნიდან 30 დღის შემდეგ (მგრძნობიარე ინფორმაცია არ არის, ფსევდონიმიზაცია არ სჭირდება).
• shell_settings：shell-ის პარამეტრები (ცენტრალური master reference პარამეტრი). ფიზიკურად იშლება წაშლის მოთხოვნიდან 30 დღის შემდეგ (მგრძნობიარე ინფორმაცია არ არის).
• client_settings：client-მასშტაბის ნაგულისხმევი პარამეტრები. ფიზიკურად იშლება წაშლის მოთხოვნიდან 30 დღის შემდეგ (მგრძნობიარე ინფორმაცია არ არის).

4.9.5　Delete account
ანგარიშს გადაიყვანს წაშლის მოთხოვნის მდგომარეობაში (logical_deleted). აღდგენა შესაძლებელია საწყისი წერტილიდან 30 დღის განმავლობაში. 30 დღის შემდეგ, მონაცემები ეტაპობრივად ფსევდონიმიზდება და ფიზიკურად იშლება ზემოთ მოცემული თითოეული შენახვის ვადის შესაბამისად. სამართლებრივ შენახვას დაქვემდებარებული მონაცემები (usage_aggregates, customer_balance, balance_history) ინახება წაშლის მოთხოვნის შემდეგაც, სანამ სამართლებრივი ვადა (10 წელი) არ გავა. ეს მოქმედება ეხება ამ ანგარიშის ყველა მომხმარებელს.