МАТЧАСТЬ / TRUST & VERIFICATION / DOCUMENT 20 / 02.09.2026

Верификация компаний и экспертов

Как доказать, что компания действительно существует, что пользователь имеет право управлять её профилем, что эксперт — реальный человек с подтверждаемой связью с организацией, какие факты можно считать проверенными, какие badge показывать публично, когда проверку нужно повторять и как не превратить «галочку» в платный декоративный значок.

4разных вещей: existence, control, relationship, facts

V0–V3рабочие уровни доверия, но не «рейтинг качества бизнеса»

2+независимых сигналов желательно для high-impact claim

∞ ≠ verifiedверификация имеет срок актуальности и может истекать

1. Главное решение

Не использовать одну универсальную «синюю галочку». «Матчасть» должна отдельно подтверждать четыре разных утверждения: организация существует; пользователь имеет право управлять её профилем; конкретный человек действительно связан с организацией/имеет заявленную роль; конкретные факты подтверждены источниками.

VERIFICATION ≠ ONE BADGE 1. ENTITY EXISTENCE "такая компания существует" 2. CONTROL "этот аккаунт имеет право управлять профилем" 3. RELATIONSHIP "этот эксперт действительно связан с компанией" 4. FACT VERIFICATION "конкретные данные подтверждены источниками" Ни одно из этих утверждений НЕ означает: "компания хорошая" "компании можно доверять деньги" "продукт качественный" "редакция рекомендует компанию"

2. Почему это критично для продукта

РБК Компании строит пользовательский workflow вокруг конкретной организации: для добавления компании указывается ОГРН, затем данные подтверждаются и подаётся заявка на подключение. В экспертном профиле РБК прямо оставляет за собой право запросить документы, подтверждающие трудоустройство, если возникают сомнения. Это показывает, что деловая платформа должна проверять не только email пользователя, но и связь пользователя/эксперта с сущностью.

Для «Матчасти» verification layer является частью data moat: AI/search systems и читатели получают не просто маркетинговый текст компании, а явно обозначенное происхождение сведений.

3. Четыре независимых объекта проверки

Объект	Вопрос	Пример доказательства
Existence	Существует ли организация?	ЕГРЮЛ/ЕГРИП, официальный иностранный реестр, LEI и т. п.
Control	Имеет ли этот пользователь право менять профиль?	DNS/domain verification, corporate email, документ/ручная проверка, делегирование владельцем.
Relationship	Связан ли эксперт/бренд/юрлицо с организацией?	Official company page, corporate email, HR/appointment document, verified admin confirmation + source.
Claim	Правда ли конкретное утверждение?	Реестр, отчёт, документ, dataset, независимый источник.

4. Уровни verification

V0 — UNVERIFIED entity создана / данные заявлены V1 — IDENTITY VERIFIED подтверждено существование и базовые идентификаторы V2 — CONTROL VERIFIED представитель подтвердил право управлять профилем V3 — FACTS VERIFIED ключевые данные/отношения дополнительно проверены ВАЖНО: V3 не значит "лучший бизнес" и не является рейтингом.

Публично лучше не показывать загадочные «V2/V3». В интерфейсе использовать понятные подписи: «Компания подтверждена», «Профилем управляет представитель компании», «Данные проверены по источникам».

5. ФНС как основной источник для российских юрлиц и ИП

ФНС перечисляет сервис «Прозрачный бизнес» как сервис комплексной информации о налогоплательщиках: поиск ЮЛ/ИП, статусы, учредители, руководители, адреса, правопреемство, сведения о недостоверности, выписки, ОКВЭД и другие данные. ФНС также предоставляет сведения из ЕГРЮЛ/ЕГРИП для использования в информационных системах, включая ежедневно обновляемые данные в соответствующей модели доступа.

Поле	Можно использовать как verification signal?
ОГРН / ОГРНИП	Да, сильный identifier
ИНН	Да
Юридическое наименование	Да, с датой состояния
Статус организации	Да
Руководитель	Да, как реестровое отношение на конкретную дату
Учредители	Да в доступном объёме и с учётом актуальности
ОКВЭД	Да, но не считать полной картиной фактической деятельности
Маркетинговое описание	Нет, это другой слой данных

