Clarify comparison layers and decision criteria

web/src/content/docs/compare-event-sourcing-dotnet.mdx

@@ -12,7 +12,11 @@ import { Aside } from '@astrojs/starlight/components';
 
 KurrentDB, Marten, and Cratis Chronicle all support event-sourced systems, but they make different architectural choices. KurrentDB is a dedicated event database, Marten is an in-process .NET library built on PostgreSQL, and Chronicle is a separate event-sourcing server and processing runtime.
 
-This page compares the capabilities where those products overlap. It does not rank them, and it does not compare the complete Critter Stack with the wider Cratis ecosystem.
+This page compares the capabilities where those products overlap. It does not rank them, and it does not compare the Critter Stack as a whole with the wider Cratis ecosystem.
+
+## Comparison layers
+
+These products do not occupy the same layer. KurrentDB and Chronicle are separate event-server runtimes; Marten is an in-process .NET library. The Critter Stack and Cratis ecosystem add adjacent products rather than changing the boundary of the compared product. The matrix compares overlapping concerns and names which product owns each concern; it is not a feature checklist between equivalent products.
 
 ## What is being compared
 
@@ -69,10 +73,22 @@ Examine Chronicle closely when you want event storage and event processing behin
 2. **Database boundary:** Do you want PostgreSQL as the fixed foundation, a purpose-built storage engine, or a runtime with documented provider choices?
 3. **Application model:** Do you want to assemble the CQRS and messaging layers yourself, adopt the Critter Stack's .NET model, or use the wider Cratis application path?
 4. **Projection model:** Which work must share the append transaction, and which work may run asynchronously or on demand?
-5. **Language boundary:** Is .NET the complete application boundary, or must several language clients use the same event server?
+5. **Language boundary:** Is .NET the only application boundary, or must several language clients use the same event server?
 6. **Operations:** How will your team inspect subscription progress, failed processing, parked work, projections, replay, and recovery for the exact topology you deploy?
 7. **Commercial and license boundary:** Which server features, support terms, and licenses apply to the exact products you intend to run?
 
+## Decision criteria to verify separately
+
+This comparison does not score several decision-critical dimensions that depend on the exact deployment profile:
+
+- append and side-effect atomicity, plus read consistency;
+- event schema evolution, replay, and migration behavior;
+- backup, restore, upgrade, failure, and recovery procedures;
+- authentication, tenancy, encryption, PII, and redaction controls; and
+- support, commercial terms, and operational responsibility.
+
+Verify each dimension against the exact product versions and deployment profiles before choosing.
+
 ## Limitations
 
 - This is a documentation comparison, not a benchmark or production evaluation.

web/src/content/docs/compare-event-sourcing-jvm.mdx

@@ -12,7 +12,11 @@ import { Aside } from '@astrojs/starlight/components';
 
 Axon Framework, KurrentDB, and Cratis Chronicle all support event-sourced JVM systems, but they are not the same kind of product. Axon is an application framework with command, event, and query infrastructure plus pluggable event storage. KurrentDB and Chronicle are separate server products used through client SDKs.
 
-This page compares the concerns where those products overlap. It does not treat a database client as a complete application framework, and it does not treat framework breadth as proof that a database is missing features.
+This page compares the concerns where those products overlap. It does not treat a database client as an application framework, and it does not treat framework breadth as proof that a database is missing features.
+
+## Comparison layers
+
+Axon Framework is the application-framework option; Axon Server is optional event infrastructure. KurrentDB and Chronicle are event servers consumed through clients. The matrix compares overlapping concerns and labels whether responsibility sits in the framework, server, or client; it does not treat the products as equivalent feature bundles.
 
 ## What is being compared
 
@@ -66,12 +70,24 @@ Examine Chronicle closely when you want event storage and event processing behin
 
 1. **Framework boundary:** Do you want a JVM framework to own commands, queries, entities, repositories, and event processing, or do you want an event server behind an application model you choose separately?
 2. **Storage boundary:** Should events live in Axon Server, PostgreSQL or JPA through Axon, KurrentDB's own engine, or one of Chronicle's documented providers?
-3. **Spring boundary:** Do you need a complete CQRS application framework integrated with Spring, a Spring-configured database client, or Chronicle artifact registration and request integration?
+3. **Spring boundary:** Do you need Axon's CQRS application framework integrated with Spring, a Spring-configured database client, or Chronicle artifact registration and request integration?
 4. **Processing model:** Which handlers must share a transaction, which processors must be replayable, and where should checkpoints, retries, and failed work be owned?
-5. **Language boundary:** Is the JVM the complete system boundary, or must several language clients use the same event server?
+5. **Language boundary:** Is the JVM the only system boundary, or must several language clients use the same event server?
 6. **Operations:** How will your team inspect processor or subscription progress, failed processing, projections, replay, and recovery for the exact topology you deploy?
 7. **Commercial and license boundary:** Which server edition, support terms, and licenses apply to the exact components you intend to run?
 
+## Decision criteria to verify separately
+
+This comparison does not score several decision-critical dimensions that depend on the exact deployment profile:
+
+- append and side-effect atomicity, plus read consistency;
+- event schema evolution, replay, and migration behavior;
+- backup, restore, upgrade, failure, and recovery procedures;
+- authentication, tenancy, encryption, PII, and redaction controls; and
+- support, commercial terms, and operational responsibility.
+
+Verify each dimension against the exact product versions and deployment profiles before choosing.
+
 ## Limitations
 
 - This is a documentation comparison, not a benchmark or production evaluation.