Strategic Guide — Adoption

> Decision support for engineering managers evaluating KernDX adoption: enterprise-delivery realities, TCO modelling, AI tooling alignment, decision matrices, coexistence patterns, > and a brownfield roll-out roadmap with migration narratives.

Part of the KernDX Strategic Guide. See also: Architecture & Philosophy | Operations | Risks | Glossary | Personas

> Primary reader: Engineering manager or platform lead deciding whether to adopt KernDX and how to roll it out across teams. Skim then drill. Risks live in the > companion Risks doc; steady-state running cost lives in Operations.

---

Table of Contents

• Enterprise Delivery
  • The Multi-SI Challenge
  • Onboarding Time Comparison
  • Core Pattern Comparison
  • Enterprise Utilities Beyond Core Patterns
  • Framework Selection by Org Archetype
  • Build vs Buy: Hidden Costs
  • Build vs Buy: Cost Considerations
  • Coherence Costs of Modular Stacks
  • Operational Entropy and Maintainability in Multi-Team Environments
• AI & Modern Platform
  • AI Development Landscape
  • AI Context Files
  • Agentforce Implications
  • Practical AI Development Patterns
  • Modern Platform Features
• Decision Matrix & Coexistence
  • Quick Decision Guide
  • Decision Criteria
  • Capability Comparison
  • Coexistence Playbook
• Adoption Roadmap
  • Adoption Patterns
  • Standalone Adoption — Logging as a No-Migration Wedge
  • Starting from Existing Org (Brownfield)
  • Migration Narratives
  • Organisational Readiness
  • Adoption Governance Model
  • Operational Ownership Model
  • Success Metrics
• Conclusion
  • Summary
  • What Comes Next
  • Decision Framework
  • Decision Summary Matrix

Enterprise Delivery

The Multi-SI Challenge

Large enterprises typically engage multiple System Integrators (SIs) across different regions, business units, or project types. Each SI brings preferred framework choices, development standards, staff training investments, internal accelerators, and partner relationships.

This creates natural tension between consistency and SI expertise:

1. Enterprise selects Framework A for initial implementation, succeeds, becomes "standard"
2. Second SI proposes Framework B (their expertise), enterprise faces choice: force SI to learn Framework A (timeline risk) or accept Framework B (fragmentation)
3. Pattern repeats with each new SI

The Reality:

• Fortune 500 enterprises — often run 3-5 different frameworks across business units
• Global 2000 enterprises — may have 10+ framework variations across regions
• SI perspective — training 50-100 developers on unfamiliar framework = 6-12 month investment
• Enterprise perspective — multiple frameworks = higher support costs, slower cross-team collaboration, talent acquisition complexity

Multi-SI Environment Risk Analysis:

Risk Dimension	KernDX	Modular OSS Stack
Hand-off complexity	Higher if the incoming SI is new to KernDX — they must learn the framework-specific conventions, metadata topology, and managed-package constraints	Comparable — incoming SIs that already use one of taf / apex-fluently-soql / nebula-logger get a head start on that library; SIs new to those libraries face equivalent ramp
Convention fragmentation	Lower if governance exists — managed package enforces a single convention set	Higher — each SI may adopt different libraries, or use them inconsistently, unless the central architecture team enforces a standard
Contractual boundaries	More complex — framework dependency should be addressed in SI contracts; source ownership and maintenance responsibility require explicit terms (mitigated by public source availability under BSL 1.1 — the framework source is published on the public KernDX repository, so any team can clone and self-maintain it without a handover)	Simpler — open-source libraries carry no contractual implications
Knowledge silo risk	Higher — KernDX expertise concentrated in the original SI; handover requires deliberate knowledge transfer	Comparable in practice — modular libraries have public READMEs and (in some cases) hosted docs, but most are single-maintainer projects without large issue-tracker communities, so the "Stack Overflow will save us" framing is weaker than it sounds
Overall multi-SI risk	Higher risk without strong central governance to enforce consistent usage across SIs; manageable with central authority	Comparable risk to KernDX — multi-SI fragmentation is governance-driven, not framework-driven. Modular stacks fragment differently (library divergence) than integrated stacks (partial adoption) but both fragment without governance

Recommendation: In multi-SI environments, the load-bearing variable is governance strength, not framework choice. Either stack fragments without a central architectural authority enforcing consistency across all delivery partners; either is viable with one. See Operational Entropy and Maintainability in Multi-Team Environments for the entropy mechanism.

Onboarding Time Comparison

The fair comparison is per-module learning time, because no developer learns an entire framework at once regardless of which approach they use.

Per-module onboarding time (mid-level developer):

Each KernDX module has a dedicated Fast Start guide that follows a tiered approach (see it work then build your own then production patterns). The times below reflect completing the Fast Start — enough to build a working implementation and understand the patterns. Full-depth Developer Guides cover each module when developers need to go deeper.

Module	KernDX (Fast Start time)	taf	apex-fluently-soql	nebula-logger
Selectors	SEL_Base: ~30 min	N/A	~2-5 hours*	N/A
Triggers	TRG_*: ~20 min	~2-4 hours	N/A	N/A
DML	DML_Builder: ~30 min	N/A	N/A	N/A
Logging	LOG_Builder: ~30 min	N/A	N/A	~1-2 hours (basic), ~3-4 hours (full)
Test data	TST_Builder: ~30 min	N/A	N/A	N/A
Feature flags	UTIL_FeatureFlag: ~25 min	N/A	N/A	N/A
Validations	ValidationRule__mdt: ~25 min	N/A	N/A	N/A
Outbound APIs	API_Outbound: ~30 min	N/A	N/A	N/A
Inbound APIs	API_Inbound: ~30 min	N/A	N/A	N/A
Async processing	UTIL_AsyncChain: ~30 min	N/A	N/A	N/A
Code scanning	PMD + ESLint: ~20 min	N/A	N/A	N/A
E2E testing	Playwright: ~25 min	N/A	N/A	N/A
Full stack (all 12)	~5.5 hours of Fast Starts to productive	N/A (triggers only)	N/A (queries only)	N/A (logging only)

Competitor onboarding times are based on each library's documentation as observed in the comparator workspace:

• taf — README is 30 lines linking to the maintainer's docs site. Docs site has ~4,400 words across 9 focused pages. Strong ApexDoc on all core classes. A developer reads the getting-started page, creates a trigger + custom metadata record + action class + test in ~2-4 hours. No structured learning path — docs are reference-style, not guided.
• apex-fluently-soql — README links to the maintainer's hosted docs site. Docs site has 49 pages — broad in coverage and well-structured. The library intentionally suppresses all ApexDoc per the project README, so developers must leave their IDE to learn the API. First query is trivial (~10 minutes), but the lack of in-IDE documentation creates constant context-switching between IDE and browser during learning. Developers who read docs first: ~2-3 hours. Developers who learn by doing (the majority): ~4-5 hours due to IDE-to-browser round trips on every new method. Without ApexDoc, autocomplete shows many overloads with no descriptions. Note: apex-fluently-soql defaults to USER_MODE, so FLS/CRUD are enforced by construction. KernDX QRY_Builder also defaults to USER_MODE — same security default.
• nebula-logger — README ships quick starts for Apex, LWC, Flow, and OmniStudio. Strong ApexDoc on core classes. First log entry in ~10 minutes (Logger.info('msg'); Logger.saveLog();). Full setup with retention, tags, and log browser takes ~3-4 hours. Wiki migration in progress — docs split between repo and GitHub Wiki.

Key insight: KernDX's onboarding advantage is not faster per-module learning — competitors cover their individual modules in comparable time. The advantage is structural: 12 timed, tiered Fast Start guides with consistent conventions, full ApexDoc in the IDE, and a single documentation site covering the entire stack. Competitors have no cross-module learning path and varying documentation quality.

Key Factors:

• Documentation depth — KernDX ships 18 developer guides, 15 Fast Start guides, 263 API reference pages, a comprehensive Security Guide and a top-level SECURITY.md, a release-testing runbook (471 anonymous-Apex assertions across 71 sections), drift-audit cycle, AGENTS.md + docs/Code Conventions - Guide.md at repo root plus AI Agent Instructions for AI tooling. taf: 9 docs pages + ApexDoc. apex-fluently-soql: 49 docs pages but zero ApexDoc per repo-level exclusion. nebula-logger: README + GitHub Wiki (migration in progress) + ApexDoc. Across the comparable Apex frameworks surveyed, most ship no SECURITY.md at all; the 4 Beyond-The-Cloud libraries (apex-fluently-dml, apex-fluently-soql, apex-fluently-consts, apex-fluently-httpmock) ship the same Beyond-The-Cloud project-template SECURITY.md verbatim.
• In-IDE experience — KernDX and taf have full ApexDoc (developers learn without leaving their IDE). apex-fluently-soql has none — developers must consult the external docs site for every method. This is the biggest onboarding friction difference.
• Structured learning path — KernDX Fast Starts follow a tiered approach (see it work, build it, extend it) with each guide self-contained at ~30 minutes. No comparator offers a structured learning path across modules.
• Convention consistency — One naming system is faster to learn than 5+. New developers absorb QRY_*, TRG_*, SEL_* patterns that apply everywhere.
• AI tooling — Frameworks with a unified AGENTS.md (or similar tool-neutral context file) plus a canonical conventions doc reduce ramp time by enabling AI tools to generate convention-compliant code from day one.
• Code similarity to native Apex — Both KernDX and the Apex Fluently libraries use standard Apex patterns (selectors, builders, DTOs). Neither requires a paradigm shift like the fflib Domain-Driven Design patterns.