6. Verification source hierarchy для РФ

ENTITY IDENTITY: A. ФНС / ЕГРЮЛ / ЕГРИП B. другие официальные государственные реестры C. официальный домен / документы компании D. корпоративный email / domain control E. публичные business directories F. user-submitted data Чем ниже источник, тем меньше он должен иметь вес в автоматическом verification decision.

7. Verification иностранной компании

Не делать российский ИНН обязательным универсальным условием, иначе платформа закрывается для иностранных SaaS/AI-компаний.

Сигнал	Пример
Official company register	Юрисдикционный регистрационный номер
LEI	Если применим
Tax/VAT identifier	По стране
Official domain	Domain control + website
External authoritative IDs	Дополнительный disambiguation

Google Organization structured data также рассматривает URL, tax identifiers, LEI/ISO identifiers и другие administrative properties как данные, помогающие однозначно определить организацию.

8. Entity existence workflow

USER ENTERS: INN / OGRN / name / domain SYSTEM: → search authoritative registry → normalize identifiers → find existing Mathchast entity → entity-resolution check → show candidate company USER: "Это моя компания" SYSTEM: → create claim request → move to CONTROL verification Если entity ещё нет: → create V0 → fetch verified registry fields → promote identity to V1

9. Claim profile ≠ create new company

Если компания уже существует в графе, пользователь не создаёт её заново. Он запрашивает права на существующую entity.

Это предотвращает:

дубли;
две карточки одной организации;
историю, принадлежащую аккаунту агентства;
потерю публикаций после смены подрядчика.

10. Методы проверки права управления

Метод	Strength	MVP?
Corporate email на verified domain	Высокий	Да
DNS TXT challenge	Очень высокий для контроля домена	Да/Р1
HTML file/meta challenge на сайте	Высокий	Можно позже
Manual document review	Высокий при корректной процедуре	Fallback
Invoice payment от юрлица	Хороший supporting signal	Да, но не единственный универсальный метод
Free mailbox @gmail/@mail и текст «я директор»	Низкий	Не достаточно

11. Почему DNS verification особенно полезна

Google Search Console использует DNS record как единственный способ проверки Domain property. Это не доказывает юридическую собственность бизнеса, но является сильным доказательством технического контроля над доменом.

Для «Матчасти» DNS verification означает: «аккаунт контролирует домен, который ранее подтверждён как официальный домен организации». Два отдельных факта вместе дают сильное доказательство control.

1. Mathchast verifies: example.com = official domain of Organization X 2. User adds: TXT mathchast-verification=TOKEN 3. System sees token CONCLUSION: user controls official domain of X → strong CONTROL signal НЕ CONCLUSION: user юридически владеет X или является CEO.

12. Corporate email verification

official domain = acme.ru user = maria@acme.ru → send one-time code → email verified stronger: maria appears on official team/contact page weaker: random_employee@acme.ru может доказать связь с доменом, но не автоматически admin authority.

13. Email role policy

Email	Что доказывает
ceo@company.ru	Контроль ящика на домене, но роль «CEO» всё равно не принимается автоматически как юридический факт
name@company.ru	Связь с корпоративным доменом
agency@gmail.com	Не доказывает связь с клиентом
pr@agency.ru + delegation	Агент может получить отдельное делегированное право

14. Агентское управление

Agency workflow должен быть построен через делегирование, а не через фиктивное «агентство является владельцем профиля клиента».

COMPANY CONTROL OWNER → invites Agency A → grants: EDIT_PROFILE SUBMIT_PUBLICATIONS VIEW_ANALYTICS BILLING? optional OR: Agency requests access → company confirms Fallback: documented authorization + manual review Revoke: company can remove agency public entity/history remains.

15. Что делать, если у компании нет сайта

Не требовать domain verification от всех. Для реального малого бизнеса без домена:

проверить реестровую entity;
проверить документы/оплату/уполномоченного представителя;
использовать manual verification;
дать V1 identity, а control подтверждать другим методом.

