{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","research_id":"eoa_inverse_innovation_exp09_light_prior_art_20260804","cell_id":"catalytic_pathway_enablement__computer_science","search_lanes":{"direct_problem_and_intervention":{"queries":["versioned event schema normalization gateway canonical event transformation receipt quarantine","event schema evolution upcasting migration chain event sourcing older events current schema"],"source_ids":["SRC2","SRC3","SRC4"],"no_result_note":"No retained source used the proposal's full gateway-and-receipt phrasing, but direct searches found established mechanisms covering version-selected transformation chains, validation, and exception routing."},"synonyms_and_historical_terms":{"queries":["event sourcing schema evolution upcasting copy transform empirical study 19 systems PDF","canonical data model anti corruption layer message transformation schema versions quarantine dead letter"],"source_ids":["SRC1","SRC2","SRC4"],"no_result_note":null},"products_practices_and_standards":{"queries":["Confluent Schema Registry schema evolution compatibility rules data contracts","AWS EventBridge Schema Registry discover schemas code bindings versioned events"],"source_ids":["SRC3","SRC4"],"no_result_note":"AWS schema discovery and bindings were reviewed in search results but not retained because they were less close than Confluent migration rules and Axon upcaster chains."},"component_combination":{"queries":["site:learn.microsoft.com event sourcing versioning upcasting old events schema","site:docs.axoniq.io upcaster event versioning event stream"],"source_ids":["SRC2","SRC4"],"no_result_note":null}},"sources":[{"source_id":"SRC1","title":"An Empirical Characterization of Event Sourced Systems and Their Schema Evolution — Lessons from Industry","publisher":"Journal of Systems and Software / arXiv","url":"https://arxiv.org/abs/2104.01146","source_type":"PRIMARY_RESEARCH","claims_supported":["A grounded study of 25 engineers and 19 event-sourced systems identifies event-system evolution as a prominent engineering challenge.","Observed schema-evolution techniques include versioned events, weak schemas, upcasting, in-place transformation, and copy-and-transform.","The study advises upcasting when simpler compatibility techniques are insufficient and notes performance, maintainability, and privacy concerns."]},{"source_id":"SRC2","title":"Event Sourcing Pattern","publisher":"Microsoft Azure Architecture Center","url":"https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing","source_type":"OFFICIAL_GUIDANCE","claims_supported":["Combining historical events with a new schema can be difficult.","Events can carry version identifiers that consumers use to select handling logic.","Registered upcasters can transform older schemas to the current schema and can be chained while leaving stored events unchanged.","Replay cost, ordering, auditability, and personal-data compliance are explicit operational considerations."]},{"source_id":"SRC3","title":"Data Contracts for Schema Registry on Confluent Platform","publisher":"Confluent","url":"https://docs.confluent.io/platform/current/schema-registry/fundamentals/data-contracts.html","source_type":"FIRST_PARTY_PRODUCT","claims_supported":["Confluent data contracts combine versioned schemas with integrity constraints, metadata, sensitive-field tags, policies, validation, and declarative migration rules.","Consumers can mediate between producer and application schema versions by transforming records to the expected version.","Rules can route invalid messages to a dead-letter queue, and migration rules can accommodate mutually incompatible producer and consumer versions.","Schema Registry centrally maintains version histories and supports both inter-topic and consume-time transformations."]},{"source_id":"SRC4","title":"Event Versioning","publisher":"AxonIQ","url":"https://docs.axoniq.io/axon-framework-reference/4.11/events/event-versioning/","source_type":"FIRST_PARTY_PRODUCT","claims_supported":["Axon supplies event upcaster abstractions that conditionally transform event payloads, types, metadata, or stream structure.","Successive version transformations are attached to an event stream through an ordered EventUpcasterChain.","The framework supports context-aware and one-to-many transformations, demonstrating reusable ordered migration logic for stored events."]}],"problem_evidence":{"status":"PARTLY_SUPPORTED","finding":"The general problem is visible: empirical research describes schema evolution as a prominent and difficult challenge, while official guidance says mixing historical and current event schemas can be difficult and requires versioning or upcasting. Product documentation also treats consistency, validation, sensitive-field handling, and incompatible-version migration as operational needs. The retained evidence does not directly establish the proposal's more specific claims about duplicated logic across ingestion jobs, repeated consultation with service owners, or queue growth caused by scarce historical-schema expertise.","source_ids":["SRC1","SRC2","SRC3"]},"closest_prior_art":[{"name":"Confluent Schema Registry data contracts and migration rules","source_ids":["SRC3"],"overlap":"Provides centrally maintained version histories, declarative upgrade and downgrade transformations, data-quality validation, sensitive-data policies, and dead-letter handling so records from one schema version can be presented to a consumer in another version.","remaining_difference":"The documentation places rule execution in serializers, deserializers, or consumers rather than specifying the proposal's separately operated ingestion-boundary gateway, per-record transformation receipt, explicit capacity metering and regeneration protocol, or fixed-resource performance comparison."},{"name":"Event-version upcasting and ordered upcaster chains","source_ids":["SRC1","SRC2","SRC4"],"overlap":"Version-tagged historical events are transformed through reusable, ordered functions until current application code can consume them; the transformations can be chained and preserve stored history.","remaining_difference":"These sources do not jointly specify centralized cross-service admission governance, authorization-context checks, typed privacy quarantine, transformation receipts, downstream-backlog admission control, or cache-reset recovery assays."}],"prior_art_disposition":"SUBSTANTIAL_COLLISION","contrastive_claim_remaining":"Relative to established consumer-side data contracts and ordered upcaster chains, a separately operated ingestion-boundary gateway will, under identical compute, event mix, mappings, authorization, and acceptance invariants, materially reduce engineer touch time and end-to-end conversion time across repeated batches while maintaining semantic agreement, policy compliance, traceability, and exception rates; any advantage must persist without producer redesign or relaxed validation.","contrastive_claim_falsifier":"The claim is falsified if an existing shared data-contract or upcaster implementation achieves equivalent results, if the gateway produces no material reduction in engineer touch or cycle time under fixed resources, if mappings cannot be reused across batches, or if apparent speed comes with worse semantic agreement, field loss, policy violations, unexplained quarantines, downstream backlog, or maintenance effort proportional to converted events.","gates":{"adequate_source_search":{"status":"PASS","rationale":"Eight queries covered the proposal directly, historical upcasting terminology, products and practices, and component combinations. Four opened sources from four publisher organizations include primary research, official guidance, and two first-party implementations.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"supported_problem":{"status":"PASS","rationale":"The evidence partly supports the proposed problem: schema evolution and replay across historical versions are documented challenges with established transformation, validation, privacy, and audit concerns, although the proposal's exact staffing and duplication observations remain unverified.","source_ids":["SRC1","SRC2","SRC3"]},"distinct_testable_claim":{"status":"PASS","rationale":"Despite substantial prior-art overlap, a falsifiable contrast remains: whether independent gateway operation adds measurable reuse, engineer-time, latency, traceability, and recovery benefits over existing data-contract or upcaster baselines without changing resources or acceptance rules.","source_ids":["SRC2","SRC3","SRC4"]},"bounded_next_test":{"status":"PASS","rationale":"The proposed isolated replay of at most 1,000 copied events across three documented versions, with fixed compute, identical mappings and invariants, no production writes, comparative metrics, and explicit halt conditions is bounded and directly tests the remaining contrast.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"no_obvious_safety_or_authority_stop":{"status":"PASS","rationale":"No obvious stop prevents an authorized, read-only replay using copied events. Existing guidance confirms privacy, sensitive-field, audit, and invalid-message concerns, all of which the proposed authorization boundaries, quarantine path, traceability checks, and stop conditions address. Production use would still require the named semantic, security, privacy, and change-control approvals.","source_ids":["SRC1","SRC2","SRC3"]}},"screen_survival":false,"world_novelty_boundary":"This bounded public-web screen establishes neither world novelty nor absence of patents, proprietary systems, unpublished practice, or differently named implementations. It cannot determine patentability, market size, expert acceptance, or realized value. It finds substantial collision with established schema-registry data contracts and event-upcasting chains; only the narrower comparative claim about a separately operated, receipt-producing, capacity-governed gateway remains for testing."}