Reality Check: These are best-case numbers assuming quality documentation, senior developer mentorship, and dedicated learning time. Real-world onboarding often takes 50-100% longer due to production pressures, incomplete documentation, and learning-by-debugging existing code.

Core Pattern Comparison

Pattern	fflib	at4dx	KernDX	taf	apex-fluently-soql
Triggers	Custom base	Custom base	Metadata-driven (TRG_Base + TriggerAction__mdt)	Metadata-driven	N/A
Queries	fflib_QueryFactory	Query builder	QRY_Builder + SEL_* selectors	N/A	SOQL builder
DML	fflib_SObjectUnitOfWork	Unit of Work	DML_Builder	N/A	N/A
Service Layer	fflib_SObjectDomain	Domain classes	Service-specific (API_*, SVC_*, FLOW_*)	N/A	N/A
Selector	Abstract factory	Inheritance	Inheritance (SEL_Base)	N/A	Direct SOQL calls
Mocking	fflib_ApexMocks	ApexMocks	TST_Mock + QRY_Builder.setMock()	Standard Apex mocking	Standard Apex mocking
Test Data	Custom factories	Custom factories	TST_Builder + TST_Factory	N/A	Standard test setup
Logging	Custom	Custom	LOG_Builder (Platform Events)	N/A	Integrate nebula-logger
Feature Flags	Custom	Custom	UTIL_FeatureFlag	N/A	Custom or 3rd party
Caching	Custom	Custom	UTIL_Cache (Platform Cache)	N/A	Custom
API Integration	Custom	Custom	API_Outbound + API_Inbound	N/A	Custom
LWC	N/A	Limited	ComponentBuilder + modules	N/A	N/A

Key Observations:

• fflib / at4dx — broad scope, require significant training investment. fflib has had 1 tag and ~16 commits in the last 12 months (latest tagged release ~2,884 days old); installation is source deploy, not an unlocked or managed package. at4dx extends fflib with dependency-injection patterns and inherits fflib's posture on CRUD/FLS enforcement (opt-in at the query/DML layer); architecture review of the at4dx dependency-injection module is required before adoption. KernDX coexists with both for teams that want an infrastructure layer alongside Domain-Driven Design.
• KernDX — one managed package covering all layers. FLS/CRUD enforced by default on both read and write paths; data masking framework available across the broadest scope surveyed (any SObject), with per-SObject opt-in via MaskingTarget__mdt plus TriggerSetting.ApplyMasking__c = true, a framework-wide kill-switch for emergency rollback, and a Data Masking Advisor console that scans coverage and exports a regulated-field inventory; session encryption shipped; every bypass writes a structured audit event. Framework-internal selectors opt into SYSTEM_MODE via the documented SEL_Base.systemModeRequired() hook; the metadata kill-switches double as emergency rollback.
• taf / apex-fluently-soql — focused, modular, fast onboarding. Both ship USER_MODE defaults on their read paths and have established adoption signal (apex-fluently-soql at 147 commits / 36 tagged releases in 12 months, hosted docs site; taf at 33 published versions). KernDX matches them on substance and adds an integrated expansion path; the choice between them is depth on a single specialty surface versus framework-wide cohesion.
• Mix-and-match — teams commonly combine taf (triggers) + apex-fluently-soql (queries) + nebula-logger (logging). The three core libraries require no integration work — they are standalone and orthogonal. rflib's adoption of apex-fluently-soql in v9.1.0 confirms easy composition.

Enterprise Utilities Beyond Core Patterns

Enterprise teams need utilities beyond the core separation-of-concerns patterns:

Capability	fflib	at4dx	KernDX	Build or Integrate 3rd Party
Logging	Custom required	Custom required	Built-in (LOG_Builder)	nebula-logger (most established adoption signal surveyed)
Feature Flags	Custom required	Custom required	Built-in (UTIL_FeatureFlag)	LaunchDarkly, custom metadata
Circuit Breaker	Custom required	Custom required	Built-in (UTIL_CircuitBreaker)	Custom implementation
Retry Logic	Custom required	Custom required	Built-in (UTIL_Retry)	Custom implementation
Caching	Custom required	Custom required	Built-in (UTIL_Cache)	Custom Platform Cache wrapper
String/Date/Collection	Custom required	Limited	39 utility helpers across string, date, collection, set/list/map, security	Custom implementation
Test Builders	Custom required	Custom factories	Built-in (TST_Builder, TST_Factory)	Custom factories
API Framework	Custom required	Custom required	Built-in (API_Outbound, API_Inbound)	Custom implementation
LWC Base	N/A	N/A	Built-in (ComponentBuilder)	Custom base components
DTO Framework	Custom required	Custom required	Built-in (DTO_JsonBase)	Custom implementation

Reality Check: 80% of enterprises eventually build custom utilities regardless of framework choice. Logging is most commonly replaced first (with nebula-logger), followed by test builders, then integration frameworks.

Framework Selection by Org Archetype

Different organisational archetypes have fundamentally different framework needs:

Org Archetype	Realistic Needs	KernDX Approach	Modular Approach
Startup (< 20 users)	Triggers + queries + tests (minimum)	Install KernDX, use TRG_* + QRY_Builder + TST_Builder	taf + apex-fluently-soql + custom test setup
SMB (20-200 users)	+ logging + validation	Add LOG_Builder, validation rules	+ nebula-logger + custom validation
Mid-Market (200-1000)	+ web services + resilience	Full KernDX adoption	taf + apex-fluently-soql + nebula-logger + apex-fluently-dml + apex-fluently-httpmock + custom resilience
Enterprise (1000+)	Full stack + governance	Full KernDX — metadata enforces conventions	taf + Apex Fluently libraries (apex-fluently-soql, apex-fluently-dml, apex-fluently-async, apex-fluently-httpmock, apex-fluently-cache, apex-fluently-test, apex-fluently-lwc, apex-fluently-consts — each installed independently) + nebula-logger — discipline enforces conventions
ISV (AppExchange)	Package quality + namespace isolation	KernDX (designed for managed packages)	taf + zero-dep (or Apex Fluently source)
Integration-heavy	Retry, circuit breaker, outbox, idempotency	KernDX — built-in outbound retry, circuit breaker, transactional outbox, body-hash idempotency, dead-letter queues. KernDX covers more aspects of the Outbound family than any other Apex framework surveyed; rflib is competitive on the safe-mode surface	Build custom resilience patterns. Note apex-chainable ships a reflective-execution dispatcher — unsuitable for managed-package distribution
Government / regulated	Compliance + audit logging	KernDX (any-SObject masking, pre-emit log masking, session encryption, payload signing) + nebula-logger if a pre-built log browser is required	taf + apex-fluently-soql + nebula-logger (USER_MODE default on the query path; no integrated session encryption or signing)
Domain-complex	Business logic isolation	KernDX + custom domain layer (KernDX does not ship a Domain layer by design; fflib covers more aspects of the Domain Patterns family than any other Apex framework surveyed)	fflib or at4dx (Domain / Service / Unit-of-Work patterns; fflib ships as source deploy with one tag in the last 12 months)

Decision principle: Even the smallest team needs trigger handling, query organisation, and test data. The question is not whether to adopt a framework — it is which approach (integrated vs modular) best fits your team's size, priorities, and maintenance capacity. Over-engineering a small org is costly, but so is having no framework when the codebase reaches 20+ classes and technical debt starts compounding (Besker et al.: 23% of development time wasted on tech debt; McKinsey: 10-20% of new-product budget diverted to debt resolution).

Build vs Buy: Hidden Costs

Beyond framework licensing and training, enterprises encounter hidden costs that affect total ownership:

Hidden Cost	Description	Impact
Framework upgrade testing	Each framework version requires sandbox testing before production promotion	2-4 hours per upgrade per framework
Cross-framework debugging	When bugs span multiple libraries, debugging requires expertise in each one	4-8 hours per cross-framework incident
Documentation maintenance	Internal coding standards, onboarding guides, and migration playbooks require updates when frameworks change	8-16 hours per major version
CI/CD pipeline maintenance	Test configurations, deployment scripts, and quality gates for each framework	4-8 hours per framework per quarter
Vendor risk monitoring	Tracking GitHub activity, release cadence, and community health for each dependency	1-2 hours per framework per quarter
Framework conflict resolution	Namespace conflicts, dependency version mismatches, governor limit interactions	Rare but high-impact (8-24 hours per incident)

Key insight: The modular approach (taf + apex-fluently-soql + nebula-logger) has lower per-framework costs but multiplied by 3+ frameworks. KernDX has higher per-framework costs but only one dependency to manage. The break-even point is typically at 3-4 independent libraries — beyond that, an integrated framework may have lower total hidden costs.

Build vs Buy: Cost Considerations

This guide does not publish a modelled 3-Year TCO comparison of Native Apex / fflib / KernDX / a modular OSS stack in specific dollar figures. The reason: a fair per-framework dollar comparison rests on soft-cost multipliers ("framework-enforced quality standards reduce production bugs by Nx", "convention consistency reduces technical debt accumulation by Ny") that the relevant industry research (IBM/NIST, DORA, Besker et al., McKinsey) supports as qualitative ranges but does not convert into per-framework dollar deltas. Publishing specific dollar figures would give the comparison a precision it does not have. The honest framing is "the dollar delta depends on your team's pre-framework baseline" — and a directional comparison built on industry-research qualitative findings, not a fabricated point estimate.

What the research does support, qualitatively:

• Production bugs cost 10-100x more than development-phase bugs (IBM/NIST/NASA). Frameworks with enforced coverage gates, ApexDoc requirements, and scanner enforcement reduce production-defect rates relative to no-framework or unenforced-standards baselines. KernDX's 100% per-file Apex coverage gate and 36 scanner rules are concrete enforcement mechanisms that move this metric in your direction.
• Developers waste roughly 23% of their time on technical debt (Besker, Martini & Bosch 2018, IEEE — replicated 2019); McKinsey 2020 found 10-20% of new-product budget is diverted to debt resolution. Framework-enforced conventions reduce the inconsistent-pattern flavour of debt; they do not eliminate it.
• Quality documentation strengthens the lift from technical practices (DORA 2022 Accelerate State of DevOps report). KernDX's documentation depth (14 developer guides, 12 Fast Starts, 263 API reference pages, AGENTS.md + docs/Code Conventions - Guide.md AI context, the comprehensive Security Guide, the release-testing runbook) materially reduces the per-new-hire ramp curve — a metric you can measure directly against your team's own historical baseline.

What the research does not support: a specific dollar comparison of "KernDX costs $X over 3 years vs Modular at $Y" without measuring against your team's actual delivery data. Run the comparison on your team's own pre-framework baseline (defects per release, P1 incident MTTR, onboarding ramp time, code review cycle time) and remeasure after the pilot. See Success Metrics for the metric set most enterprises track.

Cost considerations that do not need a model:

• Licensing. Native Apex, KernDX, fflib, taf, apex-fluently-*, nebula-logger, rflib, apex-libra — all zero recurring license fees.
• Initial adoption ramp. fflib requires internalising Domain-Driven Design, which is a paradigm shift, not just an API change — meaningful ramp investment. KernDX and modular stacks have comparable per-module learning time (see Onboarding Time Comparison); the total framework footprint differs (KernDX covers more capability areas; modular stack covers fewer but is layered incrementally).
• Maintenance and upgrades. One managed package with one upgrade cycle (KernDX) vs five-to-eight independent libraries with five-to-eight independent release cadences (modular stack) is a real difference, but the dollar magnitude depends on your team's release-engineering maturity.
• Multi-SI entropy. In environments with multiple SIs and weak central governance, both stacks fragment. With strong central governance, either is viable. The mechanism is described in Operational Entropy and Maintainability in Multi-Team Environments.

Sensitivity Analysis — Adoption Scenarios:

Scenario	Impact on KernDX TCO	Impact on Modular TCO	Favours
High turnover team (40%+ annual)	Training costs increase with churn; KernDX documentation depth and AI context files reduce per-new-hire ramp time	Training costs increase with churn similarly; per-module onboarding times are comparable (see Onboarding Time Comparison)	Either — pick based on your team's existing framework experience
Stable senior team (< 10% turnover)	Training costs minimal; coherence and maintenance savings dominate	Training costs minimal; coherence discipline easier with stable team	KernDX (marginal)
Heavy Flow org (>50% logic in Flows)	Framework value reduced — most logic bypasses Apex framework	Framework value reduced equally	Neutral (both disadvantaged)
Pure Apex org (>90% logic in Apex)	Maximum framework value — all logic flows through framework patterns	Maximum framework value — all logic benefits from library standards	KernDX (marginal)
Bus factor event (maintainer unavailable 6+ months)	High impact per component — single maintainer; source publicly available under BSL 1.1 lets the team self-maintain from the public repository	Portfolio-distributed risk, component-level concentration is comparable — a 5-library modular stack spreads bus-factor events across 5 solo maintainers (a single event affects ~20% of the stack, not 100%), but individual components are themselves single-maintainer in most cases. Across comparable Apex frameworks, most comparable Apex frameworks are also single-maintainer. Only the fflib family has distributed maintainership. Fork potential applies equally to KernDX (source publicly available under BSL 1.1). See Bus Factor Mitigation.	Modular (portfolio spread), otherwise equivalent

Entropy risk (see Operational Entropy and Maintainability in Multi-Team Environments) should be considered as an additional TCO variable. In multi-SI, weakly governed environments, modular stack entropy costs can exceed the coherence savings of an integrated framework. Conversely, in centrally governed environments, integrated frameworks reduce entropy-driven costs.

Adoption Cost Dimensions (Relative Ratings):

Dimension	KernDX	Modular Stack	fflib	Native Apex
Initial Adoption Effort	★★ Medium — 1 framework, 1 convention set, 1 doc site	★★ Medium — comparable per-module learning time, but 5-8 APIs, 5-8 convention sets, and integration glue between libraries. Lower if adopting fewer modules, but equivalent at full-stack level	★★★★ High — paradigm shift to Domain-Driven Design, steep learning curve	★ Low — no framework overhead (costs surface in maintenance/debt)
Ongoing Maintenance	★ Low — single upgrade cycle, encapsulated internals	★★★ Medium-High — multiple upgrade cycles, cross-library testing	★★★ Medium — community maintenance, low recent release cadence	★★★★ High — no standards enforcement, technical debt compounds
Architectural Flexibility	Low — centralised metadata + naming conventions enforced via the managed package; subscriber code follows framework prefixes (TRG_* / SEL_* / DML_* / LOG_* / API_*) and patterns by construction	High — swap libraries independently, full source control	Low — pervasive Domain-Driven Design patterns, high migration cost	High — no framework constraints
Test Coverage Guarantee	100% per-file Apex + 95% LWC statement/branch — enforced by managed package requirement	Varies per library — apex-fluently-soql 98%+, others vary, custom code is your responsibility	Not publicly documented	Whatever your team enforces
Resilience / Web Services	Built-in — retry, circuit breaker, outbox, idempotency, distributed tracing	Must build custom — no modular equivalent for this combined feature set	Must build custom	Must build custom

Directional ratings (★ Low through ★★★★ Very High for cost rows; Low / Medium / High for strategic dimensions). See TCO model above for dollar estimates.

TCO Sensitivity Factors:

Factor	Impact on TCO
SI turnover rate	Higher turnover = training and onboarding costs dominate = favour well-documented frameworks (KernDX) or simple standards (modular)
Greenfield vs brownfield	Brownfield = favour modular adoption (per-library incremental) over full framework migration
Team Apex maturity	Junior-heavy teams = higher code quality costs without standards = favour frameworks with strict enforcement
Multi-SI strategy	Multiple SIs = favour managed-package enforcement (KernDX) or modular stacks with strong central governance — without central governance, either stack fragments
Integration volume	High integration count = favour KernDX (built-in resilience) over custom patterns
Code quality requirements	Regulated / ISV = favour 100% coverage + ApexDoc frameworks (KernDX, taf)

See the Decision Summary Matrix for situation-specific recommendations, and Decision Matrix & Coexistence for detailed evaluation criteria.

Coherence Costs of Modular Stacks

Production applications face ongoing architectural discipline costs — the effort to maintain coherence that a unified framework provides automatically. For the conceptual argument, see Integrated Stack. For the operating model perspective, see Operational Entropy and Maintainability in Multi-Team Environments.

Concern	Modular Stack Cost	Integrated Framework
Error handling	Manual Logger.error() in every catch block with hand-assembled context	Automatic structured logging with trigger context and correlation ID
Log correlation	Build custom correlation ID system across trigger / API / async boundaries	Correlation ID propagates automatically across all layers
Testing	3+ mock systems (query mocks, HttpCalloutMock, logger test setup) with separate APIs	Unified TST_Mock + QRY_Builder.setMock() + API_MockFactory
Feature flags	Manually disable each component (trigger bypass, query check, API check)	One feature flag record disables an entire feature path
Upgrade coordination	5-8 independent release cycles with manual compatibility testing	1 managed package upgrade with internally tested compatibility
Convention enforcement	5+ library APIs with different naming, error handling, and test patterns	1 prefix system and 1 set of conventions (AGENTS.md + docs/Code Conventions - Guide.md) covering all modules
Environment quality	Source-distributed code appears in subscriber's PMD scans and coverage reports	Managed package encapsulates code from subscriber analysis

These costs are manageable with strong technical guidance. Teams with dedicated architects who enforce cross-library consistency can maintain a coherent modular stack. Teams without that discipline will see these costs compound over time.

Operational Entropy and Maintainability in Multi-Team Environments

Problem Statement

In large Salesforce implementations, long-term maintainability is driven less by licensing model and more by delivery operating model.

Enterprise org degradation most commonly occurs due to:

• Multiple system integrators contributing concurrently
• Inconsistent architectural enforcement
• Divergent coding patterns
• Uneven adoption of shared utilities
• Fragmented logging and error handling approaches
• Variable CI/CD enforcement discipline
• Team turnover across vendors

Maintainability challenges in these environments are typically behavioural and structural, not related to whether components are open source or integrated.

Open Source Does Not Guarantee Maintainability

The presence of an open-source framework does not inherently enforce:

• Naming conventions
• Consistent abstraction layering
• Cross-cutting concerns (logging, retry, resilience)
• Transaction boundary discipline
• Test strategy alignment
• Dependency management hygiene

Open-source modularity provides building blocks. It does not enforce organisational consistency. Sustained maintainability depends on governance, enforcement, and architectural authority.

Entropy Risk in Modular Architectures

In multi-SI or loosely governed environments, modular stacks can introduce additional degrees of freedom. Common failure patterns include:

• Selective framework adoption by different teams
• Local utility duplication
• Forked implementations of shared libraries
• Inconsistent trigger orchestration approaches
• Divergent logging frameworks
• Incompatible error handling standards
• Variable mocking and test patterns

