55 / DATA INGESTION & SYNC / KNOWLEDGE-RESEARCH ENGINE + PRODUCTION FABRIC
55 / PRODUCTION / BACKFILL · INCREMENTAL SYNC · CHECKPOINTS · UPSERT

DATA INGESTION
& SYNC.

Data Ingestion & Sync — механизм, который систематически переносит данные из внешних источников во внутренний knowledge/data layer и поддерживает локальное представление актуальным: делает backfill, incremental sync, deduplication, upsert, deletion handling, retries и checkpoints.

Главный принцип: connector отвечает на вопрос «как прочитать источник», а ingestion/sync — «как надёжно пройти весь нужный набор данных, понять что изменилось и привести локальное состояние к согласованному виду».
00. ARCHITECTURAL STATUS

НЕ ВСЕ AI-СИСТЕМЫ ДОЛЖНЫ КОПИРОВАТЬ ДАННЫЕ К СЕБЕ

Если агент всегда делает live read через connector и объём небольшой, ingestion может быть лишним. Но когда нужен searchable corpus, локальный индекс, embeddings, offline processing, low-latency retrieval или устойчивость к provider API — sync становится production capability.
TYPEPRODUCTIONData movement / freshness layer.
DEFAULTCONDITIONALТолько для mirrored/indexed sources.
ENABLE WHENLOCAL CORPUS NEEDEDSearch/index/ETL/knowledge freshness.
SEPARATE COMPONENTYESLong-running sync responsibility.
LIVES INR06 + FABRICKnowledge / Research Engine + Production Fabric.
COMPLEXITYLOW → HIGHStart with periodic incremental sync.
IMPLEMENT: IF LOCAL KNOWLEDGE EXISTS
Минимум 80% ценности: source registry, initial backfill, stable source IDs, updated_at/cursor checkpoint, idempotent upsert, deletion policy, retry with bounded backoff, sync status/lag metrics, provenance and one simple scheduled worker. Не нужен отдельный LLM-agent: это deterministic data pipeline.
01A. ARCHITECTURE BOUNDARIES & OPERATIONS

EXPLICIT SYSTEM CONTRACT

A. BOUNDARY WITH NEIGHBORS

№54 Connectors умеет обращаться к конкретной внешней системе; №55 orchestrates recurring ingestion, backfill, checkpoints, dedupe, update/delete propagation. №56 Document Parsing/OCR превращает конкретный fetched blob/document в извлечённые структурированные элементы; №55 доставляет и переобрабатывает такие blobs. №08 RAG ищет знания во время запроса; №55 подготавливает corpus заранее. №42 Events & Triggers может инициировать sync; №55 владеет sync state. №57 Queues & Workers выполняет work units; №55 определяет сами ingestion jobs и checkpoints. №61 Provenance позже углубит lineage; №55 обязан уже сохранять source identity/version.

B. PREREQUISITES / CROSS-REFERENCES

Prerequisites: №08 RAG, №10 State, №42 Events, №46 Observability, №50 Contracts, №54 Connectors. Forward references: №56 Parsing/OCR, №57 Queues/Workers, №58 Scheduler, №59 Broker, №60 Artifact Store, №61 Provenance, №62 Caching, №63 Retry, №66 Vector DB & Embeddings.

C. PLANE PLACEMENT

REQUEST-TIME: обычно NO — это background pipeline. CONTROL PLANE: YES — source registry, schedules, cursors, backfill state, pause/resume, schema versions. DATA PLANE: YES — source objects, blobs, normalized records, tombstones. OFFLINE: YES — reindex/backfill/reprocessing, validation, quality checks.

D. FAILURE & OPERATIONS CONTRACT

Success: local corpus converges toward source state within defined freshness SLA. Retryable: transient source/worker errors and rate limits. Permanent: unsupported schema/object, revoked auth, deterministic parse failure after policy-defined attempts. Idempotency: same source version can be replayed safely. Persist: source_id, external_id, version/hash, cursor/checkpoint, sync run, last_seen/updated, tombstone state, parse/index versions. Trace: source→fetch→transform→upsert/delete→index.

