Strategic Guide — Risks

What this guide is: an honest catalogue of the downsides, limits, and open questions of adopting KernDX, written for the people whose job is to find them. Why it exists: no framework is the right choice everywhere, and a governance review deserves a straight answer rather than a sales pitch. This guide names where KernDX is the wrong fit, where a specialist library does a particular job better, what could go wrong technically and organisationally, and how each risk is mitigated. Who should read it: architects, governance reviewers, and the executives or delivery managers who sign off on a framework. When to use it: when you are weighing KernDX against the alternatives, or preparing for the questions an architecture review board will ask.

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

Primary reader: an architect, governance reviewer, or executive evaluating the downsides of adoption, including the hard questions an architecture review board will ask. For decision support and the roll-out plan, see Adoption. For runtime operating-cost and exit mechanics, see Operations.

---

Table of Contents

• When NOT to Use KernDX
• When Modular Architectures Clearly Excel
• Risks, Mitigations & Trade-offs
  • Technical Risks
  • Organisational Risks
  • Ecosystem Risks
  • Enterprise Risk Dimensions
  • Potential Drawbacks
  • Modular Stack Risks
  • Bus Factor Reframe — Institutional Knowledge Survival via Documentation Depth
  • Community Support: Signal vs Substance
  • Governance Model
  • Versioning & API Stability
  • Adoption Gate Criteria
  • Hard Questions Architecture Review Boards Will Ask
  • Strategic Recommendations

When NOT to Use KernDX

KernDX is a broad foundation, but breadth is not always what you need. The table below names the situations where a different choice is genuinely better, and what to pick instead. Read it before you read anything KernDX does well: if your situation is in this list, the rest of the strategic guides matter less than the row that fits you.

Scenario	Constraint	Why KernDX Is a Poor Fit	Recommended Alternative
Single concern with a feature genuinely absent from KernDX (per-record log retention overrides, log analytics dashboards)	Feature-specific gaps in KernDX	nebula-logger ships per-record retention overrides and log analytics dashboards; KernDX's retention is a global window and its Log Console covers browsing and search, not dashboards. (Masking is not a differentiator here: KernDX also masks by default, covering secrets and payment cards across its diagnostic objects, log events included, plus more tested rules that enable on any object.) On query-layer security both apex-fluently-soql and KernDX QRY_Builder default to USER_MODE (runs with the current user's read/write permissions and record sharing enforced), so they are equivalent on substance. (taf and KernDX both react to record-change events and run follow-up work after the transaction commits.) For a single-concern use where these features aren't needed, KernDX is still viable, because unused code is inert in a managed package	taf (triggers), nebula-logger (logging depth), apex-fluently-soql (queries, no namespace)
Domain-Driven Design is required	Complex domain model with bounded contexts	KernDX is service-oriented, not Domain-Driven	fflib or at4dx
OSI-approved permissive licensing required on the immediate procurement window	Architecture board or policy mandate accepts only MIT/Apache-2.0/BSD on every dependency at install time	KernDX is BSL 1.1 (source-available, public repository, relicenses to Apache 2.0 after the four-year change date); functionally close to OSI for your use as an adopter, but not OSI-approved during the BSL window	taf (Apache 2.0) + apex-fluently-soql (MIT) + nebula-logger (MIT): all OSI-approved permissive licences, available today
Existing modular stack working well	Coherence is already managed; migration cost exceeds benefit	Disruption risk outweighs marginal improvement	Continue current approach
Consulting project requiring framework familiarity at handover	Client must maintain code independently post-handover	If the client team already uses a specific modular library, hand off in that library so they continue with what they know. KernDX onboarding requires per-module learning of the framework's conventions	taf + apex-fluently-soql (or whichever libraries the client team already uses)
Multiple independent delivery partners with no shared governance	No central architectural authority to enforce conventions	KernDX's value depends on consistent usage; ungoverned adoption results in partial framework use	Modular OSS stack with per-SI adoption
High team turnover (>40% annual)	Continuous developer churn	Per-module onboarding times are comparable across comparable Apex frameworks (see Onboarding Time Comparison); high turnover offsets KernDX's documentation-depth advantage by repeatedly resetting the ramp curve. Pick based on the team's existing framework experience and the libraries already in your hiring pipeline	taf + apex-fluently-soql (if the team or its replacements already use them)
Public ecosystem credibility is a hard requirement during the immediate procurement window	Architecture board requires OSI-approved licensing AND multi-contributor community validation at install time	KernDX is BSL 1.1 (source-available, published in a public repository, relicenses to Apache 2.0 after the four-year change date), single maintainer at the snapshot date. Most comparable Apex frameworks are also single-maintainer (only the fflib family carries distributed maintainership), so modular OSS alternatives address the OSI-licence and public-repository requirement, not necessarily the contributor-count one. See Bus Factor Reframe	taf + Apex Fluently + nebula-logger for OSI-licence + public-repo requirements at install time; only the fflib family if multi-contributor maintainership is also required
Regulatory audit requiring multi-vendor traceability	Compliance requires demonstrable multi-vendor supply chain	Single-vendor BSL framework complicates audit narrative	Open-source stack with public commit history