These conditions increase architectural entropy — the growth of inconsistency and unpredictability across the codebase over time. Higher entropy correlates with increased onboarding time, slower incident triage, cross-team integration friction, and reduced confidence in refactoring.

This risk is independent of open-source licensing. It is an operating model outcome.

Degradation Sequence in Multi-SI Environments

In distributed delivery environments, entropy compounds through a predictable temporal sequence:

1. SI A adopts framework X — establishes initial patterns and conventions
2. SI B introduces different patterns — uses alternative libraries or custom utilities for the same concerns
3. SI C bypasses both for delivery speed — writes inline solutions under sprint pressure
4. Utility duplication emerges — three string utility classes, two date helpers, no shared awareness
5. Logging fragments — each SI instruments differently; cross-team incident triage requires reading three logging styles
6. Testing conventions diverge — mock strategies, assertion patterns, and data setup approaches differ across teams
7. Composite codebase without coherence model — no single developer or team can reason about the full system with confidence

This is not a failure of any framework. It is an emergent property of modular freedom under distributed ownership.

Integrated Framework as Entropy Constraint

An integrated framework reduces available implementation pathways by centralising trigger orchestration, logging standards, query construction patterns, error handling conventions, resilience patterns, and test scaffolding. This reduces the number of architectural decisions individual teams must make.

Reduced optionality can lower entropy growth in environments where governance is inconsistent, multiple vendors contribute, architectural enforcement is variable, or knowledge transfer between teams is weak.

This does not eliminate entropy. It constrains the surface area for divergence.

Trade-Off: Coherence vs Coupling

Centralised integration introduces countervailing risks:

• Increased dependency on core maintainers
• Tighter coupling between framework components
• Higher impact radius of framework defects
• Greater importance of release discipline
• More structured onboarding requirements

Approach	Strengths	Risks
Distributed Modularity	Greater flexibility; lower central dependency	Higher entropy risk without governance
Integrated Coherence	Reduced decision variance; lower entropy growth potential	Higher central governance dependency

Each approach has trade-offs; suitability depends on operating model maturity.

Maintainability Comparison

Dimension	Modular Stack	Integrated Stack
Code readability	Depends on governance	Depends on governance
Long-term sustainability	Depends on maintainer continuity	Depends on maintainer continuity
Upgrade path	Component-specific	Release-aligned
Architectural entropy risk	Higher in distributed ownership	Lower if enforced
Vendor lock-in	Low	Medium

Maintainability is not determined by open-source status. It is determined by consistency, enforcement, and cultural discipline. The key difference lies in how much structural guard-rail the architecture provides when discipline erodes.

Entropy Risk by Environment

Delivery Environment	Modular Stack Entropy Risk	Integrated Framework Entropy Risk
Single cohesive team	Low	Low
Two coordinated teams	Medium	Low
Multi-team, shared governance	Medium	Low
Multi-SI, weak central enforcement	High	Medium
High turnover, distributed vendors	High	Medium

This table assumes governance strength as the primary variable.

Governance Maturity and Framework Suitability

Framework suitability correlates with the adopting organisation's governance maturity:

Level 1 — Tactical Delivery Org: Multiple vendors, no architectural board, sprint velocity prioritised over consistency. Modular entropy risk is high because no central authority enforces convergence. Integrated frameworks reduce decision variance but still require minimum governance investment (naming conventions, code review standards, upgrade ownership).

Level 2 — Controlled Enterprise: Central architecture function exists, framework standards enforced via pull request reviews and CI pipelines. KernDX ships a ready-to-use Framework Compliance Scanner — 36 rules (PMD + Node + ESLint) that enforce framework abstraction usage (no inline SOQL, no direct DML, no System.debug(), etc.). Upload the rulesets to your CI/CD tool (Gearset, Copado, AutoRABIT, CodeScan) and enforcement is automatic. Mixed modular stacks are viable at this level because governance mechanisms catch divergence before it compounds, but require teams to build their own linting rules. Integrated frameworks with built-in scanners provide additional guard-rails with zero custom tooling.

Level 3 — Platform-as-Product Org: Strong internal platform team, CI enforcement with automated linting and convention validation, dedicated framework maintainers. KernDX's scanner provides the linting baseline; platform teams extend it with org-specific naming rules. Modular stacks are sustainable long-term because the platform team actively manages cross-library coherence. Integrated frameworks offer diminishing marginal returns at this maturity level.

Governance Level	Modular Stack Viability	Integrated Framework Value
Level 1 (Tactical)	High entropy risk	Reduces decision variance
Level 2 (Controlled)	Viable with enforcement	Additional guard-rails
Level 3 (Platform)	Sustainable long-term	Diminishing marginal returns

KernDX reduces dependency on Level 2/3 governance maturity but does not eliminate the need for it.

Key Framing Principle

Maintainability is a function of governance authority, enforcement mechanisms, pattern discipline, review rigor, and cultural alignment — not licensing model. Architectural choice should therefore align with the organisation's ability to enforce standards across delivery partners.

---

AI & Modern Platform

AI Development Landscape

AI coding assistants have evolved from code completion to full-context development agents:

Tool	Model Access	Context Handling	Salesforce Integration
Agentforce Vibes	Claude (Cline fork)	AGENTS.md support	Native (VS Code extension, org-aware)
Claude Code	Claude	AGENTS.md native support	Generic (requires manual context setup)
Cursor	Claude, GPT, custom	.cursorrules project context	Generic (requires custom rules)
Cline	Any API (Claude, OpenAI, Gemini, Ollama)	Custom instructions, project context	Generic (community SFDC prompts)
Copado AI	Claude (partnership)	Salesforce metadata-aware	Native (deployment history, test impact)

Key Observations:

• Tools with project-specific context files (AGENTS.md, .cursorrules) produce more convention-compliant code
• Salesforce metadata awareness (Agentforce Vibes, Copado AI) reduces deployment errors by ~30%
• Base subscription costs converging ($10-20/month); real cost driver is API usage for multi-turn conversations

AI Context Files

KernDX maintains three AI context files:

File	Tokens	Location	Purpose
AGENTS.md	~3K	repo root	Tool-neutral entry point for AI coding assistants — points to canonical conventions (the AGENTS.md convention recognised by Claude Code, Cursor, Cline, Agentforce Vibes)
docs/Code Conventions - Guide.md	~12K	docs/	Canonical framework conventions, code patterns, critical rules for AI code generation
AI Agent Instructions (docs/AI Agent Instructions.md)	~10K	docs/	Complete per-module framework reference for deep AI-assisted development — architecture, module inventory, conventions, examples

Prompt caching (available from major LLM providers) benefits frameworks with standardised instruction files most — reducing repeated input token costs by ~90%.

Agentforce Implications

Salesforce's Atlas Reasoning Engine (Agentforce GA October 2024) enables autonomous agents to execute multi-step workflows. Framework implications:

1. Lean code preferred — agents reason about simple code more effectively
2. Declarative config preferred — metadata-driven frameworks align with agent execution
3. Test coverage critical — agents validate changes via unit tests
4. Idempotency essential — agents may retry actions; framework-level duplicate detection prevents double-processing

Practical AI Development Patterns

Pattern 1: Framework-Aware Code Generation

With a well-structured docs/Code Conventions - Guide.md, AI assistants generate convention-compliant code:

// Prompt: "Create a trigger action that sets Account.Description to 'Enterprise' when Industry is 'Technology'"

// Without conventions — AI generates vanilla Apex with System.debug, inline SOQL, raw DML
// With AGENTS.md + docs/Code Conventions - Guide.md — AI generates:
//   - TRG_SetAccountDescription extending TRG_Base
//   - Implements IF_Trigger.BeforeInsert
//   - Uses LOG_Builder instead of System.debug
//   - Includes TST_Factory setup in test class
//   - Follows Allman bracing, tab indentation, ApexDoc conventions

Pattern 2: AI-Assisted Test Generation

Frameworks with structured test patterns enable better AI test generation:

Without Framework	With KernDX
AI writes insert record	AI uses TST_Builder.of(SObjectType).build()
AI writes [SELECT ...]	AI uses QRY_Builder or SEL_*
AI writes System.debug()	AI uses LOG_Builder
AI guesses test setup	AI uses TST_Factory.newTriggerAction()
AI forgets mock setup	AI uses TST_Mock for DML-free tests

Modern Platform Features

Spring '26 introduces features that affect framework selection:

Feature	Impact	KernDX Integration
Apex Cursors (GA)	Process up to 50M rows in controllable chunks	.toCursor() on QRY_Builder
RunRelevantTests (Beta)	AI-driven test selection for faster deployments	Declare dependencies via testFor parameter
Named Query API (GA)	REST endpoints without custom Apex	Reduces need for simple query-only API classes

---

Decision Matrix & Coexistence

> Scenarios where KernDX is not the right fit — including "When NOT to Use KernDX" and "When Modular Architectures Clearly Excel" — live in the > companion Risks doc.

Quick Decision Guide