E. WHAT THIS TOPIC DOES NOT OWN

№55 не владеет provider API adapter, content parsing algorithms, embedding model, vector DB internals, queue engine, scheduler platform или full data governance. Она владеет THE STATEFUL PROCESS THAT MOVES AND RECONCILES SOURCE DATA OVER TIME.

01. WHEN DO WE NEED SYNC?

LIVE ACCESS И LOCAL CORPUS — РАЗНЫЕ АРХИТЕКТУРЫ

LIVE ACCESS

Read on demand

Agent вызывает connector прямо в момент запроса. Хорошо для небольших sources, current transactional state, редких запросов.

Плюсы: freshest source, no duplicate storage.
Минусы: latency, rate limits, provider availability, weak full-text/vector search.

LOCAL CORPUS

Ingest + sync

Система заранее копирует/нормализует нужное представление и строит индексы.

Плюсы: fast search, embeddings, joins, offline processing.
Минусы: freshness problem, storage, delete handling, sync complexity.

Часто правильна hybrid-модель: local corpus для retrieval + live connector call для критичного current state перед действием.
02. INGESTION MODES

BACKFILL, INCREMENTAL, EVENT-DRIVEN И RECONCILIATION

FULL BACKFILL

Initial copy

Пройти весь доступный dataset и создать initial local representation. Нужен при первом подключении или полной rebuild.

INCREMENTAL POLL

Changes since cursor/time

Периодически запросить только новые/изменённые records. Типовой MVP.

EVENT-DRIVEN

Webhook/change feed

Provider сообщает об изменении. Быстро, но всё равно нужен recovery/reconciliation path.

RECONCILIATION

Periodic truth check

Сравнить local state с authoritative source, чтобы поймать потерянные события и drift.

REPROCESS

Same source, new pipeline

Source не изменился, но поменялся parser/chunker/embedding/model/schema — нужно переобработать.

ON-DEMAND

Selective fetch

Ингестировать конкретный object/collection по запросу workflow, а не весь source.

Даже при webhook-first архитектуре нужен periodic reconciliation. Event delivery редко стоит считать абсолютной гарантией вечной полноты.
03. MASTER PIPELINE

SOURCE → DISCOVER → FETCH → NORMALIZE → UPSERT → INDEX

SOURCE REGISTRYconnector, tenant, scope, sync mode.
DISCOVERList changes/pages/events from checkpoint.
FETCHGet metadata/blob/content references.
IDENTIFYStable source key + version/hash.
NORMALIZECanonical metadata; parsing delegated if needed.
UPSERT / DELETEIdempotent local state reconciliation.
INDEXSearch/vector/graph derived representations.
CHECKPOINTAdvance cursor only after durable success.
Checkpoint должен продвигаться после durable processing соответствующего диапазона. Иначе crash между «cursor advanced» и «data stored» создаёт тихую потерю данных.
04. SOURCE REGISTRY

ЧТО ИМЕННО МЫ СИНХРОНИЗИРУЕМ

{
  "source_id": "SRC-...",
  "tenant_id": "tenant_A",
  "connector_id": "drive:brand_A",
  "resource_scope": "folder:123",
  "sync_mode": "INCREMENTAL",
  "status": "ACTIVE",
  "schedule": "*/15m",
  "cursor": "opaque:...",
  "freshness_sla_s": 1800,
  "parser_profile": "documents.v2",
  "index_profile": "knowledge.v3",
  "delete_policy": "TOMBSTONE",
  "last_success_at": "...",
  "last_error": null
}
REGISTRY VALUE

Operational source of truth

Source registry отвечает:

  • какой external scope подключён;
  • какой connector используется;
  • какой режим sync;
  • какой cursor/checkpoint;
  • какие pipeline versions;
  • какой freshness SLA;
  • как обрабатывать delete;
  • paused/error/active?