When Modular Architectures Clearly Excel

Sometimes a hand-picked set of separate open-source libraries (a modular stack) is unambiguously the right choice, and KernDX is not. The scenarios in the table below are those cases. They are real and load-bearing, not a token concession.

One framing caveat before you read it. When this guide says "modular" it means the licence model and the source-ownership story, not the size of the contributor community. Most of the popular modular libraries are themselves single-maintainer projects (most comparable Apex frameworks are single-maintainer; only the fflib family has distributed maintainership). So if your requirement includes multiple active maintainers, read the Bus Factor Reframe before assuming "modular" means "community-maintained".

Scenario	Why Modular Fits
Highly specialised internal Salesforce teams with deep platform expertise	Team can curate libraries individually and maintain consistency through expertise rather than framework enforcement
Organisations with long-term in-house ownership and stable engineering teams	Institutional knowledge persists; framework-imposed conventions are redundant when team culture enforces them
Cost-sensitive environments avoiding any centralised dependency	Zero vendor dependency; no managed package lifecycle to manage; issue trackers are publicly visible on GitHub
Platform R&D orgs experimenting with architectural patterns	Modular adoption allows swapping individual libraries without rearchitecting; ideal for evaluating emerging tools
Organisations requiring public governance for audit or compliance	Public GitHub repos and open commit history satisfy audit requirements that private frameworks cannot. If the audit also demands multi-contributor maintainership, only the fflib family genuinely qualifies (per the Bus Factor Reframe); most other community libraries are also single-maintainer

In these contexts, KernDX may introduce abstraction and operational overhead you do not need, and a modular stack is the better fit. For a capability-by-capability comparison of KernDX against each of these libraries, including where a specialised library is the better pick, see Choosing a Framework.

---

Risks, Mitigations & Trade-offs

The tables below lay out the known risks of both approaches, side by side: adopting one integrated framework like KernDX, and assembling your own modular stack from separate libraries. For each risk you get how likely it is, how much it would hurt, how feasible the mitigation is, and the net exposure that remains after mitigation. The point is to let you compare like with like rather than to argue one approach is risk-free.

Technical Risks

Risk	Likelihood	Impact	Mitigation Feasibility	Net Exposure	Justification
Package overhead in CPU-intensive operations	Low	Low	High	Low	Pre-compiled managed package; benchmark hot paths
Dependency on Salesforce platform roadmap	Medium	Medium	High	Low	Standard Apex only; no unsupported API usage
Managed package namespace constraints	Low	Low	High	Low	Three exit paths including namespace removal
Metadata configuration sprawl	Medium	Medium	High	Low-Medium	Document metadata inventory; migration effort is ~1-2 days agent-executed against the AI-context bundle (or 1-2 weeks conventional human-only) for deeply adopted orgs. Mitigation Feasibility rated High because exit mechanics are now routine for an AI-equipped team, so the residual risk is absorbable inside a single sprint rather than a multi-week project.
Over-abstraction risk	Low	Medium	High	Low	Incremental adoption; unused modules are inert
Developer cognitive load	Medium	Low	High	Low	Per-module learning; AGENTS.md + docs/Code Conventions - Guide.md + Fast Starts reduce ramp
Framework updates break existing code	Low	High	High	Low	2GP version locking; sandbox testing before production; semantic versioning
Static methods harder to mock in tests	Low	Low	High	Low	Built-in mocking: QRY_Builder.setMock(), TST_Mock.register(), API_MockFactory
Data Access Governance on auxiliary read paths (framework-internal SYSTEM_MODE selectors)	Low	Low-Medium	High	Low	By default KernDX queries and writes (QRY_Builder / DML_Builder) run with the current user's permissions and record sharing enforced (USER_MODE), on both read AND write. 33 framework-internal selectors deliberately opt back into SYSTEM_MODE (which skips those checks) via SEL_Base.systemModeRequired(); every such opt-out is documented, audit-traceable, and scanner-enforced, and a CI-blocking scanner rule prevents regression. Metadata flags act as a master off-switch you can flip in an incident without a deployment: change one record, no code deploy, to revert if you hit unexpected access denials.
Critical bug in managed package class	Low	High	Medium	Medium	Handler bugs: bypass via metadata. Infrastructure bugs (QRY_Builder, DML_Builder): you cannot hotfix these yourself; fixing one needs a vendor push upgrade or taking source ownership and repackaging. This is the same constraint as Financial Services Cloud / CPQ.