If You Need...	Choose	Rationale
Only trigger framework	taf or KernDX (triggers only)	KernDX covers every aspect in the Trigger family — metadata-driven per-event activation, three observability hooks (failure emission, per-action perf timer, framework-wide bypass audit), Change Data Capture dispatch, and post-trigger transaction finalizers — and taf wins on none of them. Choose KernDX unless you already run taf and want triggers only
Only query builder	apex-fluently-soql or KernDX (queries only)	Both default to USER_MODE on the read path. apex-fluently-soql covers the query specialty surface (semi-join, cursor pagination, ROLLUP/CUBE aggregates); KernDX matches on substance and adds integrated selector infrastructure (SEL_Base with 12+ inherited methods). Choose apex-fluently-soql for syntax breadth on a single specialty surface; choose KernDX for integrated selector infrastructure and a coherent expansion path
Only logging	nebula-logger	nebula-logger covers more aspects of the Logging family than any other Apex framework surveyed, with a dedicated historical log-browser LWC, log retention purge, 7 log levels, and four save-method strategies. KernDX matches on Apex / async / LWC logging plus W3C distributed tracing and cross-trigger correlation IDs, but lacks a dedicated log-browser LWC.
Triggers + queries (no full framework)	taf + apex-fluently-soql or KernDX (partial)	Both modular libraries default to USER_MODE on the read path. Modular: 2 installs, no namespace. KernDX: 1 install, use 2 modules, rest is inert, integrated when you expand. Choose based on whether you value independent installs (no namespace, mix-and-match) or integrated expansion path
Modular open-source full stack	Apex Fluently libraries + nebula-logger	Assemble from 8 independently-installable MIT libraries (apex-fluently-soql, apex-fluently-dml, apex-fluently-async, apex-fluently-httpmock, apex-fluently-cache, apex-fluently-consts, apex-fluently-test (Beta), apex-fluently-lwc — each in its own repo) + nebula-logger. Per-module learning comparable to KernDX; trade-off is flexibility vs coherence costs (see Coherence Costs of Modular Stacks). Note: the 8 Apex Fluently libraries share a single primary author, so this stack is effectively 2 maintainers (the Apex Fluently author plus the nebula-logger maintainer), not 9. For portfolio-level maintainer spread, pair independently-maintained libraries — taf + apex-fluently-soql + nebula-logger — for 3 distinct maintainers
Full integrated infrastructure	KernDX	Integrated triggers / queries / logging / web services / resilience / LWC / inbound REST routing / masking / async chain. KernDX ships production-ready implementations of every core Salesforce capability, broader than the comparable Apex frameworks the team has surveyed. Per-module learning comparable to modular; advantage is pre-integrated coherence, single upgrade cycle, and cross-cutting framework guarantees (see Coherence Costs of Modular Stacks)
Complex domain modelling	fflib	fflib covers more aspects of the Domain / Service / Application-factory surface than any other Apex framework surveyed; KernDX is absent on this capability by design. fflib distribution is source deploy (~16 commits and 1 tag in the last 12 months) — plan for in-org source maintenance.
Web services + resilience	KernDX	KernDX covers every aspect in the Outbound family: outbound HTTP client with retry, circuit breaker, transactional outbox, body-hash idempotency, dead-letter queues. KernDX is also the only Apex framework surveyed shipping inbound REST routing with body-hash idempotency that returns HTTP 409 on replay divergence. rflib is competitive on the safe-mode surface.
Agentforce integration	KernDX + nebula-logger	Idempotent actions, platform event diagnostics, web service capabilities
Team < 5 developers	KernDX (incremental) or taf + apex-fluently-soql	Both viable — per-module learning time is equivalent. Adopt per-module, not all-at-once
Team > 20 developers	KernDX or taf + Apex Fluently + nebula-logger	Standardisation at scale, architectural governance
Existing fflib org	KernDX utilities + fflib domains	Leverage existing domain logic, add infrastructure modules (HTTP client, retry / circuit breaker, structured logging, masking, async chain orchestration) that fflib does not ship
Managed package development	KernDX	Designed for managed packages — 2GP, namespace isolation, 100% per-file Apex coverage

Decision Criteria

Use this table to evaluate which approach best fits your constraints. Each column has strengths — the right choice depends on your team's priorities:

Criterion	Favours Integrated (KernDX)	Favours Modular (taf + Apex Fluently + nebula-logger)
Team size > 20 developers	Convention enforcement via managed package	Modular libraries with team-supplied conventions (architectural discipline required to keep multiple libraries consistent)
Governance maturity is low	Managed package encapsulates standards	Requires architectural discipline to maintain consistency
Integration volume > 5 APIs	Built-in retry, circuit breaker, transactional outbox	Build custom resilience or adopt apex-libra
Package encapsulation needed	2GP managed, exempt from 6 MB limit	Source-distributed, counts against limit
Open-source community required	Not a fit — source is public under BSL 1.1, but BSL is not OSI-approved until the Apache 2.0 conversion, and the contribution model is single-maintainer / issues-only	MIT-licensed, public GitHub repos
Existing fflib investment	Complement with utilities, don't replace	Complement with utilities, don't replace
Domain-Driven Design required	Not a fit (service-oriented)	fflib or at4dx
Rapid prototyping	Strong default conventions speed delivery	Lighter initial setup
AI-assisted development	AGENTS.md + docs/Code Conventions - Guide.md at repo root plus AI Agent Instructions per-module framework reference, optimised for AI code generation	Per-library README quality varies; apex-fluently-soql and nebula-logger ship maintainer-authored docs sites
Consulting delivery with handover	Source is public under BSL 1.1; consulting delivery adds direct source delivery and handover support, and the client owns and can self-maintain the framework	Client may already know one or more of the libraries; if not, the per-library ramp is comparable to learning KernDX
Operational entropy risk (multi-team)	Lower entropy growth potential (see Operational Entropy)	Higher entropy risk without governance (see Operational Entropy)

Capability Comparison

See Choosing a Framework for the full capability-by-capability comparison and head-to-head trade-offs across all frameworks.

Coexistence Playbook

Modern Salesforce implementations rarely use a single framework. Salesforce frameworks are increasingly modular and interoperable: taf handles triggers, apex-fluently-soql handles queries, nebula-logger handles logging — no architectural conflicts.

Example Combinations:

Combination	When to Use	Trade-offs
taf + KernDX utilities	Need taf's declarative trigger surface + KernDX web services / resilience / async / inbound REST	Learn two frameworks. Bypass KernDX's TRG_Dispatcher.
apex-fluently-soql + nebula-logger	Specialty query surface + pre-built log browser	No integrated trigger or DML framework
taf + apex-fluently-soql + nebula-logger	Full open-source stack — taf on triggers, apex-fluently-soql on query depth, nebula-logger on log browser + masking	Requires managing three separately-versioned dependencies
KernDX + fflib domains	KernDX infrastructure + fflib Domain layer (KernDX absent on this family by design)	Requires understanding both paradigms. fflib distribution is source deploy (~16 commits / 1 tag in the last 12 months).
KernDX + apex-fluently-soql (query-layer swap)	Subscribers who specifically need apex-fluently-soql's specialty (semi-join, cursor pagination, ROLLUP/CUBE aggregates)	Two query builders in the same codebase — pick one per class via convention; lint to prevent drift. Both default to USER_MODE on read AND write — equivalent on substance, not a swap driver.

Practical Coexistence Examples

fflib Domain with KernDX Query Builder:

public inherited sharing class Accounts extends fflib_SObjects
{
    public Accounts(List<Account> records)
    {
        super(records, Account.SObjectType);
    }

    public void applyDefaults()
    {
        Set<Id> ownerIds = new Set<Id>();
        for(Account account : (List<Account>)getRecords())
        {
            ownerIds.add(account.OwnerId);
        }

        Map<Id, User> ownerMap = (Map<Id, User>)QRY_Builder.selectFrom(User.SObjectType)
            .fields(new List<SObjectField>{User.Id, User.Department})
            .condition(User.Id).isIn(ownerIds)
            .asMap();

        for(Account account : (List<Account>)getRecords())
        {
            User owner = ownerMap.get(account.OwnerId);
            if(owner != null && String.isBlank(account.Department__c))
            {
                account.Department__c = owner.Department;
            }
        }
    }
}

Invoking Flows from KernDX Trigger Actions

KernDX's trigger framework ships native Flow-as-trigger-action via TRG_InvokeFlow and a FlowName__c field on TriggerAction__mdt — set FlowName__c, leave ApexClassName__c blank, and the framework dispatches via its built-in flow runner with declarative LogAndContinue / BlockDml failure strategies and a deploy-time scanner. For programmatic Flow invocation outside the trigger framework — for example calling a Flow from a non-trigger context — the pattern below applies:

public without sharing class TRG_InvokeAccountFlow extends TRG_Base implements IF_Trigger.AfterInsert
{
    private static final String FLOW_NAME = 'Account_PostProcessing';

    public void afterInsert(List<SObject> newRecords)
    {
        for(SObject record : newRecords)
        {
            Map<String, Object> inputs = new Map<String, Object>{ 'recordId' => record.Id };
            Flow.Interview flow = Flow.Interview.createInterview(FLOW_NAME, inputs);
            flow.start();
        }
    }
}

> Note: This pattern invokes Flows programmatically from arbitrary Apex. KernDX's native Flow-as-trigger-action surface (TRG_InvokeFlow + FlowName__c on TriggerAction__mdt) handles declarative trigger-time dispatch without writing this Apex.

Adoption Principle

Adopt incrementally: start with one module (triggers or queries), expand when the team is comfortable, add resilience patterns when integration requirements arise. Specific timelines depend on team size, existing codebase complexity, and available training time.

Testing Hybrid Implementations

Isolation Principles:

• Each framework's test patterns remain valid within their scope
• taf trigger actions test independently using standard Apex test patterns
• apex-fluently-soql queries test using direct assertions on returned data
• KernDX web services test using API_OutboundTestHelper assertions
• nebula-logger tests verify log entries using its Logger.getBufferedLogEntries() API

Integration Testing: When components from multiple frameworks interact, write integration tests that verify the handoff points:

@IsTest
private class Integration_TriggerToWebService_TEST
{
    @IsTest
    private static void shouldQueueApiCallFromTrigger()
    {
        // TAF trigger fires and queues KernDX API call
        Case record = (Case)TST_Builder.of(Case.SObjectType)
            .withOverrides(new Map<SObjectField, Object>{
                Case.Subject => 'Test', Case.Priority => 'High'
            }).build();

        // Assert: KernDX API queue item created
        List<ApiCall__c> items = QRY_Builder.selectFrom(ApiCall__c.SObjectType)
            .condition(ApiCall__c.TriggeringRecordId__c).equals(record.Id)
            .toList();
        Assert.areEqual(1, items.size(), 'Should create one API queue item');
    }
}

When NOT to Combine Frameworks

Avoid Redundant Capabilities:

• Don't install both taf and KernDX TRG_* for triggers (choose one)
• Don't install both apex-fluently-soql and KernDX QRY_Builder for queries (choose one)
• Don't install both nebula-logger and KernDX LOG_Builder for logging (choose one)

Organisational Complexity:

• If release cadence is less than quarterly, avoid managing multiple framework upgrade streams in parallel — pick one integrated stack or one modular stack and let it run
• If central architectural authority is not yet established, don't introduce competing patterns; pick one approach and ratify it before mixing
• If on-call coverage cannot sustain debugging across 5+ independent libraries' release notes, prefer a single integrated framework's release cycle

---

Adoption Roadmap

Adoption Patterns

Three models describe how KernDX is typically adopted:

1. Internal Accelerator Model

• Used within a single enterprise to standardise delivery
• Governance centralised under platform engineering
• Ownership formalised with dedicated framework maintainer
• Best fit: large enterprise orgs with multiple Salesforce teams

2. Managed Package Platform Model

• Primary alignment case — KernDX was designed for managed package development
• Requires version discipline (semantic versioning, global API stability)
• Namespace isolation provides clean boundary between framework and subscriber code
• Best fit: ISVs, AppExchange publishers, multi-tenant product teams

3. Ecosystem Alternative Model

• Positions KernDX as one option alongside modular open-source stacks
• Requires demonstrating value over taf + Apex Fluently + nebula-logger combination
• Community growth strategy needed for long-term market adoption
• Best fit: teams evaluating integrated vs modular approaches

Standalone Adoption — Logging as a No-Migration Wedge

Subscribers evaluating KernDX without committing to a full-framework adoption can start by adopting the logging capability standalone. LOG_Builder ships alongside existing subscriber automation without requiring migration of any existing triggers, queries, or DML.

Why this works as a wedge:

• TRG_LogEntryEvent fires only on the LogEntryEvent__e Platform Event — subscriber SObject triggers are not touched
• TRG_Base + TRG_Dispatcher are inert until a TriggerAction__mdt record registers a handler — an existing subscriber trigger framework continues unchanged
• UTIL_FrameworkMasker short-circuits at runtime when masking is not enabled
• UTIL_BypassAudit short-circuits in test mode

Install footprint (the caveat — auditable against the artifact list):

• Apex classes (~25): LOG_Builder, LOG_Engine, TRG_PersistLogEntry, TRG_Base, TRG_Dispatcher, IF_Trigger, DML_Builder, UTIL_String, UTIL_Random, UTIL_List, UTIL_SObjectDescribe, UTIL_Limits, UTIL_AsynchronousJobLauncher (+ UTIL_AdaptiveAsynchronousProcessor + DTO_AsynchronousJobRequest + DTO_ProcessSettings + IF_Async + IF_Queryable), UTIL_FrameworkMasker (+ SEL_MaskingRule + SEL_MaskingTarget + SEL_Base + QRY_Builder + UTIL_FeatureFlag + UTIL_AsyncChain + UTIL_Exceptions), UTIL_BypassAudit (+ SEL_LogEntry + UTIL_ValidationRule).
• Apex trigger: TRG_LogEntryEvent (after-insert on Platform Event)
• Custom SObjects: LogEntry__c (~18 fields), LogSetting__c (Custom Setting hierarchy)
• Platform Events: LogEntryEvent__e (~14 fields)
• CMDT types: TriggerAction__mdt + TriggerSetting__mdt (+ Event__c picklist + SObjectType__c → EntityDefinition lookup), plus FeatureFlag__mdt + MaskingRule__mdt + MaskingTarget__mdt (records can be empty if masking stays disabled)
• CMDT registration records (required): TriggerSetting.LogEntryEvent, TriggerAction.PersistLogEntry_AfterInsert

What this gives you: structured Apex logging via LOG_Builder.build().info('...').emitAt('Class.method'), async event-bus delivery via LogEntryEvent__e, persistent LogEntry__c records, transaction correlation, optional pre-emit regex / Luhn masking, and the option to evaluate framework discipline by adopting one capability without migrating any existing subscriber code.

What this is NOT:

• NOT a minimal install — the package deploys all 183 production Apex classes, 168 test classes, 53 LWC bundles. Unused classes are inert (no governor impact, exempt from the 6 MB managed package limit) but the namespace prefix and single upgrade cycle apply.
• NOT a way to adopt logging without the framework's broader posture — with sharing defaults, USER_MODE defaults on QRY_Builder / DML_Builder, etc., all apply to the installed classes whether or not the subscriber actively uses them.

Starting from Existing Org (Brownfield)

Weeks	Activity	Effort	Notes
1-2	Adopt trigger framework. Choose taf or KernDX TRG_*. Select highest-value trigger (most defects, most business rules, most frequently changed). Migrate to framework pattern. Achieve 100% coverage.	3-5 dev-days	taf: configure TriggerAction__mdt. KernDX: configure TriggerAction__mdt + TriggerSetting__mdt. Comparison summary: taf is the most-established comparator on declarative trigger registration, handler ordering, and Flow-as-trigger-action; KernDX matches on dispatcher substance and adds bypass audit emission (every bypass writes a structured event), performance monitoring with metadata-driven thresholds, and W3C distributed tracing.
3-4	Standardise trigger pattern. Migrate 2-3 additional triggers. Establish coding standards (bypass mechanisms, recursion handling, test patterns). Document migration playbook.	5-10 dev-days	Train team on metadata-driven configuration
5-6	Adopt query framework. Choose apex-fluently-soql or KernDX QRY_Builder. Refactor 5-10 high-complexity queries. Focus on queries with multiple filters, dynamic conditions, or caching needs.	3-5 dev-days	Measure query performance before/after. Both apex-fluently-soql and KernDX QRY_Builder default to USER_MODE on the read path. Document any framework-internal SYSTEM_MODE opt-outs via SEL_Base.systemModeRequired() (KernDX) or .systemMode() call sites (apex-fluently-soql) for code review.
7-8	Standardise query pattern. Build reusable query methods for common patterns. Establish coding standards (security modes, caching policies). Document migration playbook.	5-8 dev-days	Explore complementary libraries (apex-fluently-dml, apex-fluently-async — each Apex Fluently library installs independently from its own GitHub repo)
9-10	Adopt logging framework. Choose nebula-logger or KernDX LOG_Builder. Replace System.debug() in async processes. Configure log retention and monitoring dashboards.	2-3 dev-days	Trade-off: nebula-logger covers more aspects of the Logging family than any other Apex framework surveyed on the historical log-browser LWC, log retention purge, and pre-emit masking (default-on regex matching with four shipped rules applied before-publish on every log emission); KernDX matches on Apex / async / LWC logging plus W3C distributed tracing but uses per-SObject masking opt-in (a deliberate performance-aware trade-off).
11-12	Retrospective. Measure success metrics (code coverage, defect rates, developer velocity). Identify remaining migration candidates. Plan next quarter's framework adoption.	2-3 dev-days	Refine coding standards and CI/CD gates

Effort estimates assume a team of 5-10 developers and scale with codebase size, trigger complexity, and team familiarity with framework patterns. A smaller codebase (< 50 Apex classes) will trend toward the lower bound; a larger codebase (200+ classes) or teams new to metadata-driven patterns will trend toward the upper bound.

Migration Narratives

Subscribers migrating from one framework to another rarely move gear-for-gear. The summary below covers the honest trade for five common migration paths, grounded in the per-comparator decision trees.

From taf to KernDX

