ოპერატორების ეკოსისტემა

1) მონაწილეობის როლები და მოდელები

ანჩორ-ოპერატორი (Core): პლატფორმის მფლობელი, განსაზღვრავს სტანდარტებს, აქვეყნებს ზოგად სერვისებს.
Affiliate/Referral ოპერატორი: იგი ციტირებს მოთხოვნას, ასრულებს არხის როლს, შეუძლია ნაწილობრივ გამოიყენოს ზოგადი სერვისები.
White-label/Franchise: პარტნიორის ბრენდი Shared Core- ზე (UI/მარკეტინგი არის საკუთარი, საერთო ბირთვი).
Multi-brand Holding: ერთი და იგივე ჯგუფის რამდენიმე ოპერატორი, საერთო ზურგჩანთა/მონაცემები პოლიტიკის შესახებ.
Technology/ISV ოპერატორები: უაღრესად სპეციალიზირებული სერვისები (KYC, რისკის ესკორტი, ანტიფროდი, გადახდები).
Market/Hub ოპერატორი: აერთიანებს ოფისებს, მოქმედებს როგორც „ბირჟა“ რამდენიმე ოპერატორისთვის.

• ერთი Core + ბრენდის ფანჯრები.
• Core ფედერაცია ხიდებით (interconnect).
• კერა და პერიფერია: საერთო ბაზარი (SOR), ადგილობრივი შემსრულებლები.

2) ღირებულებისა და ზოგადი სერვისების რუკა

• იდენტურობა და წვდომა: IDP, SSO/SAML/OIDC, RBAC/ABAC, ხანმოკლე ნიშნები.
• გადახდები და გაანგარიშებები: PSP კარიბჭეები, საფულეები, KMS/დაშიფვრა, ჩანაწერები.
• KYC/AML/Antifrod: მრავალჯერადი გადამოწმება, ჩეკები, ქცევითი მოდელები.
• შინაარსი/კატალოგები/პროდაქტიული ფიდები: ერთიანი კატალოგები, რეიტინგები, შურისძიება, ლიცენზიები.
• ღონისძიების საბურავი: ერთიანი მოვლენები, გასწვრივ „trace _ id“, დედაპლატი.
• დაკვირვება: SLI/SLO, logs/მეტრიკა/ტრეისი ეტიკეტებით 'ოპერატორის', 'brand', 'region'.
• PRM/ORM: ოპერატიული პარტნიორების მენეჯმენტი (onboarding, შესაბამისობა, KPI).
• მონაცემთა პლატფორმა: DWH/ლაქები, მონაცემთა ხელშეკრულება, კონფიდენციალურობა/ლოკალიზაცია.
• მთავრობა: პოლიტიკის კატალოგები, რისკების რეესტრები, ინტეგრაციის სერტიფიკაცია.

3) თავსებადობა და სტანდარტები (ინტეგრაცია)

yaml event. v1:
id: uuid occurred_at_utc: timestamp operator_id: string brand_id: string type: string  # e. g., user. created / txn. settled / kyc. approved payload: object signature: ed25519 version: 1

catalog. item. v1:
id: string title: string region: string tags: [string]
availability_ttl_s: int vendor: { operator_id, tier }

Versioning & Compatibility: თესლი, დამხმარე ფანჯრები 'vN/vN + 1', ქვიშის ყუთები და ტესტის პაკეტები, conformance ტესტები და სტატუსები „თავსებადი/მოძველებული“.

rego package operators. compat deny["No event signature"] { input. event. signature == "" }
deny["Unsupported version"] { not startswith(input. event. version, "1. ") }

4) მონაცემთა ფედერაცია და კონფიდენციალურობა

სუბიექტების მოდელი: ერთი 'global _ user _ pseudo _ id' + ადგილობრივი იდენტიფიკატორები (ფსევდონიზაცია).
სუვერენიტეტი/ლოკალიზაცია: geo-pinning (ჩვენ განვსაზღვრავთ, თუ სად ცხოვრობენ PII/გარიგებები).
Retenschen: TTL/ILM დომენების მიხედვით, crypto-erasure კლავიშებზე (პლეი-ოპერატორი/ტრანს-რეგიონი).
საგნის უფლება: DSAR მარშრუტიზაცია ოპერატორების ჯაჭვის გასწვრივ.
მონაცემთა ნაკადი: „აუცილებელი მინიმუმი“ - დანაყოფები/ფსევდო, ველების ნებართვები.

yaml dataset: txn_ledger owner: "core-finops"
contains_pii: false regions: ["EU","TR","LATAM"]
retention: "7y"
sharing:
allowed_to: ["brand_","hub_recon"]
fields: ["txn_id","amount","currency","status","operator_id","brand_id","ts"]

5) კოლექტიური ლიკვიდობა და მარშრუტიზაცია