16. Account verification и Entity verification — разные вещи

Account

Email, MFA, телефон при необходимости, security.

Entity

Официальные IDs, domain, registry, company status.

«Пользователь подтвердил email» не означает «компания подтверждена».

17. Expert verification

РБК Компании допускает профиль эксперта только для штатного сотрудника организации в своей модели и при сомнениях может запросить подтверждающие документы. «Матчасти» может быть шире: эксперт может быть сотрудником, основателем, независимым консультантом или исследователем, но тип связи должен быть указан точно.

PERSON VERIFIED? → identity → relationship → expertise claims PERSON: реальный человек RELATIONSHIP: employee / founder / partner / independent EXPERTISE: что именно подтверждает компетенцию

18. Уровни экспертной проверки

Level	Что подтверждено	Public wording
E0	Профиль создан	Без badge
E1	Identity / contact verified	«Личность подтверждена» — только если реально есть такой процесс
E2	Связь с организацией	«Связь с компанией подтверждена»
E3	Ключевая роль/экспертиза подтверждена источниками	«Данные об эксперте проверены»

19. Не продавать Expert Verification

Verified badge нельзя купить как тариф. Можно брать деньги за ускоренную ручную проверку документов/enterprise onboarding, но результат проверки не гарантируется.

Иначе verification перестаёт быть trust signal.

20. Методы подтверждения связи эксперта с компанией

Evidence	Strength
Corporate email + official team page	Очень хороший
Official press release / company page naming person and role	Высокий
Registry showing formal executive	Высокий для зарегистрированной роли
Appointment/employment document	Высокий, но privacy-sensitive
Verified company admin confirmation	Хороший supporting signal
LinkedIn/social profile alone	Supporting, не единственный
Сам эксперт написал это в анкете	Claim, не verification

21. Не хранить трудовой документ дольше необходимого

Verification evidence может содержать лишние персональные данные. Хранить минимум, необходимый для доказательства результата проверки: тип документа, дата, кто проверил, redacted reference/hash — вместо бесконечного хранения полной копии, если она не нужна юридически.

Точный retention/privacy процесс будет отдельным документом.

22. Expertise verification

EXPERT CLAIM: "специалист по AI Visibility" evidence: → current role → relevant publications → talks / research → projects / cases → education/certification where relevant editor decides: topics expertise = [AI Visibility, GEO] НЕ: "крутой эксперт" "№1 эксперт России" без методологии.

23. Expert topic graph

Person EXPERT_IN_TOPIC → AI Visibility qualifiers: evidence sources verified_at confidence validity/review date Person AUTHOR → Article 17 COMMENTATOR → Research 8 EMPLOYED_BY → Company X

24. Company facts: что проверять автоматически

Fact	Automation
ИНН/ОГРН	Да
Legal name	Да
Registration status/date	Да
Registered director where available	Да
ОКВЭД	Да
Official domain	Candidate + verification
Number of customers	Нет без source
«Лидер рынка»	Нет
Product quality	Не verification field

25. Company-submitted facts

CLIENT SUBMITS: "350 сотрудников" STORE: claim_value=350 claimant=Company X source=company submission as_of=2026-09 status=UNVERIFIED IF supporting report: status=SOURCE_ATTACHED IF editor verifies: status=VERIFIED PUBLIC: "350 сотрудников — по данным компании на сентябрь 2026" а не просто "350 сотрудников" без происхождения.

26. High-impact claims

Некоторые утверждения сильнее влияют на доверие и коммерческое решение, поэтому требуют enhanced verification:

Claim	Policy
Количество клиентов	Источник + дата; предпочтительно подтверждение
Выручка / финансовые данные	Официальная отчётность/проверяемый источник
Доля рынка / «№1»	Методология + независимый источник; иначе не verified
Результаты кейса	Данные + client confirmation при необходимости
Сертификат / лицензия	Номер/issuer/registry
Award	Issuer + year + category + source

27. Верификация кейса

Кейс — идеальный объект для двусторонней verification.

