МАТЧАСТЬ / CMS & MODERATION WORKFLOW / DOCUMENT 24 / 02.09.2026
CMS и moderation workflow «Матчасти»
Как устроить редакционную и коммерческую операционку: от идеи, анкеты и оплаченного заказа до публикации, маркировки, IndexNow, отчёта, исправлений и повторной покупки. Документ определяет состояния материала, роли, очереди, SLA, права клиента, работу редактора, fact-check, legal review, возвраты, версионирование, аудит и требования к интерфейсу CMS.
1 объектpublication проходит единый state machine независимо от того, кто заплатил
4 очередиstandard, enhanced, legal/high-risk и corrections/incidents
Human gateAI помогает собирать и проверять, но не публикует коммерческий материал самостоятельно
Audit firstкаждое критическое решение, правка и смена статуса оставляет историю
1. Главное решение
CMS «Матчасти» должна быть не текстовым редактором с кнопкой «Опубликовать», а workflow engine. Внутри одного объекта publication связываются: контент, entities, claims, sources, права, legal classification, рекламная маркировка, коммерческий заказ, ссылки, structured data, index state, публикационный lifecycle и analytics.
INPUT
idea / client order / questionnaire / editorial assignment
↓
DRAFT
↓
AUTOMATED PRECHECK
↓
EDITORIAL TRIAGE
↓
FACT / SOURCE REVIEW
↓
LEGAL & AD REVIEW if needed
↓
FINAL EDITOR
↓
READY
↓
PUBLISH
↓
DISCOVERY
↓
MONITORING
↓
CORRECTIONS / REPORTING / NEXT ACTION
2. Почему CMS является ядром бизнеса
Самый опасный сценарий для «Матчасти» — сделать красивый сайт, оплату и AI-редактор, а модерацию оставить в Telegram/Google Docs. Тогда невозможно доказать, кто что одобрил, какой текст был оплачен, какие claims проверены, почему материал получил статус рекламы, откуда взялась ссылка и какая версия ушла в публикацию.
Если workflow существует только «в голове редактора», масштабирование до 20–100 публикаций в месяц быстро разрушит качество и compliance.
3. Что показывает РБК Компании
В текущем workflow РБК Компании пользователь выбирает формат, сохраняет черновик или отправляет материал на модерацию. Если материал не проходит проверку, пользователь получает комментарий и дорабатывает его. Сервис публично указывает обычный срок рассмотрения до 3 часов, а в отдельных случаях — до 2 суток. Редакция может делать небольшие корректировки заголовка, анонса и текста, а значительные изменения требуют повторной модерации.
Для нас важен сам паттерн: Draft → Submit → Moderator decision → Changes/Approve → Publish, но «Матчасть» добавляет к нему entity verification, sources, legal classification, ad workflow, link policy и measurement.
4. Что показывает Хабр
Хабр описывает ручную проверку публикаций по нескольким признакам: оформление, факты при сомнениях, реклама/реферальные ссылки, тематическая релевантность. Модераторы используют внутренний флаг проверки, часть материалов требуют более тщательного чтения, а решения можно обжаловать.
Для «Матчасти» полезен принцип risk-based moderation: не каждый материал требует одинаковых 40 минут, но ни один коммерческий материал не должен обходить обязательные policy checks.
5. Один publication object, несколько процессов
PUBLICATION
├─ content state
├─ editorial state
├─ legal state
├─ verification state
├─ commercial order state
├─ link state
├─ index state
├─ publication lifecycle
└─ measurement state
НЕ НУЖНО:
одно поле status="approved"
которое означает сразу всё.
6. Почему одно поле status не работает
| Ситуация | Content | Legal | Commerce | Publish |
|---|---|---|---|---|
| Текст хороший, ждём erid | APPROVED | AD_PENDING_ERID | PAID | BLOCKED |
| Редакционная статья готова | APPROVED | EDITORIAL | NONE | READY |
| Кейс оплачен, но цифры не подтверждены | FACT_CHECK | REVIEW | PAID | BLOCKED |
| Статья опубликована, но потом исправляется | CORRECTION | UNCHANGED | COMPLETE | ACTIVE |
7. Editorial state machine
IDEA
→ DRAFT
→ SUBMITTED
→ PRECHECK
→ TRIAGE
→ NEEDS_DATA
→ EDITORIAL_REVIEW
→ NEEDS_CHANGES
→ FACT_CHECK
→ ENHANCED_REVIEW
→ APPROVED
→ FINAL_PROOF
→ READY
terminal/side states:
REJECTED
WITHDRAWN
ON_HOLD
8. Publication lifecycle state machine
READY
→ SCHEDULED
→ PUBLISHED
→ ACTIVE
then:
UPDATED
CORRECTED
ARCHIVED
SUPERSEDED
MOVED
LEGAL_HOLD
TAKEDOWN_PENDING
REMOVED
Этот слой наследует правила Mathchast_16.
9. Commercial order state
ORDER_CREATED
→ PAYMENT_PENDING
→ PAID
→ MATERIAL_REQUIRED
→ SERVICE_IN_PROGRESS
→ PLACEMENT_READY
→ PUBLISHED
→ REPORTING
→ COMPLETED
alternatives:
CANCELLED
REJECTED_CREDIT_RETURNED
PARTIAL_REFUND
FULL_REFUND
DISPUTED
10. Legal state
UNCLASSIFIED
→ EDITORIAL
→ DIRECTORY_INFORMATION
→ BORDERLINE_REVIEW
→ ADVERTISING
→ RESTRICTED_REVIEW
→ REJECTED_LEGAL
if ADVERTISING:
advertiser resolved
contract resolved
ORD ready
erid ready
disclosure ready
reporting ready
11. Verification state
UNVERIFIED
→ SOURCE_ATTACHED
→ PARTIALLY_VERIFIED
→ VERIFIED
or:
DISPUTED
FAILED
STALE
Верификация относится к claims/relations/entities и не должна заменяться общим approval материала.
12. Четыре очереди модерации
| Queue | Что попадает | Кто рассматривает |
|---|---|---|
| STANDARD | Обычная статья, экспертное мнение, нормальный кейс без сложных claims | Editor |
| ENHANCED | Paid partner, сравнение, чувствительные утверждения, новый topic, сложный кейс | Senior editor |
| LEGAL/HIGH-RISK | Регулируемые темы, обвинения, медицинские/финансовые claims, спорная реклама | Senior + Legal; на MVP часто reject |
| CORRECTIONS/INCIDENTS | Ошибки в уже опубликованных материалах, takedown, broken disclosures | Priority editor + Legal/Tech по необходимости |
13. Risk-based routing
risk signals:
paid placement
regulated topic
negative accusation
financial claim
medical claim
comparison
"best / №1"
high-impact metric
unknown source
out-of-scope topic
SEO-link request
duplicate press release
unverified expert
new advertiser
legal dispute
score / rules
→ STANDARD
→ ENHANCED
→ HIGH-RISK
14. Queue priority
P0:
wrong ad marking
legal takedown
false critical fact
malware link
published page unavailable
P1:
paid order waiting
scheduled publication
high-priority correction
P2:
standard editorial submission
profile changes
P3:
seed content enrichment
bulk imported entity cleanup
15. SLA на MVP
| Операция | Рабочая гипотеза |
|---|---|
| Automated precheck | До нескольких минут |
| Initial human triage | До 1 рабочего дня |
| Standard moderation | 1 рабочий день |
| Повтор после обычных правок | 1 рабочий день |
| Enhanced review | До 2 рабочих дней |
| Legal/high-risk | 2–5 рабочих дней / case-by-case |
| Critical correction | Немедленный приоритет |
РБК Компании заявляет до 3 часов в обычной ситуации и до 2 суток в отдельных случаях. Для нового проекта безопаснее сначала обещать менее агрессивный SLA и улучшать его по данным.
16. SLA clock
Нужно чётко определить, когда часы SLA идут, а когда остановлены.
SLA RUNNING:
material submitted
all required fields present
client responded
no external dependency
SLA PAUSED:
NEEDS_DATA from client
waiting advertiser docs
waiting client case confirmation
waiting legal clarification
Dashboard:
"Ожидаем вас"
не считается просрочкой редакции.
17. Assignment model
publication
→ queue
→ assignee
→ backup assignee
→ due_at
→ priority
→ risk flags
→ workload estimate
Редактор должен видеть не просто список статей, а очередь с причинной приоритизацией.
18. Editor dashboard
TODAY
P0 incidents: 1
Due today: 7
Paid waiting: 4
Needs legal: 2
Corrections: 3
Standard: 11
filters:
format
topic
client
risk
legal status
assignee
deadline
commercial / editorial
verification missing
19. Карточка публикации в CMS
HEADER
title
format
client/entity
order
risk
current state
due time
TABS:
Content
Entities
Claims
Sources
Links
Visuals
Legal
Commercial
Machine View
Versions
Comments
Audit
Analytics after publish
20. Content tab
Редактор работает с typed blocks из Mathchast_23, видит форматные подсказки, inline comments, tracked changes и предупреждения.
BODY
+
format checklist
+
reader job
+
main claim
+
missing required fields
+
AI flags
+
editor comments
21. Entities tab
Company X
relation: VENDOR_IN_CASE
verified: yes
Company Y
relation: CLIENT_IN_CASE
verified: partial
Person Z
relation: AUTHOR
employment relation: verified
Topic:
AI Visibility
approved topic node
22. Claims tab
CLAIM #14
"конверсия выросла на 34%"
impact: HIGH
source: client analytics screenshot
verification: SOURCE_ATTACHED
counterparty confirmation: pending
public wording:
"по данным компании..."
editor decision:
ACCEPT / NEED_MORE / REMOVE
23. Sources tab
SOURCE
official report
registry
company document
media
research
questionnaire
interview transcript
fields:
URL / file
publisher
date
retrieved_at
supports claims
trust tier
verification
notes
24. Links tab
Применяет Mathchast_17 автоматически.
client.ru/product
ROLE: ADVERTISER
COMMERCIAL: yes
REL: sponsored
HTTP: 200
FINAL DOMAIN: client.ru
rosstat.gov.ru/report
ROLE: EDITORIAL_SOURCE
COMMERCIAL: no
REL: —
HTTP: 200
Клиент не может отредактировать поле
rel через rich text.25. Visuals tab
cover
source
rights
creator
AI generated?
documentary?
alt
crops
usage rights
verification
asset hash
26. Legal tab
legal_status
classification_reason
advertiser_entity
payer
agency
contract
ORD
erid
disclosure
restricted category
legal reviewer
reporting state
27. Commercial tab
order_id
SKU
price
credits
payment
editing service
distribution add-on
monitoring window
refund eligibility
agency/client split
28. Machine View tab
canonical
robots
index state
JSON-LD preview
schema warnings
sitemap class
IndexNow event
crawler access
OpenGraph
publication health
29. Versions tab
v1 submitted by client
v2 editor cleanup
v3 client revision
v4 fact-check corrections
v5 approved
v6 published
v7 correction 12.10.2026
diff each version
who
why
timestamp
30. Comments: private vs client-visible
| Comment type | Кому виден |
|---|---|
| EDITORIAL_INTERNAL | Редакции |
| LEGAL_INTERNAL | Legal + senior editor |
| CLIENT_REQUEST | Клиенту |
| FACT_CHECK_INTERNAL | Редакции |
| RESOLUTION_NOTE | По настройке |
Не отправлять клиенту внутреннюю фразу вроде «кажется, это сомнительный рекламодатель» из-за одного неверного типа комментария.
31. Triage screen
MODERATOR answers:
1. Format correct?
2. Topic in scope?
3. Reader value present?
4. Obvious pure promo?
5. Duplicate?
6. Legal/ad signals?
7. Sources enough?
8. High-risk claims?
9. Entity verified?
10. Links policy okay?
OUTPUT:
STANDARD
ENHANCED
NEEDS_DATA
REJECT
LEGAL
32. Автоматический precheck до человека
AI/automation должны убирать механическую работу, а не принимать редакционное решение.
PRECHECK:
required fields
format mismatch
broken URLs
duplicate similarity
source count
claim extraction
entity extraction
title issues
prohibited phrases
promo signals
exact-match anchors
legal keywords
restricted categories
image metadata
AI-generated content signals
topic distance
Context Bridge flag
33. Topic-distance flag
Idea 001 можно встроить прямо в moderation workflow.
new publication
→ semantic topic distance
→ far from current graph?
NO:
normal flow
YES:
flag NEW_TOPIC_OUTLIER
→ editor checks:
is topic strategically relevant?
need Context Bridge?
create topic node?
reject as out of scope?
34. Field Snapshot workflow
Idea 002 также требует отдельной CMS-механики.
QUESTIONNAIRE CAMPAIGN
→ participants
→ consent
→ entity resolution
→ claims
→ verification sample
→ dataset
→ aggregation
→ editorial analysis
→ publication
→ participant notification
→ recurring wave later
35. Questionnaire campaign object
campaign_id
title
topic
target segment
open_from / until
questionnaire_version
participant_count
eligibility rules
consent_version
research_label:
survey / snapshot / research
editor
dataset_id
publication_id
36. Participant moderation
response
→ spam/fraud check
→ entity resolution
→ eligibility
→ consent
→ outlier check
→ optional clarification
→ accepted / excluded
exclusion reason stored:
duplicate
outside sample
fake
incomplete
conflict
consent missing
37. Client submission flow
ORDER PAID
→ choose format
→ questionnaire or upload draft
→ client sees required fields
→ SUBMIT
→ precheck
→ moderator
→ changes requested
→ client edits
→ resubmit
→ approve
→ legal/ad completion
→ publish
38. Editor-created-for-client flow
PAID
→ brief
→ interview/source collection
→ editor draft
→ internal review
→ client FACT CHECK
→ client does not buy editorial conclusion
→ final editor
→ legal
→ publish
На клиентском согласовании важно формулировать: клиент проверяет фактическую корректность своих данных, а не получает право переписать материал в рекламный буклет.
39. Client approval types
| Approval | Что означает |
|---|---|
| FACTS_CONFIRMED | Компания подтверждает свои фактические данные |
| QUOTE_APPROVED | Спикер согласовал цитату при используемой процедуре |
| CLIENT_CASE_CONFIRMED | Контрагент подтвердил сотрудничество/результат |
| FINAL_TEXT_ACKNOWLEDGED | Клиент видел финальную версию; не обязательно имеет veto на editorial |
40. Changes requested — только с кодами
Не отправлять клиенту «доработайте статью». Система должна указывать причины.
NEEDS_CHANGES reasons:
MISSING_SOURCE
UNVERIFIABLE_CLAIM
PURE_PROMO
FORMAT_MISMATCH
NO_READER_VALUE
LINK_POLICY
TITLE_MISLEADING
DUPLICATE
OUT_OF_SCOPE
LEGAL_INFO_REQUIRED
CLIENT_CONFIRMATION_REQUIRED
IMAGE_RIGHTS
STRUCTURE
LANGUAGE
41. Rejection codes
Из Mathchast_14:
NO_READER_VALUE
PURE_PROMO
SEO_LINK_REQUEST
OUT_OF_SCOPE
UNVERIFIABLE_CLAIMS
DUPLICATE
LEGAL_RISK
CONFLICT_ATTACK
AI_LOW_VALUE
additional:
FAKE_IDENTITY
RESTRICTED_CATEGORY
RIGHTS_FAILURE
REPEATED_POLICY_BREACH
42. Rejection explanation
Внешнее сообщение должно быть конкретным, профессиональным и достаточно понятным для исправления, но не обязано раскрывать fraud/security heuristics.
PUBLIC:
"Материал отклонён: основная часть текста
состоит из описания преимуществ услуги,
а самостоятельная информационная ценность
для читателя не сформирована."
INTERNAL:
promo pattern
link-builder account
3 duplicate placements
risk score 72
43. Appeal
Хабр допускает обжалование решения модерации. «Матчасти» тоже нужен минимальный appeal workflow, особенно для платных заказов.
REJECTED
→ [Запросить пересмотр]
→ reason from client
→ second reviewer
→ decision:
UPHOLD
RETURN_FOR_CHANGES
OVERTURN
original moderator
не должен быть единственным
финальным reviewer appeal.
44. Не делать бесконечные циклы правок
Коммерческий SKU должен определить разумное количество итераций.
Publish:
2 standard revision cycles included
если клиент:
игнорирует правила
или полностью меняет тему
→ new scope / paid editing
fact correction:
не считается коммерческой итерацией
и может подаваться всегда.
Количество итераций — продуктовая гипотеза для Mathchast_30/31.
45. Editing mode
| Тип правки | Может сделать редактор без согласования? |
|---|---|
| Опечатка/пунктуация | Да |
| Небольшая читабельность | Да, если смысл не меняется |
| Заголовок без смены смысла | Да по policy; для paid можно показать клиенту |
| Удаление неподтверждённой цифры | Сообщить / запросить источник |
| Изменение факта | Только после проверки источника |
| Смена commercial claim | Legal/client workflow |
46. Track changes
Для клиента нужен простой diff: что изменилось и почему. Это снижает конфликт «вы переписали мой текст».
removed:
"мы лучшие на рынке"
added:
"компания работает в сегменте..."
reason:
UNVERIFIABLE_CLAIM / editorial neutrality
47. Fact-check workflow
extract claims
→ classify impact
→ attach sources
→ verify source date/context
→ check units
→ resolve entity
→ conflicts?
→ decide public wording
→ mark verified/source-attributed
→ final editor
48. High-impact claims
| Claim | Gate |
|---|---|
| «№1 на рынке» | Independent methodology or remove |
| Финансовый результат | Source + period |
| Рост клиента +80% | Baseline + method + source; client confirmation desirable |
| Негативное обвинение | Documents + right of reply + senior/legal |
| Медицинская эффективность | MVP usually reject/high-risk |
49. Right of reply workflow
material materially criticizes Entity X
→ create RIGHT_OF_REPLY request
→ recipient
→ sent_at
→ deadline
→ response
→ included / declined / no response
→ editor note
Publish decision:
does not necessarily require response,
but real effort must be recorded.
50. Legal classification before final publish
Legal classification нельзя делать после публикации, когда статья уже разошлась по поисковикам.
before READY:
legal_status resolved
advertiser resolved if ad
disclosure generated
erid valid if required
outbound commercial links sponsored
restricted category cleared
rights confirmed
51. Ad workflow
ADVERTISING
→ advertiser entity
→ contract
→ creative/publication metadata
→ ORD
→ erid
→ render disclosure
→ publish
→ collect stats
→ act/reporting
→ compliance archive
52. Hard publish gates
BLOCK PUBLISH IF:
required format fields missing
legal_status unresolved
ad requires erid and none
advertiser missing
critical source missing
image rights unresolved
canonical invalid
no responsible author/editor
commercial link policy violation
client entity impersonation dispute
malware destination
scheduled embargo not reached
53. Soft warnings
WARN BUT MAY PUBLISH:
low number of sources in opinion
topic distance high but editor approved
image aspect fallback only
expert profile incomplete
optional schema property missing
AI suggested better title
54. Publish button должен объяснять блокировку
Не серый disabled button без причины.
Нельзя опубликовать:
✓ текст одобрен
✓ источники
✕ отсутствует ERID
✓ canonical
✕ не подтверждены права на обложку
[Перейти к ERID]
[Заменить обложку]
55. Four-eyes principle
Для high-risk публикаций человек, подготовивший материал, не должен единолично финально одобрять его.
| Risk | Approval |
|---|---|
| Standard editorial | 1 editor |
| Paid partner standard | Editor + automated legal checks |
| Enhanced claim/comparison | Senior editor |
| High-risk legal | Senior + Legal |
| Appeal | Different reviewer |
56. Roles
| Role | Права |
|---|---|
| CLIENT_AUTHOR | Создаёт/редактирует свои drafts, отвечает на запросы |
| CLIENT_ADMIN | Управляет company submissions и users |
| AGENCY_MANAGER | Работает с delegated client entities |
| EDITOR | Moderation, edits, fact-check |
| SENIOR_EDITOR | Enhanced review, appeals, exceptions |
| LEGAL | Legal/ad classification, takedown |
| VERIFICATION_EDITOR | Entity/claim verification |
| COMMERCIAL | Order/SKU/payment context, без права менять editorial decision |
| ADMIN | System-level |
57. Separation of duties
Продажник не должен иметь кнопку «опубликовать несмотря на модерацию».
COMMERCIAL:
can see status
can communicate SLA
can manage order
cannot:
override factual rejection
remove ad label
change sponsored rel
grant Editorial Pick
58. Emergency override
Если нужен admin override, он должен требовать:
reason
responsible admin
second approval for critical state
audit event
automatic alert
NOT:
hidden "force publish" button
59. Scheduled publication
APPROVED
→ choose datetime
→ freeze final version
→ pre-publish health check 5–15 min before
→ publish worker
→ verify 200/canonical/schema/disclosure
→ IndexNow/sitemap
→ notify stakeholders
60. Embargo
Для новости/исследования позже может понадобиться embargo.
embargo_until
preview access restricted
not sitemap
not IndexNow
no public route leakage
publish automatically after time
audit access
61. Post-publish automated checks
T+0:
HTTP
canonical
robots
structured data
disclosure
link rel
assets
T+5m:
sitemap
IndexNow response
T+1h:
crawler/log health as available
later:
search observations
analytics
AI observations
62. Failed publish
publish job fails
→ state PUBLISH_FAILED
→ alert editor/tech
→ do not mark order completed
→ retry if safe
→ rollback if partial
→ incident log
63. Partial publish is unacceptable
Ситуация «страница уже доступна, а рекламная маркировка не успела загрузиться» должна считаться критической архитектурной ошибкой.
Legal disclosure и required metadata формируются server-side в одной транзакционной публикационной версии.
64. Correction workflow
REPORT
→ classify:
typo
factual
material update
legal
privacy
link/security
→ assign
→ verify
→ patch draft version
→ approve
→ publish new version
→ visible note if needed
→ update lastmod / IndexNow if significant
65. Correction SLA
| Correction | Priority |
|---|---|
| Опечатка | Normal |
| Ошибка в имени/цифре | High |
| Неверное обвинение | Critical |
| Сломанная ad маркировка | Critical |
| Malware link | Critical |
66. Public correction note
CORRECTION:
"В предыдущей версии материала
была неверно указана выручка компании.
Правильное значение — ...
Исправлено 12.10.2026."
ADMIN:
before/after
source
editor
requester
reason
67. Client correction request
Клиент может всегда сообщить о фактической ошибке. Это не считается платной «итерацией правок».
Коммерческие пожелания после публикации идут другим маршрутом:
"исправьте ошибку" → CORRECTION
"сменился официальный домен" → ENTITY/LINK UPDATE
"давайте перепишем статью под новый продукт" → NEW PUBLICATION / PAID UPDATE
68. Takedown workflow
TAKEDOWN REQUEST
→ requester verification
→ reason
→ legal/editorial review
→ freeze risky edits
→ choose:
correct
anonymize
archive
redirect
remove
reject request
→ decision log
→ public/HTTP lifecycle action
69. Audit log
actor
timestamp
object
action
before
after
reason
IP/session/request ID where appropriate
related order
related verification
related ticket
Для ключевых событий audit log должен быть append-only на уровне приложения и защищён от обычного редактирования через CMS.
70. Что обязательно аудировать
- publication approval/rejection;
- legal status changes;
- advertiser/erid changes;
- removal of sponsored rel;
- entity merge;
- verification grant/revoke;
- admin permission changes;
- published text changes;
- takedown;
- refund/credit return;
- force override.
71. Publication lock
Пока редактор проверяет конкретную версию, клиент не должен незаметно заменить текст под ним.
submitted_version = v5
locked for review
client wants edits:
→ withdraw submission
or
→ create v6 draft
reviewer approval
always references exact content_hash.
72. Optimistic editing + version conflict
В интерфейсе можно позволить параллельную работу, но при сохранении:
editor edits v5
client edits v5
→ detect base_version conflict
→ merge/diff required
→ no silent last-write-wins
73. Internal checklist automation
CASE:
✓ vendor
✓ problem
✓ process
✕ result source
✓ client relation
✕ limitations
RESEARCH:
✓ methodology
✓ sample
✕ limitations
✓ dataset
✓ sponsor disclosure
Это делает Mathchast_23 реальным продуктом, а не документом, который никто не открывает.
74. Saved response templates
| Template | Пример смысла |
|---|---|
| PURE_PROMO | Уберите прайс, оффер и список преимуществ; добавьте процесс/данные |
| MISSING_SOURCE | Укажите источник для конкретной цифры |
| FORMAT_CASE | Добавьте problem/process/result |
| LINK_POLICY | SEO-anchor/dofollow не поддерживается |
| IMAGE_RIGHTS | Нужна информация о происхождении изображения |
75. Но ответы не должны быть безличным роботом
Шаблон помогает скорости, но редактор добавляет конкретный контекст: какая именно цифра, ссылка или фраза вызывает проблему.
76. Notification system
events:
needs_changes
approved
rejected
scheduled
published
report_ready
correction
verification_needed
payment_issue
channels:
in-app
email
later Telegram/business notifications optional
deduplicate:
do not send 12 emails
for 12 field warnings.
77. Client dashboard state labels
| Internal | Client sees |
|---|---|
| TRIAGE | «На проверке» |
| ENHANCED_REVIEW | «Расширенная проверка» |
| NEEDS_DATA | «Нужны данные от вас» |
| LEGAL_REVIEW | «Проверяем требования к публикации» |
| APPROVED | «Одобрено» |
| READY | «Готово к публикации» |
78. Не показывать клиенту всю внутреннюю бюрократию
Client UX должен быть проще внутреннего state machine. Внутренне у нас может быть 25 статусов, снаружи — 6–8 понятных состояний.
79. Moderation analytics
by week/month:
submissions
approval rate
rejection rate
needs changes rate
avg cycles
time to first response
time to publish
editor workload
format breakdown
risk breakdown
top rejection reasons
correction rate
legal escalation rate
client abandonment
80. Почему rejection rate = 0% — плохой сигнал
Если коммерческий сервис одобряет 100% материалов, moderation почти наверняка декоративная.
Но высокий rejection rate тоже может означать плохой onboarding. Хорошая система должна постепенно переводить часть отказов в precheck и better questionnaires.
81. Editor quality metrics
| Полезно | Опасно использовать как KPI |
|---|---|
| Correction rate | Количество одобренных статей в час без поправки на риск |
| Source completeness | Минимальное время на материал любой ценой |
| Appeal overturn rate | Нулевые отказы |
| SLA | Скрытие сложных кейсов ради SLA |
| Reader/business outcomes later | Трафик как единственный KPI редактора |
82. Workload estimation
STANDARD NEWS: 1 unit
ARTICLE: 2
CASE: 3
EXPERT: 2
RESEARCH: 5+
LEGAL HIGH RISK: 5+
CORRECTION: variable
Dashboard:
not just "12 items",
but estimated load.
83. Moderator trust tiers
Позже система может учитывать опыт автора/компании, как описывает Хабр: проверенные авторы требуют меньше внимания, нарушители — больше. Но это используется только для routing.
Trusted client никогда не получает bypass обязательных legal/ad/source checks.
84. Repeat offender logic
account history:
SEO-link requests
hidden ad attempts
post-publish link replacement
false claims
fake sources
→ trust risk increases
→ enhanced review
→ limit submissions
→ suspend publishing
not public score.
85. Post-publish manipulation detection
Хабр отдельно описывает попытки добавить рекламные ссылки после публикации. «Матчасть» должна технически исключить такой обход.
published content edits
→ cannot go live directly
→ new version
→ policy checks
→ link diff
→ legal diff
→ editor approval
→ republish
86. Link diff
v6:
client.ru/about
v7 request:
best-seo-casino.example/promo
SYSTEM:
new external domain
commercial destination changed
risk
→ block automatic update
→ enhanced review
87. Legal diff
published:
neutral case
edit adds:
price
discount
"купить"
product CTA
→ legal classification may change
→ cannot treat as ordinary correction.
88. Published content editing permissions
| Role | Direct live edit? |
|---|---|
| Client | Нет |
| Agency | Нет |
| Editor | Создаёт новую revision; typo fast-path possible |
| Senior | Revision + audit |
| System | Не меняет смысловой content autonomously |
89. Typo fast-path
editor selects text
→ typo correction
→ reason TYPO
→ no client approval
→ publish minor revision
→ admin history
→ no visible Correction note required
90. Significant edit path
significant content edit
→ new revision
→ affected claims/sources recalculated
→ link/legal checks
→ approval
→ dateModified
→ visible Updated/Correction note when appropriate
→ IndexNow
91. Refund integration
Editorial rejection и деньги должны быть связанными системно, но редактор не рассчитывает возврат вручную.
REJECTED
reason code
service work completed?
billing rules:
placement credit unused → return
editing work performed → retain according to terms
legal rejection before production → policy
platform fault → refund/credit
→ billing service creates result
Точная математика — Mathchast_31.
92. Credit consumption
publication credit:
RESERVED at submission
CONSUMED when approved/scheduled
RETURNED if rejected before placement
RELEASED if client withdraws under allowed terms
93. Agency bulk workflow
agency uploads 10 clients
→ each publication separate entity
→ each advertiser separate
→ each company permission checked
→ shared agency dashboard
→ per-item moderation
→ bulk status/reporting
НЕ:
"approve all 10 because same agency".
94. Batch operations
Bulk actions допустимы только там, где риск одинаков и действие обратимо.
| Bulk action | Можно? |
|---|---|
| Assign editor | Да |
| Add internal label | Да |
| Approve 100 articles | Нет |
| Change advertiser | Нет |
| Publish scheduled approved set | Worker can, after per-item gates |
95. Editorial calendar
calendar shows:
editorial seed
paid scheduled
research launches
Context Bridge pieces
Field Snapshot waves
embargoes
labels:
EDITORIAL
PARTNER
RESEARCH
NEWS
commercial inventory visible,
but not allowed to crowd out
reader product automatically.
96. Capacity guardrail
CMS должна уметь ограничить продажи, если редакционная мощность закончилась.
available moderation slots
editing capacity
legal capacity
checkout:
earliest publication date
based on actual queue
Не продавать:
"публикация завтра"
если очередь уже 40 материалов.
97. Topic mix guardrail
Ещё одно применение Idea 001: CMS может показывать editorial mix и предупреждать, если платные заказы резко уводят сайт в новую случайную тему.
last 30 days:
AI/SaaS 45%
Marketing 30%
Infrastructure 15%
Other 10%
new orders:
Dental clinics x14
→ OUT_OF_SCOPE / TOPIC_EXPANSION REVIEW
→ do not blindly publish.
98. Commercial/editorial ratio dashboard
Не использовать магический fixed ratio, но видеть состав корпуса:
editorial
contributed
paid advertising
sponsored research
Field Snapshot
by:
week
month
topic
homepage exposure
99. Distribution gate
PUBLISHED
does not automatically mean:
HOME FEATURED
separate decisions:
indexable
topic feed
organic recommendation
email digest
Telegram
promoted slot
Editorial Pick
Кнопка «Опубликовать» не должна автоматически продавать редакционное внимание.
100. Homepage selection
editorial selection:
quality
relevance
freshness
reader usefulness
originality
commercial boost:
separate inventory
marked
Never:
paid order → Editorial Pick flag.
101. API boundaries
Client API later:
create draft
upload assets
read state
respond to changes
fetch report
NO API:
force approve
set legal status
remove sponsored
publish without gate
102. CMS event bus
events:
PublicationSubmitted
PrecheckCompleted
NeedsChanges
PublicationApproved
LegalClassified
EridAssigned
PublicationScheduled
PublicationPublished
PublicationUpdated
CorrectionPublished
PublicationRemoved
listeners:
notifications
billing
sitemap
IndexNow
analytics
embeddings
search
reports
103. Technical consistency
PublicationApproved должен ссылаться на точную version_id. Иначе пользователь может изменить текст между approval и publish.
approve(version_id=53, hash=ABC)
schedule(version_id=53)
publish checks:
current approved hash = ABC
if not:
BLOCK / re-review
104. Draft autosave
Autosave удобен, но он не создаёт официальную editorial version при каждом нажатии клавиши.
working draft snapshots
→ ephemeral/recoverable
formal versions:
SUBMITTED
EDITOR_REVISION
APPROVED
PUBLISHED
CORRECTED
105. Preview environment
PREVIEW EXACT FINAL RENDER:
disclosure
images
links
schema
company cards
mobile
desktop
signed URL
noindex
not sitemap
not IndexNow
106. Client preview
Клиент должен видеть максимально близкий к финальному layout, особенно рекламную маркировку, а не согласовывать Word-файл, который потом выглядит иначе.
107. CMS search
search by:
publication title
company
expert
INN/OGRN
order ID
advertiser
erid
URL
source domain
claim text
editor
status
108. Saved views
"Мои сегодня"
"Ждут клиента"
"Paid overdue"
"Legal"
"Corrections"
"New topic outliers"
"Missing sources"
"Scheduled tomorrow"
109. Permissions should be entity-scoped
Agency Manager имеет доступ только к делегированным client entities и связанным заказам, а не «ко всему агентству» по строке company_name.
110. Personal data minimization
CMS не должна показывать каждому редактору:
- billing details, которые ему не нужны;
- verification documents целиком;
- личные контакты вне workflow;
- fraud/security metadata без причины.
111. Moderation knowledge base
internal handbook:
format rules
legal examples
link rules
sources hierarchy
claim examples
restricted topics
ad classification cases
correction policy
appeal policy
AI policy
Each moderation reason:
links to handbook section.
112. Decision consistency review
Раз в месяц senior editor должен брать случайную выборку approved/rejected материалов и проверять согласованность решений.
sample 20–50 decisions
→ compare reason codes
→ false approvals
→ false rejects
→ editor variance
→ update rules/training
113. AI as reviewer assistant
AI CAN:
summarize
extract claims
compare versions
find missing sources
detect duplicate
classify links
suggest format
suggest moderation reasons
flag legal terms
prepare client explanation
AI CANNOT:
final publish
final legal classification
approve accusations
invent sources
silently rewrite facts
114. AI confidence must not hide uncertainty
Если classifier сомневается между editorial и advertising, он обязан поднять BORDERLINE flag, а не выбрать «editorial 51%» и пропустить материал.
115. Human review ergonomics
Цель интерфейса — не заставить редактора читать 14 вкладок для каждой новости. STANDARD workflow должен показывать сначала только критические поля, а детали раскрывать по risk flags.
STANDARD:
content
format checklist
sources
links
entities
decision
IF FLAG:
legal
verification
claims
rights
commercial detail
116. Fast path
Хорошая новость с verified company, источником, нормальными ссылками и отсутствием legal risk должна проходить быстро.
PRECHECK PASS
→ editor reads
→ confirms format/source
→ APPROVE
→ READY
117. Slow path
paid comparison
+ "№1"
+ finance category
+ 4 commercial links
+ new advertiser
+ source conflict
→ ENHANCED
→ FACT CHECK
→ LEGAL
→ changes
→ second review
→ publish/reject
118. Launch staffing hypothesis
| Объём | Операционная модель |
|---|---|
| 0–10 paid/month | Founder/product + 1 editor can manually learn workflow |
| 20–30 paid/month + editorial | Dedicated editor + senior/founder; legal external/on demand |
| 50–100 paid/month | 2–4 editors depending format mix + dedicated queue ownership |
| 100+ | Need measured staffing model, shifts/SLA, specialization |
Это рабочая оценка, не рассчитанная штатная модель. Реальная производительность определяется пилотами и Mathchast_30.
119. Не автоматизировать слишком рано
Первые 50–100 материалов полезно модерировать с высокой долей ручной работы и записывать причины решений. Именно эти данные потом станут хорошей основой для AI precheck.
120. Данные для будущего AI
training/evaluation set internal:
input version
format
flags
claims
sources
editor decision
reason codes
requested changes
final version
appeal result
→ later evaluate AI suggestions
Но:
privacy / client contracts / AI policy
must govern actual model use.
121. Moderation gold set
Собрать 100–300 вручную размеченных примеров:
- good article;
- pure promo;
- good case;
- fake case;
- news vs press release;
- valid source vs weak source;
- SEO-link request;
- borderline ad;
- new-topic outlier;
- AI low-value rewrite.
122. CMS не должна зависеть от AI
Если локальная модель или внешний LLM недоступен, редакция должна продолжать работать. AI precheck деградирует в ручной workflow, но публикационная система не останавливается.
123. Resilience
AI unavailable:
→ flag PRECHECK_DEGRADED
→ manual queue
ORD unavailable:
→ advertising publication blocked
→ editorial unaffected
IndexNow unavailable:
→ publish still possible
→ queue retry
analytics unavailable:
→ publish still possible
→ reporting delayed
124. Incident flags
CMS global banners:
ORD DEGRADED
INDEXNOW DEGRADED
AI PRECHECK DEGRADED
PUBLICATION HEALTH INCIDENT
CRAWLER WAF INCIDENT
Editors understand:
what is blocked
what can continue.
125. Admin config
configurable without deploy:
allowed formats
restricted topics
risk weights
SLA
revision cycles
required verification levels
link limits
allowed file types
crawler policy ref
active templates
legal classification rules
critical config changes:
audited.
126. Feature flags
FIELD_SNAPSHOT enabled?
AI_PRECHECK enabled?
AGENCY_BULK enabled?
PAID_NEWS enabled?
CONTEXT_BRIDGE scoring enabled?
Pilot new functions
without exposing to all clients.
127. CMS KPI dashboard
Business:
paid submissions
publish rate
repeat
revenue waiting in queue
Editorial:
time to decision
revision cycles
corrections
rejections
Trust:
verification coverage
source completeness
legal escalations
System:
publish errors
health failures
IndexNow errors
crawler blocks
128. MVP scope
P0 MUST:
publication state machine
typed templates
client submission
editor queue
assignment + SLA
comments
versioning + diff
reason codes
claims/sources
entity relations
link classification
legal status fields
ad hard gates
preview
publish/schedule
audit log
correction workflow
event hooks
basic metrics
P1:
appeals UI
agency bulk
questionnaire campaigns
topic-distance scoring
advanced workload
WAF crawler dashboard
P2:
AI moderation assistant
advanced risk learning
quality sampling automation
enterprise SLA tools
129. Что НЕ строить в MVP
| Не строить | Почему |
|---|---|
| Полный универсальный enterprise CMS | Слишком большой scope |
| Комментарии читателей | Отдельный moderation burden |
| Автопубликацию LLM | Риск качества/compliance |
| Сложный BPMN designer для workflow | States известны заранее |
| 100 ролей и permission combinations | Рано |
| Автоматический legal verdict | Высокий риск |
| Автоматический массовый импорт публикаций | Scaled-content риск |
130. Рекомендованная последовательность разработки
1. publication + version model
2. typed editor
3. state machine
4. client submit
5. editor moderation UI
6. claims/sources/entities
7. legal/commercial fields
8. link policy
9. audit
10. preview
11. publish worker
12. sitemap/IndexNow hooks
13. corrections
14. analytics
15. AI precheck later
131. Главная продуктовая логика
Хорошая CMS должна делать правильное действие проще неправильного. Клиенту проще добавить источник, чем спорить с редактором. Редактору проще выбрать reason code, чем писать объяснение с нуля. Система сама ставит sponsored. Публикация без erid физически не проходит gate. Обновление URL автоматически вызывает redirect/discovery pipeline.
132. Решение документа
Утвердить workflow-first CMS. Материал имеет независимые editorial, legal, verification, commercial, publication и measurement states. Все клиентские и редакционные материалы проходят automated precheck и human moderation; риск определяет глубину проверки, но не отменяет обязательные gates. Оплаченный заказ не гарантирует публикацию неизменённого текста. Клиент получает конкретные reason codes и возможность доработки/апелляции. Published content редактируется только через revisions. Legal/ad disclosure, sponsored links, rights, verified version hash и canonical health являются hard publish gates. CMS хранит claims, sources, entities, links, versions и audit trail, а события publication workflow запускают sitemap, IndexNow, analytics и future AI Visibility.
133. Что этот документ разблокирует
Mathchast_24 CMS & moderation
→ Mathchast_25 AI precheck & AI editor
→ Mathchast_26 distribution engine
→ Mathchast_27 reader product
→ Mathchast_28 seed content
→ Mathchast_29 client cabinet
→ Mathchast_31 billing/refunds
→ Mathchast_32 publication health
→ Mathchast_37 agency workspace
→ Mathchast_40 technical architecture
→ Mathchast_42 monitoring/SLA/incidents
Источники исследования
- РБК Компании — создание материала, сохранение в черновик, отправка на модерацию, комментарии при отказе, сроки рассмотрения и правки редакции
- РБК Компании — управление профилями и отправка изменений/публикаций на модерацию
- РБК Компании — content restrictions, рекламные фрагменты, неподходящие темы и критерии рекламности
- РБК Компании — рубрики и возможность их изменения по решению модерации
- Хабр — описание ручной модерации: проверка оформления, фактов, рекламы, ссылок, внутренние флаги, усиленная проверка и обжалование
- Хабр — публикационные типы и ограничения процесса публикации
- Хабр — актуальные правила, коммерческие упоминания и ограничения ссылок
State machine, роли, очереди, SLA, reason codes, hard gates, version locking, workload units, questionnaire campaign workflow, approval matrix и технические события являются проектной моделью «Матчасти». Они объединяют решения документов 13–23 в единый operational layer. Перед разработкой следует превратить P0-блок в отдельную техническую спецификацию API/БД/UI.