P1 Hotfix Mitigation: A common architecture-board concern with managed packages is: "What if a critical bug is found inside a framework class and the vendor is unavailable?" KernDX's metadata-driven architecture provides multiple isolation mechanisms that do not require code deployment or a vendor push upgrade:

Mechanism	Scope	Action	Code Deploy Required
TRG_Base.bypassAction(className)	Single trigger handler	Programmatically skip a specific handler for the remainder of the transaction	No (Apex API call)
TriggerSetting__mdt.BypassExecution__c	All handlers for an object	Declaratively disable all trigger processing for an SObject type	No (metadata deploy)
FeatureFlag__mdt	Entire feature path	Disable a feature flag, which prevents associated trigger actions from executing	No (metadata deploy)
Web service feature flags	Specific API handler	Disable outbound/inbound web service processing via FeatureFlag__mdt	No (metadata deploy)
Chain Monitor stop action	Single running chain	Stop a background chain that is already running; ends at the next step boundary	No (console action)
Source ownership + repackaging	Any framework class	Fork the public source (BSL 1.1), fix the bug, repackage under client namespace	Yes (the exit strategy)

The chain stop needs one piece of setup before an incident, not during one. It sits behind a permission set that ships assigned to nobody, and whoever holds that permission also needs the Administrator permission set to read chain data at all, so assign both to your on-call operators while things are calm. The framework's chain recovery job works the same way. It checks whether a chain's work is genuinely still running, safely restarts the runs it can prove died, and marks the ones it cannot prove dead for a person to look at rather than touching them, but it runs only once an admin schedules it (the Health Check offers a one-click way to schedule it). A restarted run picks up under the framework's default settings rather than the settings its original builder set.

Every bypass is audit-logged by default, so you can see who turned a safety check off and why. Every bypass call writes a structured audit event via LOG_Builder, carrying the W3C correlation ID (one tracking ID that follows a single user action across triggers, queries, callouts and jobs). That means every bypass is traceable across triggers, async chains, and API calls, whether it was a deliberate P1 mitigation or an accidental call inside a loop. You get auditable evidence of every emergency bypass without writing any logging code yourself. This matters because it is not the norm: across comparable Apex frameworks, only KernDX and rflib record this automatically every time a safety check is turned off. The others leave no trace when a check is switched off: taf's programmatic bypass surface, fflib's static-Boolean kill-switch, apex-libra's disableTrigger / asSystemWithoutSharing, and the Apex Fluently programmatic surfaces all leave no trace on bypass.

Two tiers of risk, with honest trade-offs:

Tier 1, pluggable handler bugs (trigger actions, API handlers, chain steps): The bypass mechanisms above let you disable the faulty handler and deploy a temporary replacement in your own code. This is a real, tested mitigation, and it needs no vendor involvement. If a faulty chain step is already mid-run, the Chain Monitor stop action ends that run at its next step boundary.

Tier 2, infrastructure bugs (QRY_Builder, DML_Builder, TRG_Dispatcher, LOG_Builder): you cannot hotfix these. They are compiled inside the managed package, and no bypass mechanism helps because your code calls into them. Your options are: wait for a vendor push upgrade, work around the specific bug in your own code (for example, write raw SOQL for the affected query pattern), or trigger the source-ownership exit strategy. This is the inherent trade-off of any managed package: Salesforce's own products (Financial Services Cloud, CPQ, Health Cloud) carry the same constraint.

What mitigates the Tier 2 risk: Infrastructure classes are the most stable and most heavily tested components in the framework. They are covered by 180 Apex test classes (4,082 @IsTest methods) plus the LWC Jest suite, gated at 100% per-file Apex coverage and 95% statement/branch LWC coverage, enforced at every release build and validated against the subscriber-side release-testing harness (561 anonymous-Apex assertions across 76 sections, 190 test methods across 41 subscriber test classes). They change less frequently than handler logic and are validated across every package build (128 published managed-package versions declared in sfdx-project.json). The risk is real but low-probability. Before adopting, your org should evaluate whether the vendor's support responsiveness is acceptable for your SLA, and keep the exit-strategy documentation current.

What ClassTypeResolver__mdt provides: a way to extend the framework, not to replace it. You inject your own new handlers, strategies, and chain steps into the framework's resolution chain by adding configuration records (custom metadata); the framework then finds those classes in your namespace at runtime via UTIL_System.getTypeForClassName(). This is a dependency-injection mechanism for extending the framework, not a hotfix path for replacing package internals.