• Low-friction port. KernDX's TRG_* trigger framework is a direct evolution of taf — the Apex headers of the dispatcher and base classes retain taf attribution under Apache 2.0. The mental model is the same: metadata-driven dispatcher, one trigger-action class per concern, context interfaces (BeforeInsert / AfterUpdate / etc.), declarative bypass. A taf developer reads a KernDX trigger action and recognises it immediately; the hardest part of the port is the metadata-record schema change, not the Apex code.
• Keep: The class-per-concern discipline, the context-interface pattern, and the declarative bypass posture. IF_Trigger.BeforeInsert is the direct analogue of TriggerAction.BeforeInsert. Developers do not need re-training on the architectural model.
• Give up: The 627-star / 7-contributor community footprint and the architecture-board-signalling value of a framework maintained by Salesforce's Apex product lead.
• Gain: Flow-as-trigger-action via FlowName__c on TriggerAction__mdt (leave ApexClassName__c blank — the framework dispatches via its built-in flow runner) with declarative LogAndContinue / BlockDml error strategies, deploy-time flow-name + variable-contract scanner, and a mock harness for orchestration tests. triggerOldMap as a lazy-loaded Map<Id, SObject> for keyed lookups (taf provides list-only); performance monitoring with metadata-driven thresholds + auto-emitted audit event when a slow-action budget is exceeded (KernDX-only surveyed); W3C distributed tracing (traceparent/tracestate propagate across triggers, async chains, and API calls); feature-flag gating via FeatureFlag__mdt; bypass audit trail — every bypass call writes a structured audit event with W3C correlation ID. Across comparable Apex frameworks, only KernDX and rflib ship built-in bypass-audit emission; EntityDefinition-validated object binding instead of taf's free-text field (typo-proof).
• Schema migration: taf's sObject_Trigger_Setting__mdt + Trigger_Action__mdt (7 per-context MetadataRelationship fields) maps to KernDX's TriggerSetting__mdt + TriggerAction__mdt (single event picklist + single setting lookup). Record-by-record migration is mechanical — most teams script it once and replay. Flow-action records drop the ApexClassName__c = 'TriggerActionFlow' indirection (KernDX dispatches via its built-in flow runner whenever FlowName__c is populated and ApexClassName__c is blank) and add FailureAction__c = 'BlockDml' (validation flows) or 'LogAndContinue' (orchestration flows).
• Coexistence option: If a team already runs taf on specific objects and isn't ready to migrate, keep taf there and adopt KernDX on new objects. Both frameworks leave system Apex triggers alone; they coexist by object.

From fflib to KernDX

• Keep: Selector pattern (both frameworks ship a selector inheritance model); parent-child DML; fflib-mocks for behaviour verification — KernDX does not replace fflib_ApexMocks behaviour verification (98 matcher factories in fflib_Match, in-order sequence verification, post-hoc argument capture — KernDX absent on this surface by design).
• Give up: fflib Domain layer and fflib_Application registry — KernDX absent by design (the framework conventions document explicitly forbids fflib patterns); registerEmail() / IDoWork on fflib_SObjectUnitOfWork; domain lifecycle hooks (onValidate, onApplyDefaults). Subscribers that need Domain-Driven Design should keep fflib in place or pair KernDX with a custom domain layer.
• Gain: Metadata-driven triggers with bypass audit; per-action performance monitoring (KernDX-only); W3C distributed tracing; feature flags; circuit breaker (KernDX-only); inbound REST routing with body-hash idempotency (KernDX-only); any-SObject masking (four rule modes: regex, JSON-key, exact-match, credit-card-with-Luhn; enabling on a given SObject still requires TriggerSetting.ApplyMasking__c = true); pre-emit log masking; auto-topological DML sorting with .allowPartial(); async chain orchestration.
• Install note: fflib distribution is source deploy (apex-enterprise-patterns/fflib-apex-common), with ~16 commits and 1 tag in the last 12 months — plan for in-org source maintenance.
• Net gain on query security: fflib's newQueryFactory().setCondition(String) accepts arbitrary WHERE strings and fflib has no USER_MODE default; the static-Boolean kill-switch consulted at every check method is silent. fflib's query and DML layers ship without a security-by-default posture. KernDX QRY_Builder and DML_Builder default to USER_MODE on read AND write, with the toggle methods explicit and subscriber-write-time toggles audit-traceable. Migrating the query / DML layer off fflib is one of the larger security gains this path delivers.

From nebula-logger to KernDX LOG_Builder

• Keep: If logging is your primary need, do not migrate. nebula-logger covers more aspects of the Logging family than any other Apex framework surveyed, with the historical log-browser LWC, log retention purge, real-time event monitoring, and the depth of its logging surface (mixed transport modes, 7 log levels, four save-method strategies). KernDX matches on the core surface — Apex / async / LWC logging plus W3C distributed tracing — but the dedicated dashboard surface rests with nebula-logger.
• Give up: 10 LWC components for historical log browsing; Big Object archival; plugin framework (Slack, Big Object, async plugins); 7 log levels (vs 4 in KernDX); four save-method strategies.
• Gain: W3C traceparent / tracestate header propagation across async chains and outbound API calls; automatic instrumentation of every KernDX trigger, query, DML, and API call; auto-publish (no forgotten Logger.saveLog()); ERROR bypass buffering; typed async context serialisation. KernDX is the only Apex framework surveyed covering logging woven into trigger bypass auditing, DML failure handling, outbound HTTP correlation, and inbound idempotency tracking via shared correlation IDs.
• Not a pure gain on masking: nebula-logger covers more aspects of pre-emit log masking than any other Apex framework surveyed — default-on regex matching with four shipped rules applied before-publish on every log emission. KernDX's per-SObject opt-in via MaskingTarget__mdt + TriggerSetting.ApplyMasking__c = true is a deliberate performance-aware trade-off that lets subscribers configure masking only where their data warrants it. KernDX covers more aspects of cross-surface masking scope — KernDX masking covers platform events, chain executions, API calls — not just log entries.
• Coexistence option: Run both. KernDX LOG_Builder for framework infrastructure logging with W3C tracing + bypass audit emission; nebula-logger for business audit trails with log browser + Big Object archival + default-on regex masking. Cost: two log storage tables.

From rflib to KernDX