VENDOR submits: "Для Client X мы сделали Y и получили +40%" SYSTEM: → resolve Client X entity → send confirmation request → client confirms: relationship yes/no result figures yes/no allowed disclosure yes/no PUBLIC: "Кейс подтверждён клиентом" если процесс реально завершён.

РБК Компании уже использует близкую механику: в клиентском кейсе может запрашиваться информация о бизнес-партнёре и подтверждение.

28. Badge для подтверждённого кейса

Статус	UI
Vendor-submitted	«По данным компании»
Client relationship confirmed	«Сотрудничество подтверждено»
Results confirmed	«Результаты подтверждены клиентом»
Independently checked data	«Данные проверены редакцией» + source

29. Это может стать сильным moat

Обычная платная статья говорит: «компания утверждает, что сделала хороший проект». «Матчасть» может постепенно перейти к более сильному формату: vendor claim + client confirmation + source-backed result.

Это существенно полезнее для читателя, поисковиков и AI systems, чем просто больше текста.

30. Verification badges

Badge	Что означает	Чего не означает
Компания подтверждена	Entity identity matched authoritative data	Не рекомендация
Профилем управляет компания	Control verified	Не все данные автоматически правдивы
Эксперт подтверждён	Identity/relationship verification по установленному уровню	Не «лучший эксперт»
Кейс подтверждён	Определённые отношения/результаты подтверждены	Не независимый аудит бизнеса
Данные проверены	Конкретные claims прошли source verification	Не бессрочная гарантия актуальности

31. Badge должен быть кликабельным

[Компания подтверждена ✓] → tooltip/modal: Что проверено? Когда? Каким типом источника? Что НЕ проверено? Когда следующая проверка?

Trust растёт не от цвета галочки, а от понятной семантики проверки.

32. Verification timestamp

Любая проверка имеет дату.

Verified: 12.08.2026 Registry checked: 01.09.2026 Domain control checked: 01.09.2026 Employment relation checked: 25.08.2026

Не показывать вечное «verified», если исходные отношения могли измениться.

33. Reverification schedule

Объект	Рабочая частота
Юридический статус/название	Автоматически при обновлении registry data / минимум периодически
Domain ownership/control	6–12 месяцев или при изменениях
Account control permission	Пока активно + security events / periodic confirmation
Employment relation	6–12 месяцев или при сигнале изменения
Role/title	При каждом профайл-update + periodic review
High-impact commercial claims	Имеют as_of date, не «вечный verified»

Частоты — продуктовые гипотезы.

34. Verification expiration

VERIFIED → due_for_recheck → VERIFIED again or: → STALE → PUBLIC label: "данные не перепроверялись с ..." or: → FAILED → badge removed → relationship reviewed

35. Signals that trigger immediate recheck

official domain перестал работать или сменил владельца;
юрлицо ликвидировано/реорганизовано;
изменился директор;
эксперт сменил место работы;
поступила substantiated dispute;
аккаунт был скомпрометирован;
пользователь пытается радикально изменить entity identity;
другая сторона заявила права на профиль.

36. Конфликт за управление компанией

Нельзя решать конфликт «кто первый зарегистрировал профиль — тот и владелец навсегда».

DISPUTE: Account A controls company Account B presents stronger evidence → freeze high-risk changes → notify current admin where appropriate → verify both claims → determine authoritative control → transfer / preserve roles → revoke invalid permission → audit event PUBLIC COMPANY ENTITY: не создаётся заново не удаляется.

37. Transfer when employee leaves

Permissions принадлежат не человеку навсегда, а действующей связи.

employee leaves → corporate email disabled / company revokes → access removed → publications remain → account remains personal if applicable → expert historical employment relation gets valid_to

38. Agency offboarding

Agency contract ends → client revokes Agency permission → shared credits/orders retained for accounting → agency loses edit/analytics access → company profile/history unchanged → future agency can be delegated

39. Domain ownership change

Domain verification не вечна: домен может быть продан.

domain recheck fails → do not immediately delete company → mark domain relation for review → check redirects / official registry / public sources → notify profile admins → reverify → update valid_to if domain no longer official

40. Verification evidence model