• მიზნები: fill rate, time-to-match, ხარისხი/რეპუტაცია, შესაბამისობა.
• კრიტერიუმები: ფასი/განაკვეთები/ხარისხი, პარტნიორი SLA, რეგიონი/იურისდიქცია, ლატენცია, fairness.
• ხელშეკრულებები: ვინ ფლობს გარიგებას/კომისიას, პრეტენზიის ფანჯრებს, ჩანაწერებს.

python def route(req, pools):
candidates = [q for p in pools if compliant(req,p) for q in p. quote(req)]
ranked = sorted(candidates, key=lambda q: score(q, req))
return pick_with_fairness(ranked, window="24h", max_share=0. 4)

6) ხელშეკრულებები და კასკადის SLA/OLA

1. SLO: წვდომა, p99, ღონისძიებების მიწოდება, გაანგარიშების სიზუსტე.

2. ინციდენტები/ესკალაცია: არხები, აფდეიტის ფანჯრები, როლები L1/L2/L3.

3. ანაზღაურება: სესხები/ჯარიმები, სისტემატიზაციის შეწყვეტის უფლება.

4. შესაბამისობა: DPA, KYC/AML, შინაარსის წესები, ასაკობრივი შეზღუდვები.

5. Exit გეგმა: მონაცემთა ექსპორტი, ვადები, ასლების განადგურება.

6. ვერსიები/დეპრესიები: ნოტიფიკაციის ფანჯრები, ვერსიების „ორმაგი მხარდაჭერა“.

OLA (Core- ს შიგნით): პლატფორმის ბრძანებების მიზნები გარე SLA (PRM/ORM, ტელემეტრია, ფინანსები, უსაფრთხოება).

7) ფასეულობების და გამოთვლების აღნიშვნა

მოდელები: CPA/RevShare/Hybrid, net vs gross, მინიმალური გარანტიები.
ატრიბუტი: ღონისძიების ფანჯრები (signup/FT/purchase), არხების პრიორიტეტი, მოვლენების დედობა ('event _ id', 'click _ id', 'session _ fp').
რეკონსტრუქცია: ორმხრივი მოხსენებები, infinitions, SLA განსხვავებების დახურვა.
Settlement: T + N, მულტივალუტა, კურსები, შენახვა/შენახვა.

yaml report. settlement. v1:
period: "2025-10"
operator_id: "opA"
brand_id: "brand42"
totals: { gmv, net, commission, taxes, payout }
diffs: [{ event_id, reason, amount, side }]
signature: "ed25519:..."

8) Governance и ORM (Operator Relationship Management)

1. Sourcing/Screening: კითხვარი, იურიდიული შემოწმება, თავსებადობა, შინაარსის წყაროები/კაპიტალი.

2. Onboarding: გასაღებები/API, ქვიშის ყუთები, ინტეგრაციის ტესტის შემთხვევა, DPA/MSA/SLA.

3. Enablement: haids, SDK, კატალოგები, ერთობლივი მარკეტინგი.

4. რუნი: კვარტალური QBR, თავსებადობის სტატუსი, მოვლენების აუდიტი, KPI/OKR.

5. Changes/Exit: კლავიშების როტაცია, ვერსიების განახლება, მონაცემთა ექსპორტი, პოსტ-mortem.

yaml operator_id: "opA"
brands: ["brand42","brand43"]
regions: ["EU","TR"]
contracts: { msa: "2025-01-10", dpa: "2025-01-10", sla: "99. 9/30d" }
tech:
api_versions: ["events. v1","catalog. v1"]
webhook_signature: "Ed25519"
limits: { rps: 300, burst: 1000 }
compliance:
kyc: true aml: true age_gates: "18+"
scorecards:
reliability: "A"
recon_health: "A-"
status: "active"
owner: "ecosystem-team"

9) ეკოსისტემის დაკვირვება და SLO

SLI/SLO ქსელის დონეზე: გლობალური ფილმი, დრო-მატჩის პ95, საკანცელარიო, ფანჯრების კონვერტაციის წილი, egress მოხმარება.
აუდიტი და კვალდაკვალ: 'trace _ id', მოვლენების ხელმოწერები, ვერსიების ჟურნალები.
შედარების დაშბორდები: 'operator/brand/region', შეცდომების ბიუჯეტის შემცირება, პროგნოზული ალერტები.

rego package release. slo deny["SLO burn risk"] {
input. forecast. fill_rate < 0. 90 input. change. affects == "routing"
}

10) უსაფრთხოება და რისკები

Zero-Trust: mTLS, არტეფაქტების ხელმოწერა, SBOM/SLSA, საიდუმლოებები KMS- ში, როტაცია.
უფლებები და PoLP: მინიმალური საჭირო ნაკრები, ოპერაციებისთვის „დროებითი წვდომა“.
ანტიფროდი და ხარისხი: honey-tokens, მოწყობილობა/ASN სიგნალები, ქცევითი მოდელები, q-score ოპერატორები.
იურისდიქციები: მონაცემთა ლოკალიზაცია, სატყუარა ფურცლები.
უწყვეტობა (DR): მეორე რეგიონები, PITR/immutable-bacaps, წვრთნები (თამაშის დღეები).