• Keep: rflib's v9.1.0 adopted apex-fluently-soql — if you rely on rflib_DefaultLogger and the 4-level feature-switch hierarchy, they remain functional in an org that also installs KernDX. Before migrating, note that rflib_DefaultLogger is declared without sharing with masking off by default — an operational claim worth reviewing. On Feature Switch specifically, rflib has a longer established adoption history; KernDX matches on substance with the UTIL_FeatureFlag strategy resolution.
• Give up: Platform-event-based trigger retry up to 8 retries (rflib's only feature with no KernDX equivalent at the trigger layer); Big Object log archival; the fixed 4-level feature-switch hierarchy if your admin UX depends on it; "Ops Center" visibility habits tied to rflib's dashboards.
• Gain: Outbound HTTP framework (KernDX covers every aspect in the family); circuit breaker (KernDX-only); selector pattern (both ship one); inbound REST routing with body-hash idempotency (KernDX-only); W3C distributed tracing; any-SObject masking (KernDX-only between these two). KernDX matches rflib on bypass audit emission — the only two frameworks surveyed with built-in bypass-audit emission.
• Not a pure gain on logging: Per the scoring across comparable Apex frameworks, rflib and nebula-logger carry the established adoption signal on the Logging family; KernDX matches them on the substantive logging surface. On Logging-family adoption signal, rflib and nebula-logger (and apex-libra) carry the strongest independent uptake.

From Apex Fluently (multi-library) to KernDX

> Maintainer note (relevant if multi-contributor maintainership matters to your team): The 8 Apex Fluently libraries share a single primary author, so a full Apex Fluently > stack is effectively a single-maintainer dependency (or two maintainers if a separately-maintained logger such as nebula-logger is paired alongside). This is the norm rather than > the exception: most comparable Apex frameworks are also single-maintainer; only the fflib family has genuinely distributed maintainership. > See Architecture & Philosophy — Bus Factor Mitigation for the per-framework breakdown.

• Keep: Apex Fluently is 8 independently-shipped MIT libraries (apex-fluently-soql, apex-fluently-dml, apex-fluently-async, apex-fluently-httpmock, apex-fluently-cache, apex-fluently-consts, apex-fluently-test (Beta), apex-fluently-lwc). "Migrating to KernDX" is really a set of per-library swap decisions, not one decision. Each library can remain in place if the corresponding KernDX module does not improve on it for your use case.
• Give up: Specialty query surface in apex-fluently-soql — semi-join, cursor pagination, ROLLUP / CUBE aggregates, conditionLogic('1 OR (2 AND 3)') string expressions, toLabel(), ignoreWhen(), named mock IDs (KernDX matches on substance for aggregates via .toAggregateList() / .rollup() / .cube() / .grouping(field)); apex-fluently-async chain surface (KernDX matches on substance); the larger public community on each library. Security-default parity on the read path: both default to USER_MODE — equivalent on substance.
• Gain: Logging (none in Apex Fluently — LOG_Builder ships the full logging surface); outbound HTTP framework with circuit breaker (KernDX-only); inbound REST framework (KernDX-only); resilience primitives (feature flag, utilities, async chain); security modules (session encryption, payload signing — KernDX-only; data masking — Apex Fluently absent); LWC framework (KernDX-only); CI tooling (KernDX-only); health diagnostics; integration coherence (single set of conventions in docs/Code Conventions - Guide.md vs 8 READMEs).
• Install note: You don't have to pick one or the other. Most Apex Fluently libraries can be kept alongside KernDX; the cost is two sets of conventions and two maintenance calendars per library you keep. apex-fluently-async and UTIL_AsyncChain overlap in scope — pick one for chain orchestration. apex-chainable should not be added to a KernDX-plus-apex-fluently-async stack because its dispatcher ships a reflective-execution path.

Organisational Readiness

Framework adoption is a team activity, not a tooling decision. Even the best framework fails without buy-in. Start with a pilot team of 2-3 developers who are willing to learn and provide feedback. Measure concrete metrics during the pilot — code review cycle time, production defect rate, and new developer onboarding time — to build a data-driven case for broader rollout. See Personas for stakeholder-specific guidance on building alignment.

Adoption Governance Model

The following governance structure applies to any framework adoption — integrated or modular:

┌─────────────────────────────────────────────────────────────┐
│                ADOPTION GOVERNANCE MODEL                    │
│                                                             │
│   ┌──────────────────────────┐                              │
│   │  Architecture Authority  │  Selects framework(s),       │
│   │  (ARB / Platform Lead)   │  defines adoption gates,     │
│   │                          │  approves exceptions         │
│   └────────────┬─────────────┘                              │
│                │                                            │
│                ▼                                            │
│   ┌──────────────────────────┐                              │
│   │  Core Maintainers        │  Manages upgrades,           │
│   │  (Platform Engineering)  │  documentation, AI context,  │
│   │                          │  version compatibility       │
│   └────────────┬─────────────┘                              │
│                │                                            │
│                ▼                                            │
│   ┌──────────────────────────┐                              │
│   │  Contributing Teams      │  Builds features using       │
│   │  (Delivery / SI Teams)   │  framework patterns,         │
│   │                          │  follows conventions         │
│   └────────────┬─────────────┘                              │
│                │                                            │
│                ▼                                            │
│   ┌──────────────────────────┐                              │
│   │  Release Approval Gate   │  CI/CD, code review,         │
│   │  (Automated + Manual)    │  PMD, coverage, convention   │
│   │                          │  compliance verification     │
│   └──────────────────────────┘                              │
└─────────────────────────────────────────────────────────────┘

Operational Ownership Model

Framework adoption requires clear ownership after initial implementation:

Responsibility	Owner	Cadence
Framework version upgrades	Platform Engineering	Per release cycle
Error log review and trending	Platform Engineering	Weekly
Agent action monitoring (if applicable)	Product + Engineering	Weekly
docs/Code Conventions - Guide.md / instruction file maintenance	Engineering	When patterns change
Cost monitoring (token/credit usage, if applicable)	Product + Finance	Monthly
Incident response (framework issues)	Engineering	As needed
Change management (adoption rollout)	Product + Engineering	Per adoption phase

This model applies regardless of framework choice (taf, apex-fluently-soql, KernDX, or a combination).

Success Metrics

Measure framework adoption impact with concrete, team-agnostic metrics:

Metric	Baseline (Pre-Framework)	Target (Post-Framework)	How to Measure
Code coverage	75-85%	100% per-file Apex + 95% statement/branch LWC	sf apex run test --code-coverage
New developer onboarding	4-8 weeks to first production PR	1-2 weeks	Track time from team join to first merged PR
Production defect rate	Varies	30-50% reduction	Track defects per sprint/release
Code review cycle time	2-5 days	1-2 days	PR open then approved duration
Deployment frequency	Monthly	Weekly or bi-weekly	Successful production deployments per month
System.debug statements	Present in codebase	Zero	grep -r "System.debug" force-app/
Inline SOQL statements	Present in codebase	Zero	grep -rn "\[SELECT" force-app/
Test execution time	Varies	< 15 minutes for full suite	sf apex run test duration

Leading indicators (measure early, predict success):

• Developer satisfaction survey (quarterly, anonymous)
• Framework pattern adoption rate (% of new classes following conventions)
• AI code generation accuracy (% of AI-generated code passing review without changes)

Lagging indicators (measure later, confirm value):

• Production incident rate reduction
• Total cost of ownership vs pre-framework baseline
• Cross-team collaboration velocity (time to contribute to unfamiliar module)

---

Conclusion

Summary

The Salesforce framework ecosystem now has two viable full-stack approaches: Apex Fluently (modular open-source, 8 independent MIT libraries — each installed from its own GitHub repo) and KernDX (integrated managed package). Both cover triggers (the announced Apex Fluently Trigger Lib is not yet released — teams use taf today), queries, DML, caching, async, HTTP mocking, and test data. Both default to USER_MODE on the query layer — equivalent on read-path security. Apex Fluently does not ship logging, web services, resilience, masking, encryption / signing, inbound REST routing, an LWC framework, or CI tooling — a KernDX-equivalent modular stack pairs Apex Fluently with nebula-logger and custom resilience / security code. KernDX ships production-ready implementations of every core Salesforce capability, broader than the comparable Apex frameworks the team has surveyed. The choice between them depends on whether your team prioritises established adoption history and specialty depth on individual surfaces (modular stack) or framework-wide cohesion, broad capability coverage, default-on USER_MODE on read AND write, and bypass audit emission (KernDX).

KernDX provides an integrated alternative to modular assembly. It comes with trade-offs that matter:

Strength	Corresponding Weakness
Integrated stack covering every core Salesforce capability (broader than the comparable Apex frameworks surveyed)	Full package deployment (unused code is inert — exempt from 6 MB, invisible to subscriber quality tools, zero governor impact — but namespace prefix and single upgrade cycle apply)
Automatic cross-trigger / cross-API observability and log correlation via W3C tracing; only KernDX and rflib ship built-in bypass-audit emission across comparable Apex frameworks	Single vendor dependency
100% per-file Apex coverage gate + 95% statement/branch LWC, enforced at every release build; full ApexDoc; zero real-issue scanner findings	Higher initial development cost
Five-tier documentation architecture (14 guides + 12 Fast Starts + 263 reference pages + 2,027-line Security Guide + AI-context bundle)	Single developer authored it
Managed package (1 install, 1 upgrade, exempt from 6 MB); 107 distinct package version IDs in sfdx-project.json	Cannot modify managed source directly
Zero licensing fees; source publicly available under BSL 1.1 (relicenses to Apache 2.0 after the four-year change date); broader capability coverage than the comparable Apex frameworks surveyed (see Overview § Headline Finding)	Newly public framework — at least one known external client engagement at the snapshot date and a short public production track record so far; broader production references will accumulate as more subscribers install the public release. Subscribers weighting accumulated activity history as a primary criterion should weigh that against KernDX's framework-wide capability footprint
Subscriber-first design — release-testing harness with 471 anonymous-Apex assertions across 71 sections, 151 test methods across 22 subscriber test classes; load testing suite; rolling perf-history baselines; release runbook; drift-audit cycle	No public community (yet) — discoverability remains low

KernDX's trigger framework was adapted from taf. UTIL_Security originally descended from fflib but was replaced by platform-native QRY_Builder.withUserMode() and .stripInaccessible(). rflib adopted apex-fluently-soql. Frameworks learn from each other — teams should choose based on actual constraints.

What Comes Next

Milestone	Status	Impact
1.0 package release	In progress	First GA version
Open-source publishing	Planned	Community access, external validation
AppExchange listing	Planned	Enterprise distribution channel
Apex Cursors integration	Planned (Spring '26 GA)	50M-row processing capability
Named Query API support	Evaluating	REST exposure without custom Apex

Decision Framework

Condition	Integrated Approach (KernDX)	Modular Approach (taf + Apex Fluently + nebula-logger)
Building a managed package	Strong fit — designed for 2GP lifecycle	Viable — source distribution, no namespace isolation
Coordinated resilience patterns needed	Strong fit — retry, circuit breaker, outbox built in	Requires custom engineering per pattern
Centralised governance exists	Strong fit — framework encapsulates conventions	Strong fit — architectural discipline enforces standards
OSI-approved licensing required at install time	Weaker fit — BSL 1.1 with four-year change date to Apache 2.0; single-maintainer (this is the norm — most comparable Apex frameworks are also single-maintainer; see Risks — Bus Factor Reframe)	Strong fit on license — MIT-licensed, public GitHub repos. Multi-contributor maintainership lives mostly in the fflib family.
Incremental per-library adoption preferred	Moderate fit — per-module adoption possible	Strong fit — install only what you need
Architecture board requires public governance	Weaker fit — private CI, internal contribution model, BSL 1.1 license	Strong fit on CI visibility — public GitHub Actions. Most modular alternatives are still single-maintainer projects, so "community governance" is largely "one maintainer plus public CI" rather than a multi-contributor governance model; see Risks — Bus Factor Reframe

Decision Summary Matrix

Scenario	Recommended Posture
Greenfield managed package, single SI	Evaluate KernDX — see Decision Criteria for the per-factor rationale
Greenfield org, multiple SIs	Depends on governance strength, not framework choice — see Multi-SI Challenge. Without a central architectural authority, both integrated and modular stacks fragment under multi-SI delivery. With central authority, either is viable.
Brownfield with fflib	Freeze and contain; adopt modular libraries for new work — see Migration Narratives for the fflib coexistence guidance
Integration-heavy, single governance	Evaluate KernDX for web services layer — see Core Pattern Comparison for the inbound / outbound mechanism inventory
Open-source mandate	Modular OSS stack only — see Architecture & Philosophy — Licensing Considerations
Architecture board requires multi-contributor maintainership	The fflib family is the only modular alternative with genuinely distributed maintainership. Most other modular libraries (including the full Apex Fluently stack, which is effectively two maintainers — a single primary author across the 8 Apex Fluently libraries, plus the nebula-logger maintainer if it's included) are still single-maintainer projects. See Architecture & Philosophy — Bus Factor Mitigation
Small team (< 5), greenfield	Either — KernDX (incremental) or taf + apex-fluently-soql; see Onboarding Time Comparison for the per-module timing
Enterprise (1000+ users), weak governance	Evaluate KernDX for convention enforcement; accept single-maintainer risk. (This risk applies to most alternatives too — most comparable Apex frameworks are also single-maintainer. See Risks — Bus Factor Reframe.)

| High team turnover (>40% annual) | Either stack is viable — per-module onboarding times are comparable across the comparable Apex frameworks (see Onboarding Time Comparison). Pick based on your team's existing framework experience and the libraries already in your hiring pipeline, not on a generic "hiring liquidity" claim about any specific framework. | | Consulting handover to client team | Either stack is viable. If the client team already uses a specific modular library, hand off in that library so they continue with what they know. Otherwise, hand off in KernDX — source is publicly available under BSL 1.1 from day one (consulting engagements include direct source delivery and handover support), so the client owns the framework. |

---