05. CHECKPOINTS & CURSORS

SYNC ДОЛЖЕН ЗНАТЬ, ГДЕ ОН ОСТАНОВИЛСЯ

CHECKPOINT N

Last durable point: cursor C42 / updated_at T / page token.

PROCESS WINDOW

Fetch changes after C42. Upsert/delete all records. Persist derived artifacts/index state.

CHECKPOINT N+1

Advance to C43 only when processing policy says window is complete.

OPAQUE CURSOR

Best when provider offers it

Provider change token/page cursor should be treated as opaque state, not interpreted by model.

TIMESTAMP WATERMARK

Simple but tricky

updated_at > last_seen works only if ordering/time semantics are reliable; usually add overlap window.

COMPOSITE

Time + ID

Use timestamp plus deterministic tie-breaker ID to avoid missing records with equal timestamps.

Checkpoint — persisted operational state, не Memory. Он должен быть machine-managed и exact.
06. IDEMPOTENT UPSERT

ПОВТОРНАЯ ОБРАБОТКА ДОЛЖНА БЫТЬ НОРМАЛЬНОЙ

source_key =
  tenant_id
  + connector_id
  + object_type
  + external_id

source_version =
  provider_version
  OR updated_at
  OR content_hash

upsert(record):
    existing = load(source_key)

    if existing.version == source_version:
        return NOOP

    write canonical source record
    write provenance
    enqueue derived processing if needed
    mark version current
WHY IDEMPOTENCY

At-least-once is normal

Повтор может возникнуть из-за:

  • retry после timeout;
  • duplicate webhook;
  • worker restart;
  • reconciliation;
  • backfill overlap;
  • cursor replay.

Sync должен проектироваться так, будто один object обязательно придёт повторно.

07. VERSIONING SOURCE VS PIPELINE

ДАННЫЕ МОГУТ НЕ ИЗМЕНИТЬСЯ, А ИНДЕКС — ДОЛЖЕН

Version axisПримерЧто вызывает
SOURCE VERSIONDocument updated_at/content hash changed.Refetch/reparse/reindex.
PARSER VERSIONdocument parser v2 → v3.Reparse same source blob.
CHUNKER VERSIONChunking strategy changed.Rechunk/reembed.
EMBEDDING VERSIONNew embedding model.Re-embed current chunks.
INDEX SCHEMANew metadata/filter fields.Reindex/migrate derived records.
Нельзя использовать один updated_at для всей pipeline lineage. Храните версии source и derived processing раздельно.
08. DEDUPLICATION

ОДИН ФАКТ МОЖЕТ ПРИЙТИ МНОГО РАЗ — ИЛИ ИЗ НЕСКОЛЬКИХ ИСТОЧНИКОВ

TRANSPORT DUP

Same event/object twice

Решается stable event/object IDs + idempotent upsert.

CONTENT DUP

Same content, different IDs

Можно использовать content hash для storage optimization, но не смешивать source identity.

SEMANTIC DUP

Same fact, different docs

Это уже knowledge resolution/entity layer, не базовая sync responsibility.

Не удалять provenance ради dedupe. Два разных source objects с одинаковым текстом могут иметь разные authority, permissions и lifecycle.
09. DELETES & TOMBSTONES

SYNC, КОТОРЫЙ УМЕЕТ ТОЛЬКО ДОБАВЛЯТЬ, СО ВРЕМЕНЕМ СТАНОВИТСЯ ЛОЖНЫМ

HARD DELETE

Remove immediately

Удалить local record и derived chunks/index entries. Подходит, если governance требует полного удаления.

TOMBSTONE

Mark deleted

Сохранить minimal metadata/provenance, но исключить content из retrieval.

SOFT DELETE

Inactive

Provider объект архивирован/скрыт, но не удалён. Canonical status отражает это отдельно.

RECONCILE

Detect missing

Если provider не даёт delete events, периодическая inventory reconciliation выявляет исчезнувшие objects.