Organisational Risks

Risk	Likelihood	Impact	Mitigation Feasibility	Net Exposure	Justification
Knowledge concentration (bus factor)	Medium	High	Medium	Medium	Source ownership + AI-context files (AGENTS.md + docs/Code Conventions - Guide.md at repo root plus the AI Agent Instructions framework reference), 37 developer documents, 270 API reference pages, standard patterns, metadata-driven bypass for P1 isolation
No public community	Medium	Low	Medium	Low	Documentation + AI context for self-service
Limited market familiarity	Medium	Low	High	Low	KernDX uses standard Apex patterns (selectors, triggers, and DTOs, the small classes that hold exactly the fields you move in or out and convert themselves to and from JSON); the ramp gap is per-module API familiarity, not a language or paradigm change. Per-module onboarding times are comparable across comparable Apex frameworks (see Onboarding Time Comparison)
Internal support dependency	Medium	Medium	Medium	Medium	Source ownership + exit strategy
Developers misuse static utilities	Medium	Medium	High	Low	Code review standards; limit scope to infrastructure
Agentforce Vibes lock-in	Medium	Medium	High	Low	Instruction files work with any AI tool (Claude Code, Cursor, Cline)

Ecosystem Risks

Risk	Likelihood	Impact	Mitigation Feasibility	Net Exposure	Justification
Salesforce deprecates platform features used by framework	Low	High	High	Low	Standard Apex only; no unsupported APIs
Competing frameworks improve significantly	High	Low	High	Low	Framework is an accelerator, not a locked dependency
AI tooling reduces framework value	Medium	Medium	Medium	Medium	AI tools work with conventions, not against them
Abandoned library risk (modular stacks)	Medium	High	Medium	Medium	Open-source libraries depend on maintainer motivation; fork potential mitigates

Enterprise Risk Dimensions

These are the risk categories an architecture board usually scores a framework against. For each one, this section says whether KernDX makes the risk worse ("amplifies") or better ("mitigates"), and what backs that up. Where a modular stack faces the same category differently, that is noted too.

• Concentration Risk (single maintainer)
  • KernDX: Amplifies, because there is a single primary developer. This matches the norm across comparable Apex frameworks: most are also single-maintainer (only the fflib family carries distributed maintainership).
  • Mitigation: the source is publicly available under BSL 1.1, so any team can clone and self-maintain regardless of vendor status, and consulting engagements include direct source delivery and handover support. On top of that you get standard Apex patterns, AI-context files, 37 developer documents, and shipped repackaging-under-client-namespace tooling.
  • Audit framing: the question your audit team needs to answer ("is the framework defensible if the maintainer is unavailable?") can be answered straight from the documentation inventory (Bus Factor Reframe below), rather than depending on one person's availability. The checks and conventions are documented in the repository and built in, not left to every developer to remember from the maintainer's memory.
• Upgrade Risk (API instability)
  • KernDX: Mitigates after 1.0, through semantic versioning and a global API stability commitment
  • Mitigation: 2GP version locking, sandbox testing before production
• Survivability Risk (abandonment)
  • KernDX: Low. The source is publicly available under BSL 1.1 (which relicenses to Apache 2.0 after the four-year change date), so any team can fork and self-maintain regardless of vendor status. KernDX is one of the few Apex frameworks that ships explicit repackaging-under-client-namespace tooling and an Unmanaged.zip exit artefact, so the practical exit path is more thorough than "source on GitHub" alone.
  • Mitigation: Public source access, standard Apex patterns, shipped repackaging tooling, documented exit strategy to modular stack.
• Hiring & Ramp Risk (per-framework familiarity in the hiring pipeline)
  • This guide does not measure how deep the hiring market is for any framework, KernDX or its alternatives, so a claim that "this framework is easier to hire for" is not load-bearing without your own data. Per-module onboarding times are comparable across comparable Apex frameworks (see Onboarding Time Comparison).
  • KernDX: it uses standard Apex patterns (selectors, triggers, DTOs) that transfer from fflib or taf experience, so the ramp gap is per-module API familiarity, not a paradigm shift. In high-turnover environments, base adoption decisions on your team's own historical onboarding data, not on generic hiring-market claims about any specific framework.
  • Mitigation: KernDX documentation depth (21 developer guides, 16 Fast Starts, 270 API reference pages) plus AGENTS.md and docs/Code Conventions - Guide.md reduce per-new-hire ramp time; measure against your team's own baseline.
