Summary
LKCI currently uses one Postgres database, but it does not treat that physical fact as permission to blur responsibility. Lakehouse schemas hold ingestion, canonicalization, historical truth, enrichment, and analytical publication. Operational domain schemas hold tenant-scoped cases, issues, reviews, audit history, locks, and UI-serving state. Operations support stores durable execution state such as runs and schedules.
The operational tension is familiar: a single database makes a direct join or cross-domain write feel inexpensive. It can be inexpensive today and still be the wrong dependency. The platform chooses conceptual separation now so a future database or service split is possible without first untangling every screen, job, and query.
Operational Tension
Operational systems want current, reviewable state. Analytical systems want rebuildable historical truth. Execution systems want durable records of what ran, with attempts and recovery context. All three can be stored in one Postgres instance without being interchangeable.
If a UI reads raw analytical joins to assemble a workflow, it acquires the lakehouse's grain, freshness, and rebuild behavior as a hidden product dependency. If a pipeline mutates review state directly, it starts owning a human workflow it cannot present or repair. If a job leaves run state only in memory, an interrupted worker loses the evidence needed to recover. These are not abstract purity concerns; they are paths by which a convenient query turns into an opaque operational failure.
Decision: Separate Ownership Before Infrastructure
The repository's architecture defines separate responsibilities even while the database is shared. bronze, silver, and gold own ingestion, canonicalization, enrichment, historical fact, and analytical publication. OLTP and domain schemas own interactive workflow state. The ops area owns execution and support state. The names can evolve; the key is that ownership, not schema proximity, determines how a consumer reaches the data.
The bridge is explicit. Analytics reaches an operational surface through a publish step, a serving snapshot, or an authenticated OLTP-facing service or repository. UI code does not construct business state from raw analytical joins. There are no cross-boundary foreign keys, shared persistence models, or transactions that silently make analytical and operational state one unit of change. Temporary coupling is isolated behind an interface and documented as a migration seam.
This decision makes the current shape useful without asserting that it is the final physical topology. It treats environment configuration such as separate OLTP and analytics DSNs as a future option that the codebase should not foreclose.
Failure And Repair Posture
Boundary failures should be observable rather than repaired with a shortcut. If a published analytical projection is stale or fails a quality check, the repair belongs in the pipeline or publication path, with freshness and lineage evidence. An operational UI should not bypass that problem by querying a raw table because the serving view looks inconvenient. If a review record is missing or inconsistent, the repair belongs in the domain workflow and its audit trail, not in a backfill that writes user-facing state without context.
The same posture applies to execution. Jobs record durable run and attempt state so stale leases or recoverable failures have a repair path. A rerun can be scoped and explained rather than inferred from a process that disappeared. Each truth has its own failure semantics, but the boundaries make the owner and evidence discoverable.
Tradeoff
Explicit publishing and service boundaries create additional steps. They may duplicate selected data, require freshness contracts, and make a developer resist a tempting cross-schema query. The upfront cost can look disproportionate when everything is physically close.
The payoff is controlled change. Analytical rebuilds can evolve without silently changing an operator's screen. A review workflow can retain its audit contract without becoming a side effect of a transformation job. Execution recovery can be reasoned about separately from domain policy. If storage later splits, the platform has fewer accidental contracts to excavate.
Limits
Conceptual separation does not magically isolate runtime load, access control, or failure domains while the system shares one database. It also cannot justify an arbitrary service boundary that no workflow needs. The approach needs continued discipline in repositories, APIs, cache keys, object paths, and task payloads—not just diagrams. This account makes no claim that a physical split is planned or imminent.
Transferable Lesson
A shared database is an implementation choice; truth ownership is an architectural choice. Name the kinds of truth, define the publication and service bridges, and preserve repair paths at each boundary. Doing so turns a future split from a rewrite of assumptions into an evolution of interfaces.