IMPORTANT
Delete propagation должна касаться не только primary record: chunks, embeddings, search index, caches, graph edges и derived artifacts тоже должны стать inaccessible/removed согласно policy.
10. FULL RECONCILIATION

ПЕРИОДИЧЕСКИ СВЕРЯТЬСЯ С AUTHORITATIVE SOURCE

SNAPSHOT SOURCE IDSList authoritative object identifiers/version hints.
SNAPSHOT LOCAL IDSCurrent mirrored set.
DIFFmissing / extra / version mismatch.
REPAIRFetch missing, update stale, delete orphaned.
VERIFYConvergence metrics.
CHECKPOINTRecord reconciliation run/result.
Reconciliation — страховка против lost webhooks, corrupted cursors, partial backfills и скрытых provider behavior changes.
11. DOCUMENT PIPELINE BOUNDARY

№55 ДОСТАВЛЯЕТ; №56 ИЗВЛЕКАЕТ СОДЕРЖИМОЕ

№54 CONNECTOR

Discovers/fetches external file metadata and blob/reference.

№55 INGESTION

Tracks source identity/version, downloads/stores blob, schedules processing, maintains sync state.

№56 PARSING

Extracts text/tables/images/OCR/layout into structured document representation.

Parser failure не должен терять source object. Сохраняйте raw/source reference и processing status отдельно: позже parser можно обновить и reprocess.
12. WEBHOOK + POLL HYBRID

БЫСТРОЕ ОБНОВЛЕНИЕ + НАДЁЖНОЕ ВОССТАНОВЛЕНИЕ

WEBHOOK PATH

Low latency

Change event → dedupe → fetch current object → idempotent upsert. Хорошо для freshness.

POLL / RECONCILE

Completeness

Periodic change feed or inventory scan catches missed/expired webhook events.

Не хранить всю payload semantics webhook как source of truth, если provider позволяет fetch current authoritative object. Event может служить trigger, а object API — truth source.
13. FRESHNESS

«СИНХРОНИЗИРОВАНО» ДОЛЖНО ИМЕТЬ ИЗМЕРИМЫЙ СМЫСЛ

SOURCE LAG

How stale?

Time from source change to durable local availability.

LAST SUCCESS

Pipeline health

Time since last successful run/checkpoint.

BACKLOG

Pending changes

Known items/events/jobs waiting to process.

SLA

Business target

Например, 95% updates searchable within N minutes.

Freshness SLA зависит от domain: wiki может обновляться раз в час, support tickets — за минуты, transactional balance вообще лучше читать live.
14. PARTIAL FAILURE

ОДИН ПЛОХОЙ OBJECT НЕ ДОЛЖЕН ОСТАНОВИТЬ ВЕСЬ SOURCE

FailureRecommended behavior
One object parse failsMark object PROCESSING_FAILED, preserve source/blob ref, continue source run if safe.
Provider transient outageBounded retry/backoff, keep checkpoint unchanged for affected window.
Permission revokedPause source / AUTH_REQUIRED; do not hammer provider.
Rate limitedRespect Retry-After, reduce concurrency, resume from checkpoint.
Schema driftQuarantine affected records, alert, keep raw payload/ref, do not silently corrupt canonical schema.
Index write fails after source record storedMark derived index stale/pending; retry indexing without refetch if possible.
Разделяйте source acquisition state и derived processing state. Тогда не нужно повторно скачивать 10 GB данных только потому, что embedding service был недоступен.
15. EXACTLY-ONCE?

НЕ ГНАТЬСЯ ЗА МАГИЧЕСКИМ «РОВНО ОДИН РАЗ»

ILLUSION

Exactly once everywhere

В распределённой pipeline трудно гарантировать literally one delivery across source/network/worker/store.

PRACTICAL

At-least-once + idempotency

Разрешить replay, но сделать upsert/dedupe безопасными и deterministic.

CHECKPOINT

Durable progress

Advance progress only after effects required by your consistency contract are durable.