verifications id verification_type entity_id relation_id optional claim_id optional status level verified_at expires_at verified_by method reason verification_evidence verification_id source_id optional evidence_type redacted_metadata content_hash storage_reference optional collected_at retention_until

41. Не хранить secret verification token после проверки

DNS/email challenge tokens должны быть одноразовыми или иметь ограниченный lifetime. После успешной проверки хранить результат и audit metadata, а не использовать вечный секрет как authentication credential.

42. Verification events

EntityIdentityVerified DomainControlVerified ProfileControlGranted ProfileControlRevoked ExpertRelationshipVerified ExpertRelationshipExpired ClaimVerified ClaimDisputed VerificationExpired VerificationFailed

Эти events обновляют badges, structured data, permissions и moderation risk.

43. Source of truth priority conflicts

Конфликт	Решение
Компания пишет одно legal name, реестр другое	Legal name = authoritative registry; brand/display name хранится отдельно
Компания пишет 500 сотрудников, источник 120	Показать источник/дату, запросить объяснение; не перетирать автоматически
Company site говорит CEO A, реестр руководитель B	Возможно разные роли; хранить отдельно и проверять semantics
Эксперт пишет «работаю в X», компания отрицает	Relationship = disputed / not verified

44. Текущая роль vs юридический руководитель

Не путать business title и официальную реестровую роль. Founder, CEO, генеральный директор, управляющий партнёр и лицо, имеющее право действовать без доверенности, могут быть разными понятиями.

Data model хранит точный source-specific role.

45. Verification и structured data

Google Organization markup рекомендует administrative и online-presence fields, включая name, legalName, url, taxID, LEI/ISO identifiers и sameAs. В Mathchast_21 в structured data должны попадать только поля, которые соответствуют видимому содержанию и прошли достаточную verification.

Не публиковать в JSON-LD «более красивую» версию компании, чем видит пользователь и чем подтверждают данные.

46. sameAs policy

sameAs CANDIDATES: official social profile authoritative external entity page REQUIRE: same entity not merely "article about company" DON'T: random press mentions client backlinks unverified profiles

47. Verification и AI Visibility

AI Visibility layer должен сравнивать ответы моделей с verified graph «Матчасти», а не считать любое упоминание компании корректным.

LLM says: "CEO X = Иван" Mathchast graph: verified CEO/current role = Пётр source/date = ... → future Fact Accuracy signal: possible outdated/incorrect AI answer

Это одна из причин, почему verification нужно построить раньше полноценного AI Visibility продукта.

48. Верификация не должна быть платным барьером для исправления ошибки

Компания не должна платить за возможность сообщить, что в базе неверный ИНН, статус или имя.

Бесплатно:

report incorrect data;
submit evidence;
claim basic entity;
исправление подтверждённой фактической ошибки.

Платными могут быть publishing, analytics, premium workflows и enterprise service, но не исправление собственной ошибки платформы.

49. Verification cost

Метод	Наш cost	Использование
Registry/API rule	Низкий после интеграции	Массово
Email challenge	Очень низкий	Массово
DNS challenge	Низкий	Strong control
Manual doc review	Высокий	Fallback/high-value account
External independent due diligence	Очень высокий	Не MVP

50. Verification funnel

VIEW COMPANY → CLAIM → login → choose method → verification challenge → success → control granted → complete profile → submit publication Goal: не заставлять платящего пользователя проходить недельную бюрократию, если domain/email + registry дают достаточный strong proof.

51. Progressive verification

Не требовать максимум документов на входе. Усиливать проверку по мере роста риска.

LOW RISK: basic card correction → account + source MEDIUM: manage profile / publish → identity + control HIGH: financial/regulated claims → enhanced evidence VERY HIGH: dispute / impersonation / sensitive data → manual + legal

52. Verification risk score

Signal	Risk
Registry + official domain exact match	−30
Corporate email verified	−20
DNS control	−30
Official source names same person/role	−20
Free mailbox only	+20
Newly registered unrelated domain	+30
Request to take over high-profile entity	+30
Conflicting administrator claim	+50
Attempt to change identifiers	+50