11) ეკონომიკა და FinOps

Unit მეტრიკები: '$/req', '$/match', '$/GB-egress', gCO-e/req.
მრავალ პროვაიდერი: ტარიფების/რეგიონების შედარება, ბალანსი ხარისხსა და ღირებულებას შორის.
კვოტები/ლიმიტები: caps ოპერატორებისთვის/ბრენდებისთვის, სამართლიანი გასროლა.
მარკეტინგის ფონდები (MDF): ინტეგრაციისა და ადგილობრივი გაშვების სტიმულირება.

12) პლეიბუკები და სწავლებები

12. 1 ინციდენტი „მოვლენების რასინქრონი“

yaml playbook: "event-drift"
detect: "orderbook_drift>1          recon_diff>ε"
steps:
- "freeze settlements for affected brands"
- "replay from checkpoint T-Δ via outbox"
- "diff&patch; partner sign-off"
kpi: ["RTA<=2h","residual_diff<=ε"]

12. 2 „ბრენდის ცივი დასაწყისი“

1. ასორტიმენტის/კატალოგის იმპორტი

2. საერთო აუზიდან ლიკვიდობის სიდიდე

3. PRM enablement და ადგილობრივი მარკეტინგი

4. მიზნები: 'tv <24h', 'fill _ rate _ w1 - 85%'.

13) ეკოსისტემის სიმწიფის მოდელი

14) ანტი შაბლონები

„თითოეული საკუთარი გზით“: მოვლენებისა და ვერსიების საერთო ხელშეკრულების არარსებობა.
ოპერატორებს შორის სინქრონული მკაცრი დამოკიდებულება არის კასკადის უკმარისობა.
დაშიფვრის/რეგისტრაციის ერთი გასაღები ყველასთვის არის მისამართის გაწვევის შეუძლებლობა.
ჩანაწერების არარსებობა - ქრონიკული დავები და გადახდების გაყინვა.
სუპერ ოპერატორი, რომელსაც აქვს წილი> 50%, fairness შეზღუდვების გარეშე.
PDF პოლიტიკოსები „პოლიტიკისა და კარიბჭეების გარეშე“.
Logs PD- ით შენიღბვის გარეშე/TTL არის მარეგულირებელი რისკები.

15) არქიტექტორის ჩეკის სია

1. განსაზღვრულია როლები (core/brands/hub/ISV) და შერჩეული ტოპოლოგია?
2. არსებობს ერთი ღონისძიების კონტრაქტი, თავსებადობის ფანჯრები და ქვიშის ყუთი?
3. მუშაობს SOR და fairness, ჩაწერილია SLO ლიკვიდობა?
4. აღწერილია MSA/SLA/DPA, კასკადი OLA და ესკალაციის პროცესი?
5. ფასეულობებისა და თვითმფრინავების ატრიბუტები გამჭვირვალეა, რეკონ-SLA - 5 დღე?
6. კონფიდენციალურობა/ლოკალიზაცია: geo-pinning, ფსევდონიზაცია, TTL/ILM?
7. Observability: 'trace _ id', burn-rate, გარე სინთეტიკა?
8. უსაფრთხოება/Zero-Trust: ხელმოწერა, mTLS, KMS, როტაცია, SBOM/SLSA?
9. DR/სავარჯიშოები: PITR, მეორე რგოლი, თამაშის დღეები RTA/RPA მეტრებით?
10. FinOps: ბიუჯეტები egress/compute, caps და fair sharing ოპერატორებს შორის?
11. ORM/PRM: ოპერატორების პასპორტები, სერტიფიკაცია, QBR, exit გეგმა?

16) მინი მაგალითი „კარიბჭე“ CI/CD ეკოსისტემისთვის

rego package ecosystem. release

deny["Missing operator passport"] {
not input. operator. passport_complete
}

deny["Breaking change without deprecation window"] {
input. api. change == "breaking"
input. api. notice_days < 90
}

deny["Routing change risks SLO"] {
input. routing. change == true input. slo_forecast. fill_rate_drop > 0. 03
}

დასკვნა

ოპერატორების ეკოსისტემა არის პლატფორმის აზროვნება: სტანდარტები და თავსებადობა „ხელის“ ლიგატების ნაცვლად, ზოგადი სერვისები და დაკვირვება ფრაგმენტული დასტის ნაცვლად, სამართლიანი მარშრუტიზაცია და გამჭვირვალე გამოთვლები კონფლიქტების ნაცვლად. სწორი დიზაინის პირობებში, supply მხარე ხდება მასშტაბური და პროგნოზირებადი: ახალი ბრენდები სწრაფად დაიწყება, ლიკვიდობა იზრდება, რისკები კონტროლდება და მთელი ქსელი აძლიერებს ერთმანეთს საერთო ოქმების, მონაცემებისა და პროცესების გამო.