16. CONSISTENCY MODEL

ЧТО ЗНАЧИТ «LOCAL CORPUS СООТВЕТСТВУЕТ SOURCE»

ModelMeaningUse case
EVENTUALLocal representation converges after bounded delay.Most knowledge/RAG corpora.
READ-THROUGH VERIFYUse local corpus for discovery, then live-read critical object before action.Policies/current status/transactional data.
SNAPSHOTUse consistent source snapshot/version for a batch/research job.Audits, reproducible reports.
STRONG LIVEDo not rely on mirror for authoritative current state.Balances, permissions, mutable transactional state.
Knowledge corpus чаще всего eventual. Не пытайтесь превратить RAG index в authoritative transactional database.
17. ACCESS CONTROL DURING SYNC

ИНДЕКС НЕ ДОЛЖЕН СТЕРЕТЬ SOURCE PERMISSIONS

BAD

Flatten everything

Ингестированные документы складываются в один index без tenant/ACL metadata.

BETTER

Carry access metadata

tenant, source scope, owner/groups/classification сохраняются вместе с record/chunks.

RETRIEVAL

Filter before exposure

RAG/query layer применяет authorization filters before returning evidence to model.

Если source ACL изменился, sync должен обновить access metadata так же серьёзно, как content. «Старый доступ в vector DB» — security bug.
18. PROVENANCE

ЛЮБОЙ LOCAL RECORD ДОЛЖЕН ОТВЕЧАТЬ «ОТКУДА Я ВЗЯЛСЯ?»

{
  "record_ref": "doc://tenant_A/123",
  "source_id": "SRC-drive-brandA",
  "external_id": "drive-file-abc",
  "source_version": "v42",
  "content_hash": "sha256:...",
  "fetched_at": "...",
  "connector_version": "2.3.1",
  "parser_version": "documents.v2",
  "index_version": "knowledge.v3",
  "status": "CURRENT"
}
LINEAGE MINIMUM

Enough to reproduce

Минимальная lineage позволяет понять:

  • какой source;
  • какой external object;
  • какая версия;
  • когда fetched;
  • каким adapter/parser/index profile обработан;
  • можно ли reprocess without refetch.

№61 позже расширит lineage как отдельную тему.

19. OBSERVABILITY

SYNC НУЖНО ВИДЕТЬ КАК PIPELINE, А НЕ КАК CRON «ГДЕ-ТО ТАМ»

RUN

Sync run

source_id, run_id, mode, checkpoint start/end.

DISCOVER

Input volume

items/pages/events discovered.

UPSERT

Changes

new / updated / unchanged / deleted.

FAIL

Errors

fetch/parse/index/auth/rate-limit counts.

LAG

Freshness

source-change-to-searchable latency.

BACKLOG

Pending work

Queued items and oldest age.

DELETE

Tombstones

deletions propagated to all derived layers.

DRIFT

Reconciliation

missing/orphaned/version-mismatch counts.

20. TESTING

ПРОВЕРЯТЬ НЕ ТОЛЬКО HAPPY PATH

BACKFILL

Initial load

All expected objects mirrored once logically.

UPDATE

Incremental

Changed source version updates local/derived records.

DELETE

Removal

Deleted object disappears from retrieval/derived indexes.

REPLAY

Idempotency

Same page/event/object repeated without duplication.

CRASH

Checkpoint safety

Worker dies before/after write; restart neither loses nor corrupts object.

RATE

Throttling

429/backoff preserves progress and does not storm provider.

DRIFT

Reconciliation

Lost webhook is later repaired by poll/reconcile.

ACL

Security

Permission changes propagate to searchable representation.

21. FAILURE MODES

КАК INGESTION & SYNC ЛОМАЕТСЯ