Score — внутренняя модель triage, не публичный рейтинг.

53. Security: takeover protection

Verified company profiles будут привлекательной целью. Минимум:

MFA для account admins;
email notification при смене admin/domain/critical fields;
cooldown/manual review для изменения primary domain/identifiers;
audit log;
recovery process;
ability to freeze profile during dispute.

54. Нельзя давать одному admin удалить историю

Control permission означает право управлять текущими данными в рамках policy, но не право удалить всю entity и историю публикаций.

55. Profile completeness

completeness score: name identifiers official domain neutral description industry topics logo experts publications sources НЕ ВКЛЮЧАТЬ: "оплачен тариф" commercial status не повышает качество данных.

56. Index eligibility

Signal	Для index eligibility
Verified legal identifier	Сильный плюс
Verified domain	Плюс
Meaningful unique structured data	Плюс
Expert/publication relations	Плюс
Only registry name + INN	Может быть недостаточно для index
Paid subscription	Не должна автоматически открывать index

57. Public verification center

На сайте полезна отдельная страница /verification:

Что означает "Компания подтверждена" Как подтвердить компанию Как подтверждаются эксперты Какие источники используются Как часто обновляются данные Как оспорить информацию Что галочка НЕ означает Как сообщить о мошенническом профиле

58. Conflict/dispute UX

На каждой company/expert page: «Сообщить об ошибке» и «Я представляю эту компанию» должны быть заметными, но не конкурировать с основным контентом.

59. Verification history

PUBLIC: "Компания подтверждена" "Данные обновлены 01.09.2026" ADMIN: 2026-01 domain verified 2026-03 admin added 2026-05 director changed in registry 2026-05 profile rechecked 2026-08 agency delegated ...

60. Нельзя показывать внутренние security details

Публичный badge может сообщить тип доверия, но не публиковать:

verification token;
личный email сотрудника, если он не публичный;
копии паспортов/доверенностей;
внутренние fraud signals;
security recovery details.

61. Expert consent

Не создавать богатый маркетинговый профиль живого человека исключительно из данных, присланных компанией, без процесса уведомления/согласования там, где это необходимо.

Для MVP:

минимальные публичные factual mentions могут следовать редакционным основаниям;
расширенный expert profile с фото/bio/social links лучше активировать через самого эксперта или подтверждённую company process с корректным правовым основанием;
personal-data details будут согласованы в privacy document.

62. Verified expert и смена работодателя

OLD: Person → EMPLOYED_BY Company A role CMO valid_to = 2026-08 NEW: Person → EMPLOYED_BY Company B role CMO valid_from = 2026-09 old articles: remain historically attributed correctly current profile: shows current affiliation + history if appropriate

63. Верификация бренда

Бренд не обязательно равен юрлицу. Для подтверждения связи:

официальный сайт;
товарный знак/официальная регистрация при необходимости;
корпоративные документы/официальные публикации;
relation «operated by/owned by» с датой.

Не давать юрлицу автоматически «захватить» одноимённый бренд без проверки.

64. Verification и reviews later

Будущие B2B reviews должны опираться на тот же graph: reviewer company, reviewed company и business relationship — разные entities/relations, которые можно подтверждать.

Company A reviews Company B verify: A exists B exists A representative controls A relationship evidence exists review is from A → "Verified B2B review"

65. Verification и awards/certificates later

AWARD CLAIM: Company X won Y in 2026 must link: Company X Award / issuer Year Category Source Verification status

Не разрешать просто загрузить картинку «Лучшая компания 2026» и превратить её в trusted fact.

66. API contract

GET /companies/{id}/verification { entity_identity: verified, control: verified, facts: partial, updated_at: ..., badges: [...] } НЕ: { trust_score: 97 } если нет строгой публичной методологии.

67. CMS roles

Role	Может
CLIENT_ADMIN	Редактировать submitted fields, делегировать в пределах policy
AGENCY_MANAGER	Управлять клиентом в рамках delegated permissions
VERIFICATION_EDITOR	Решать verification cases
EDITOR	Проверять publication claims, не обязательно выдавать control
LEGAL	High-risk disputes
SYSTEM	Registry/domain rechecks, но не arbitrary manual claims