• Governance Drift Risk (different teams gradually picking different patterns)
  • KernDX: Mitigates, because the managed package keeps the conventions in one place
  • Modular stacks: Amplifies, because they require active architectural discipline across independent libraries
• Vendor Lock-in Risk (internal framework dependency)
  • KernDX: Low. It is a managed package with three explicitly documented exit paths (namespace removal, unlocked conversion via Unmanaged.zip, and repackage-under-client-namespace using the shipped tooling). KernDX is unusual among comparable Apex frameworks in shipping a complete repackaging workflow as a first-class exit path, not just publishing source on GitHub.
  • Mitigation: Three documented exit strategies plus public source access under BSL 1.1.
• Architecture Board Approval Risk (governance review criteria)
  • KernDX: Moderate. BSL 1.1 is source-available with a four-year change date to Apache 2.0 (functionally close to OSI for your use as an adopter; the structural gap is the commercial-redistribution restriction during the BSL period). There is a single maintainer at the snapshot date, and the public release brings the source into the open during the BSL window. Architecture boards requiring strict OSI-approved licensing on the immediate procurement window may still favour MIT/Apache alternatives; boards accepting source-available with a documented relicense path can adopt KernDX today.
  • Mitigation: Documented governance model, publicly available source under BSL 1.1, standard Apex patterns, time-boxed pilot.

Potential Drawbacks

These are the specific things KernDX does not do, or does in a way you may not expect. Several rows name a competitor that does a particular job better; those concessions are real, and the alternative is named so you can judge whether the gap matters for you.