FULL SCAN EVERY TIME
Каждый sync повторно загружает весь dataset.
INCREMENTAL CURSOR
CURSOR ADVANCE EARLY
Checkpoint записан до durable upsert; crash теряет records.
COMMIT AFTER EFFECT
NO IDEMPOTENCY
Duplicate event создаёт duplicate chunks/records.
STABLE SOURCE KEY
IGNORE DELETES
RAG продолжает отвечать по удалённым документам.
TOMBSTONE / DELETE
WEBHOOK ONLY
Потерянное событие остаётся незамеченным навсегда.
RECONCILIATION
SOURCE = INDEX VERSION
Новый parser/embedding не вызывает reprocessing.
SEPARATE VERSIONS
ACL LOST
Индекс забывает source permissions.
PROPAGATE ACCESS META
ONE BAD ITEM STOPS ALL
Один malformed document блокирует весь source.
QUARANTINE ITEM
SYNC INSIDE CONNECTOR
Adapter смешан со stateful pipeline/scheduler/retries.
SEPARATE №54/№55
22. METRICS

ЧТО ИЗМЕРЯТЬ

LAG

Freshness Lag

Source change → local searchable availability.

SR

Sync Success

Successful runs/items by source and stage.

BL

Backlog Age

Oldest pending item/event and queue depth.

DR

Drift Rate

Reconciliation mismatches per source snapshot.

DEL

Delete Propagation

Time until removed source is absent from retrieval.

NOOP

Unchanged Ratio

Items refetched/reprocessed without source/pipeline change.

ERR

Permanent Failure

Objects stuck in deterministic processing error.

COST

Sync Cost

API calls/bytes/compute per changed object and per source.

23. MVP IMPLEMENTATION

POSTGRES + CRON/WORKER + CONNECTOR УЖЕ ДОСТАТОЧНО

ingestion/
├── sources.py
├── discover.py
├── sync.py
├── checkpoints.py
├── upsert.py
├── deletes.py
├── reconcile.py
└── tests/

tables:
  sources
  sync_runs
  source_objects
  processing_state

sources:
  source_id
  connector_id
  tenant_id
  scope
  cursor
  mode
  last_success_at

source_objects:
  source_key
  external_id
  source_version
  content_hash
  status
  last_seen_at
  deleted_at
  parser_version
  index_version
80% VALUE MVP

Simple stateful sync

  • One source registry table.
  • Connector list/fetch methods.
  • Initial backfill.
  • Incremental cursor or updated_at watermark.
  • Stable source key + source version/hash.
  • Idempotent upsert.
  • Tombstone/delete propagation.
  • Per-object processing status.
  • Checkpoint after durable work.
  • Periodic reconciliation.
  • Freshness/error metrics.

Queues, brokers, distributed workers and sophisticated CDC can be added later if scale actually requires them.

24. PRACTICAL DECISION

СТОИТ ЛИ ДЕЛАТЬ ОТДЕЛЬНЫЙ КОМПОНЕНТ?

ВопросОтвет
Стоит ли реализовывать?Да, если система хранит локальный knowledge corpus/index, который должен обновляться. Если всегда используется live connector read — может быть не нужен.
Separate Component?YES. Stateful long-running sync responsibility отдельно от connector adapter и request-time RAG.
Минимум 80% ценности?Source registry, backfill, cursor, source version/hash, idempotent upsert, delete handling, reconciliation, freshness metrics.
Когда overkill?Строить Kafka/CDC/data-lake platform для 300 документов, которые можно раз в 15 минут проверить простым worker.
Trigger?Нужен локальный searchable/indexed corpus, offline processing, embeddings или устойчивость к source latency.
Как измерить uplift?Freshness lag, retrieval coverage, drift, sync failures, source API pressure, stale-answer rate, cost per changed object.
Можно ли rule/tool/code вместо LLM-agent?Да, полностью. Ingestion/sync — deterministic pipeline; LLM может использоваться позже только внутри content extraction/classification tasks.
25. DESIGN RULES

ПРАВИЛА ДЛЯ РЕАЛЬНОЙ СИСТЕМЫ

RULE 01

Connector ≠ sync

Provider access и long-running reconciliation — разные responsibilities.