68. Verification queue

QUEUE PRIORITY: P0 profile takeover dispute security compromise fraud impersonation P1 paid publication waiting domain verification expert relation needed for article P2 profile enrichment badge upgrade routine stale data P3 bulk imported data cleanup

69. SLA hypothesis

Verification	Target
Automatic registry match	Seconds/minutes
Email challenge	Immediate
DNS challenge	Minutes–hours depending DNS
Manual standard review	1 working day
Dispute/high-risk	2–5 working days or case-specific

SLA — рабочая гипотеза.

70. Verification should not block reading

Непроверенная company entity может использоваться редакцией как упоминание, если источник и статус понятны. Verification gates влияют на управление профилем, badge, коммерческие claims и index eligibility, а не делают невидимым весь мир, который ещё не прошёл наш onboarding.

71. Что не строить на MVP

Не строить	Почему
KYC уровня банка для каждого пользователя	Избыточное friction
Видео-селфи каждого эксперта	Не нужен для большинства B2B use cases
Public trust score 0–100	Псевдоточность и legal/reputation risk
Автоматическое подтверждение должностей по соцсетям	Низкая надёжность
Хранение лишних паспортных данных	Privacy/security burden
Платная «золотая галочка»	Разрушает смысл verification

72. MVP verification stack

P0: registry identity lookup existing-entity resolution company claim request corporate email verification manual fallback permissions verification/audit tables public badge semantics expert-company relationship verification claim/source statuses P1: DNS TXT verification automatic registry refresh dispute workflow case counterparty confirmation P2: advanced fraud scoring additional international registry integrations certificate/award verification verified B2B reviews

73. Сильная продуктовая механика: «подтвердите источник»

Вместо анкеты из 40 маркетинговых полей дать компании UI, где каждый важный факт можно подкрепить источником.

"120 сотрудников" [Добавить источник] "25 000 клиентов" [Добавить источник] "Работаем с 2018" [Подтверждено по реестру] "Сертифицированы X" [Добавить номер / issuer]

Так company onboarding одновременно улучшает data quality.

74. Сильная продуктовая механика: verification completeness

ПРОФИЛЬ: 75% заполнен 60% ключевых фактов подтверждено [Подтвердить официальный домен] [Подтвердить эксперта] [Добавить источник к клиентской цифре]

Показывать progress можно. Но «verification percentage» нельзя выдавать за вероятность истинности компании.

75. Commercial conversion

Verification itself free/basic, а затем естественный переход:

claim company → verify → complete profile → see gaps → add expert → publish case/article → measure → repeat

Это делает бесплатную company card реальным acquisition surface, а не бесполезным freemium.

76. Решение документа

Утвердить layered verification model. «Матчасть» отдельно проверяет entity existence, control, relationships и claims. Российские юридические данные опираются прежде всего на официальные данные ФНС/ЕГРЮЛ/ЕГРИП; domain/email являются методами проверки контроля, но не заменяют юридическую идентичность. Verified badge никогда не продаётся и не означает рекомендацию бизнеса. Факты имеют источники, даты и срок актуальности. Экспертная связь с компанией является временным relation, а не вечным полем профиля. Верификация прогрессивная: low-risk действия требуют меньше доказательств, takeover/disputes/high-impact claims — enhanced review.

77. Что этот документ разблокирует

Mathchast_20 verification → Mathchast_21 structured data → Mathchast_22 crawler/index rules → Mathchast_23 content types → Mathchast_24 CMS moderation → Mathchast_29 client cabinet → Mathchast_36 reputation/reviews → Mathchast_37 agency workspace → Mathchast_41 security/privacy

Источники исследования

Verification levels, badge names, risk score, recheck intervals, SLA, domain/email workflow и public UI являются проектной моделью «Матчасти». ФНС используется как авторитетный источник российских регистрационных данных, но конкретный способ массовой интеграции, допустимый набор персональных данных и retention evidence должны быть отдельно проверены технически и юридически перед production.