Drawback	Context
All-or-nothing installation	Unused code is inert (no CPU, no governor limits). Package exempt from 6 MB limit.
Framework-internal SYSTEM_MODE selectors (auxiliary read paths)	QRY_Builder and DML_Builder default to USER_MODE (the running user's permissions and sharing enforced) on read AND write. 33 framework-internal selectors (configuration reads, Chain Monitor aggregates, and similar) opt back into SYSTEM_MODE via the documented SEL_Base.systemModeRequired() hook. Each of those declarations is auditable in source and enforced by a CI-blocking scanner rule that fails builds on undeclared access modes. When you extend SEL_Base you inherit USER_MODE by default; opting out requires an explicit override. Emergency rollback is a metadata flip, no code deploy.
Leaner logging depth than the logging specialist	For logging specifically, nebula-logger covers more aspects of the Logging family than any other Apex framework surveyed: a choice of how logs are saved, all seven platform log levels, per-record retention overrides and purge, and log analytics dashboards. KernDX ships four levels on a single async transport, real-time log monitoring via Streaming Event Monitor, and the Log Console for browsing past entries (recurring problems grouped with occurrence counts, severity filtering, search, and a per-operation drilldown), with LogEntry__c fully queryable and masking-applied for reports and dashboards you build. The remaining gaps are transport choice, level count, retention overrides, and ready-made dashboards.
Log delivery is best-effort	The logger is designed never to crash or roll back your business transaction, and the trade-off is that a log entry can be silently lost. If the platform-event publish fails, the most you get is a debug line visible only while an Apex trace flag is active, and a per-event rejection leaves no trace at all; per-event publish errors are not inspected, there is no retry and no fallback write to LogEntry__c, and a buffered flush clears the buffer whether or not the publish succeeded. A dropped log entry is therefore indistinguishable from no log entry.
Flow-as-trigger-action: typed-collection input shape	KernDX TRG_InvokeFlow ships with declarative failure-action custom metadata, a deploy-time scanner, a mock harness, and inherited recursion / perf / audit / feature-flag gating. taf covers the typed List<SObject> collection input shape that KernDX does not. The reason is a platform limit: Invocable.Action.setInvocations cannot pass typed collections to typed Flow inputs at API 67.0, so KernDX ships per-record dispatch instead.
No retryable trigger actions	rflib supports Platform Event-based trigger retry (up to 8 retries), which KernDX does not. KernDX retry covers outbound HTTP calls and, as a choice you opt into, the individual steps of a background chain: a step can take a bounded number of attempts with a widening delay between them. Neither covers trigger handlers.
No Domain layer	fflib ships the Domain / Application factory surface; KernDX is absent on this family by deliberate design (the framework conventions document forbids fflib patterns). If you require Domain-Driven Design, keep fflib or layer a custom domain on top of KernDX utilities.
Chain monitor controller selectors run in SYSTEM_MODE	CTRL_ChainMonitor / CTRL_EventMonitor inherit SEL_Base defaults. When you switch off the permission and sharing checks on an individual QRY_Builder or DML_Builder call in your own code, the framework records it at runtime: the call that runs the query or DML writes a bypass audit entry per touched object, the same trace that handler bypasses leave. Framework-internal selectors such as these monitor controllers use an un-audited system-mode path by design.
Namespace verbosity	Your code has to include the namespace prefix. Modern IDEs auto-complete this.

Modular Stack Risks

For balance, here are the risks that come with the other approach: assembling your own stack from separate libraries (taf + apex-fluently-soql + nebula-logger, and so on).

Framing caveat: these modular-stack risks are scored on the same High-likelihood / High-impact scale that the Technical, Organisational, and Ecosystem Risks tables above use for KernDX. Neither approach is risk-free. Both stacks carry High-exposure risks, and the right choice depends on which set of risks your team is equipped to manage and which mitigations your team can sustain.

Risk	Likelihood	Impact	Mitigation Feasibility	Net Exposure	Justification
Integration coherence degrades over time	High	High	Low	High	Independent release cycles; no cross-library consistency maintainer
Convention drift across libraries	High	Medium	Medium	Medium	3-5 different API philosophies; no unified AI context file
Source-distributed code in your org's analysis	Medium	Medium	Medium	Medium	Counts against 6 MB limit; appears in PMD scans and coverage reports
Upgrade coordination burden	Medium	High	Medium	Medium	5+ independent release cycles; no single changelog
No single record of what ran across systems	High	Medium	Low	High	Tracing one user action across the separate libraries means writing the tracking code yourself
Documentation fragmentation	High	Low	Medium	Medium	No unified onboarding; must be written in-house
Abandoned library risk	Medium	High	Medium	Medium	Team inherits maintenance of unfamiliar source if maintainer stops

Both approaches carry real risks. The right choice depends on which risks the team is equipped to manage.

Bus Factor Reframe — Institutional Knowledge Survival via Documentation Depth

"Bus factor" is the question every governance reviewer eventually asks: what happens if the one person who understands this disappears? This section answers it for KernDX honestly.

KernDX is single-maintainer at the snapshot date. This is acknowledged across several sections of this guide (Technical Risks, Organisational Risks, Enterprise Risk Dimensions), and it is not unusual for this kind of framework: most comparable Apex frameworks are also single-maintainer. Only the fflib family carries distributed maintainership by the metrics enterprise procurement teams typically use.

So the thing that actually matters is not how many maintainers a framework has. It is whether the maintainer's mental model is written down. A bus-factor event is survivable to the degree that the knowledge in someone's head has been moved into source-controlled documentation that a successor team can pick up cold.

KernDX documentation inventory (verifiable against this repo):

Doc	Purpose	Size
AGENTS.md	Tool-neutral entry point for AI coding assistants; points to the canonical conventions doc	197 lines
docs/Code Conventions - Guide.md	Canonical Apex/LWC/JS conventions: naming, sharing modifiers, testing patterns, framework idioms	690 lines
README.md	Project entry point: installation, getting started, references	103 lines
Strategic Guides	Architectural decisions, adoption decisions, persona-tailored summaries, operations, risks, metrics, glossary	9 documents
docs/Security - Guide.md	Threat model, posture, mitigations, bypass governance	2,326 lines
Apex reference	Per-class API documentation auto-generated from ApexDoc on every release build	270 pages
Total Markdown documentation in docs/	All .md files under the docs tree	323 files

You can verify this inventory yourself by running find docs/ -name "*.md" -type f | wc -l and wc -l AGENTS.md "docs/Code Conventions - Guide.md" README.md "docs/Security - Guide.md" at the snapshot tag.

What this means for a bus-factor event: A successor team encountering KernDX cold can read AGENTS.md + docs/Code Conventions - Guide.md + the relevant Strategic Guide + the Apex reference for the affected module and ship convention-compliant changes without prior KernDX experience. The mental model is in the repository, not in the maintainer's head.

The honest framing here is that bus-factor risk is structurally similar across most Apex frameworks today. KernDX accepts that, and competes only on the one thing that matters operationally: whether the codebase is documented well enough to be inherited. This guide makes no claim about the depth of any specific alternative framework's documentation; if you are comparing bus-factor exposure across frameworks, audit each candidate's repository documentation inventory directly.

Community Support: Signal vs Substance

A popular open-source project can look like a safety net, but "active community" and "someone will fix my production incident" are not the same thing. Most Salesforce open-source frameworks do not provide support backed by a service-level agreement (SLA), are maintained by small contributor groups, and do not guarantee production assistance. The table below separates what a community genuinely gives you from what it does not, so you do not mistake one for the other when scoring risk:

Dimension	What Community Provides	What It Does Not Provide
Bug fixing	Shared issue visibility, community PRs	Contractual resolution timeline
Knowledge	Public examples, Q&A, blog posts	Production firefighting
Longevity	Fork potential, shared ownership	Formal roadmap control
Hiring	Public maintainer-authored repos may surface in candidate portfolios, technical blogs, conference talks, and Trailhead modules	Deep expertise guarantee, or measurable hiring-pool depth for any specific framework

• Public-maintainer-authored frameworks may give you shared issue visibility and community pull requests, but they do not guarantee shared maintenance. As covered in the Bus Factor Reframe, most comparable Apex frameworks are single-maintainer regardless of whether the source is publicly hosted.
• Open-source visibility does not remove your operational responsibility. Production firefighting still falls on you as the adopter, the same way it does for KernDX.
• Whatever framework you choose, your org has to own its operation.

This applies equally to all frameworks: open-source visibility and your own internal operational readiness are complementary, not interchangeable.

Governance Model

Who decides what goes into the framework, how you get help, and what keeps it alive if the maintainer steps away. This is what a procurement or governance team needs on record.

Aspect	Current State
Roadmap ownership	Primary developer with delivery engagement oversight
Contribution policy	Internal: no external contributions accepted at this time
Support model	Engagement team during active projects; documentation + AI context for self-service post-handover
Escalation path	Delivery engagement lead then framework developer
Long-term sustainability	Source publicly available under BSL 1.1 (relicenses to Apache 2.0 after the four-year change date) ensures independence from any single maintainer; standard Apex patterns ensure any senior developer can maintain

Versioning & API Stability

Whether an upgrade can break your code, and what KernDX promises to keep stable. The short answer: the global members are the stable surface you build on, and breaking changes only land in a major version.

Aspect	Policy
Versioning strategy	Semantic versioning (major.minor.patch) from 1.0 onwards
Backward compatibility	global API stability prioritised after 1.0; breaking changes require major version bump
Current status	Packaged with 128 published managed-package versions declared in sfdx-project.json
Upgrade guarantees	Backward-compatible minor releases; breaking changes in major versions only
API stability	global members are the stable API surface; public members are internal and may change
Source delivery method	Public source repository under BSL 1.1; consulting engagements additionally include direct source delivery and handover support

Adoption Gate Criteria

Any framework, whether integrated like KernDX or assembled from separate libraries, should meet these governance gates before enterprise adoption. Do not proceed unless every gate is PASS or CONDITIONAL, with explicit risk acceptance recorded for any FAIL gate. The table shows where KernDX stands today, including the gates it fails.

Gate	Requirement	KernDX Status	Pass/Fail
G-1	Semantic versioning documented	Committed from v1.0	PASS
G-2	Backward compatibility guarantee	global API stability post-1.0	PASS
G-3	Deprecation lifecycle formalised	Planned, not formalised	FAIL
G-4	Defined release cadence	Engagement-aligned, not fixed	FAIL
G-5	Named secondary maintainer	Single primary; succession via source ownership	CONDITIONAL
G-6	Contribution guidelines published	CONTRIBUTING.md published in the source repository	PASS
G-7	CI transparency	.github/workflows/ci.yml and Actions run history publicly visible on the source repository	PASS

Assessment: KernDX passes 4 of 7 gates, with 1 conditional and 2 failures. If you adopt KernDX, document explicit risk acceptance for gates G-3 and G-4 and establish contractual mitigations (source ownership, a defined handover process, succession planning). The conditional G-5 gate ("succession via source ownership") is materially stronger in practice than the conditional label alone suggests: the succession-exit path can be run by an AI agent against the framework's public AI-context bundle, taking ~1-2 days of wall-clock time for a deeply adopted transition. In other words, "succession via source ownership" is a concrete sprint-scale activity, not a multi-week project, for teams equipped with modern agentic tooling.

For comparison, the same gates applied to modular frameworks:

Gate	taf	apex-fluently-soql	nebula-logger	fflib
G-1 Semantic versioning	PASS	PASS	PASS	FAIL (low recent release cadence)
G-2 Backward compatibility	PASS	PASS	PASS	CONDITIONAL
G-3 Deprecation lifecycle	CONDITIONAL	CONDITIONAL	CONDITIONAL	FAIL
G-4 Release cadence	PASS	PASS	PASS	FAIL
G-5 Secondary maintainer	CONDITIONAL	CONDITIONAL†	PASS (25+ contributors)	PASS (30+ contributors)
G-6 Contribution guidelines	PASS	PASS	PASS	PASS
G-7 CI transparency	PASS	PASS	PASS	PASS

† The 8 Apex Fluently libraries share a single primary author, so a full Apex Fluently stack is effectively a single-maintainer dependency (or two if paired with a separately-maintained logger such as nebula-logger), so an architecture board evaluating the modular stack as a whole should treat its overall G-5 gate result as CONDITIONAL even though each individual library lists its own G-5 status.

Hard Questions Architecture Review Boards Will Ask

These are the questions a review board reliably asks about any framework, with KernDX's straight answer to each and a link to where the detail lives. Take them into the room.

The eight questions, with KernDX's answer to each

#	Question	Answer
1	What happens if the primary developer is unavailable?	Source is publicly available under BSL 1.1 on the project repository, so any team can clone, fork, and self-maintain regardless of vendor status, with consulting engagements including direct source delivery and handover support. AI-context files document framework conventions and patterns: AGENTS.md (tool-neutral pointer) + docs/Code Conventions - Guide.md (canonical conventions) at repo root carry instruction-level guidance, and the per-module AI Agent Instructions doc provides a deep framework reference. Developers using AI coding tools can generate convention-compliant code and diagnose framework internals without prior KernDX experience (this narrows but does not eliminate the tribal-knowledge gap). For critical bugs, metadata-driven bypass mechanisms (TRG_Base.bypassAction(), FeatureFlag__mdt) isolate faulty handlers without code changes; the shipped repackaging-under-client-namespace tooling supports deeper fixes by forking the source under your own namespace. See Bus Factor Mitigation.
2	Can we mix modular components with KernDX later?	Yes. KernDX coexists with taf, apex-fluently-soql, and nebula-logger. See Coexistence Playbook.
3	What is the rollback strategy?	Three exit paths: continue managed package, deploy as source, or repackage under client namespace. Estimated ~1-2 days agent-executed against the framework's AI-context bundle, or 1-2 weeks conventional human-only execution, for deeply adopted orgs. See Exit and Reversibility Analysis.
4	How do we validate production-scale performance?	Pre-compiled managed package; benchmark hot paths in sandbox. Per-trigger overhead has not been measured against a direct-Apex control arm, so KernDX publishes no overhead figure: measure your own hot paths before committing to one. See Performance & Governor Limits.
5	How does this affect hiring flexibility?	KernDX uses standard Apex patterns (selectors, triggers, DTOs). The ramp gap for an incoming developer is per-module API familiarity, not a language or paradigm shift, so any senior Apex developer can ship convention-compliant code after working through the relevant Fast Start. This guide does not measure per-framework hiring-market depth for KernDX or for any alternative, so a claim that one specific framework is "easier to hire for" is not load-bearing without your own historical data. Per-module onboarding times are comparable across comparable Apex frameworks (see Onboarding Time Comparison).
6	What governance gates must KernDX pass before adoption?	7 gates defined. KernDX currently passes 4 of 7, with 1 conditional and 2 failures. Document explicit risk acceptance for any FAIL gate before you adopt. See Adoption Gate Criteria.
7	What if KernDX is abandoned?	Source ownership means clients can fork and maintain. Standard patterns mean the codebase is readable without framework expertise. Exit playbook in Migration Checklists.
8	How does KernDX map to a recognised security benchmark?	KernDX maps itself control-by-control against the Security Benchmark for Salesforce (54 controls across 12 domains): it provides a working mechanism or audit-ready evidence for 15 controls (peer review and static analysis, source-driven builds and secret scanning, masking detection and regulated-field inventory, plus the governance-evidence and access-review feeds), and is explicit that the other 39 are org configuration and process it does not own.

Strategic Recommendations

These are the risk-mitigation steps to take at each stage of adoption: before, during, and after. They matter most when your delivery runs on partner (SI) teams whose engineers rotate at every release. In that setting these steps double as operational controls that keep production safe through the build pipeline rather than through any one engineer remembering to be careful. The 100% per-file Apex coverage gate, the default-on data-access governance, and the audit-trailed bypasses act like a technical lead built into source-visible defaults, rather than living in a single engineer's memory.

Pre-Adoption:

1. Run a time-boxed pilot (2-4 weeks) on a single non-critical object
2. Assess exit cost: review Migration Checklists for migration effort
3. Verify team readiness: at least one developer has reviewed the Fast Start guides
4. Compare in sandbox: build the same feature with KernDX and a modular stack, then measure time, coverage, and satisfaction

During Adoption:

1. Start with triggers and selectors: highest value, lowest risk
2. Add web services and resilience when integration requirements arise
3. Document all custom metadata configuration
4. Maintain exit readiness

Post-Adoption:

1. Assign a platform engineering owner for upgrades, log monitoring, and incident response
2. Review quarterly: measure success metrics (see Success Metrics)
3. Maintain AI context files: update docs/Code Conventions - Guide.md when conventions evolve
4. Ensure at least two team members can troubleshoot independently

---