RULE 02

Replay is normal

At-least-once + idempotent upsert лучше fragile exactly-once assumptions.

RULE 03

Checkpoint after durability

Progress advances only after required effects are committed.

RULE 04

Track source version

external_id alone insufficient; know whether content actually changed.

RULE 05

Track pipeline versions

Parser/chunker/embedding/index may require reprocess without source change.

RULE 06

Deletes are first-class

Removed source must disappear from all derived retrieval surfaces.

RULE 07

Reconcile periodically

Webhooks/cursors are efficient, reconciliation is the safety net.

RULE 08

Preserve provenance

Deduplication must not erase source identity/authority/access context.

RULE 09

Measure freshness

«Sync healthy» means meeting explicit lag/completeness objectives.

26. FINAL MAP

KEEP THE KNOWLEDGE CORPUS CONVERGING TOWARD SOURCE TRUTH

EXTERNAL SOURCE
        ↓
№54 CONNECTOR
list / fetch / webhook normalize
        ↓
SOURCE REGISTRY
scope + tenant + mode + cursor + SLA
        ↓
DISCOVER CHANGES
  backfill
  incremental
  webhook
  reconciliation
        ↓
STABLE SOURCE KEY
+ source version/hash
        ↓
FETCH SOURCE OBJECT / BLOB
        ↓
STORE SOURCE REPRESENTATION + PROVENANCE
        ↓
[ №56 PARSING / EXTRACTION if needed ]
        ↓
NORMALIZE
        ↓
IDEMPOTENT UPSERT
        ├─ NEW
        ├─ UPDATE
        ├─ NOOP
        └─ DELETE / TOMBSTONE
        ↓
DERIVED PROCESSING
  chunks
  embeddings
  search index
  graph
        ↓
VERIFY DURABLE RESULT
        ↓
ADVANCE CHECKPOINT
        ↓
FRESHNESS / LAG / DRIFT METRICS

PERIODICALLY:

AUTHORITATIVE SOURCE SNAPSHOT
        ↕
LOCAL CORPUS
        ↓
RECONCILE DIFFERENCES

CORE PRINCIPLE:

INGESTION GETS DATA IN.

SYNC KEEPS IT TRUE ENOUGH
FOR THE SYSTEM'S FRESHNESS CONTRACT.

CONNECTOR KNOWS HOW TO TALK TO THE SOURCE.
SYNC KNOWS HOW TO REMEMBER PROGRESS,
REPLAY SAFELY,
PROPAGATE CHANGES
AND REPAIR DRIFT.

ECC RETROFIT / PRACTICAL HARNESS INTEGRATION

A. Related ECC ideas. Context-as-cache, scoped memory, lifecycle hooks, selective capabilities, feature flags, deterministic enforcement, provider-neutral adapters and eval-gated learning are applied only where relevant to №55 Data Ingestion & Sync.

B–E. Existing boundary and placement. The existing conceptual boundary, class PRODUCTION, default CONDITIONAL and owner Knowledge / Research Engine + Production Fabric remain authoritative. Runtime/control/data/offline placement is unchanged; durable state stays outside model context.

F–H. Hooks and contracts. Use bounded PRE_MODEL/POST_MODEL, PRE_TOOL/POST_TOOL, CHECKPOINT and TASK_COMPLETED events as applicable. Illustrative fields and canonical contracts are defined in NEW_CONTRACTS_SPEC.md; no universal schema is implied.

I–J. Security and evaluation. Host-side schema, permission, secret, budget, idempotency and audit checks take precedence over LLM output. Optional mechanisms require a feature flag and WITH/WITHOUT ablation; measure quality, acceptance, correction, latency, cost, escalations and severe errors.

K–L. Task profiles and cross-references. A TaskProfile selects the relevant skill, tool/context slice, memory scope and enforcement profile independently from FAST/STANDARD/DEEP. See cross-reference map, hook spec and ablation plan. Provider adapters remain outside the core.