Domain expertise

Completes bounded work with clear goals and guidance, understands the user and intended outcome, verifies the output, and communicates promptly.

• Applies foundational role knowledge to common tasks and asks for help when uncertain.Evidence to inspect: Work passes basic checks and key concepts can be explained.
  Computer-science foundationsFoundational in this standardCoding and abstractionFoundational in this standard
• Follows team quality, security, and privacy practices and checks edge cases before submission.Evidence to inspect: Can identify obvious failure paths or sensitive-data risks.
  Quality, security, and safetyFoundational in this standardBoundariesFoundational in this standard
• When AI use is permitted, provides useful context, judges whether the output fits the task, and explains when it should not be used.Applies when: Depends on role policy, task risk, and available tools; sound decisions not to use AI count as valid evidence.Evidence to inspect: Changes include verification; generated content is not assumed correct.
  AI engineeringFoundational in this standardDebuggingFoundational in this standard
• Explains business objects, states, and data meaning in the task and checks normal and exceptional paths.Evidence to inspect: Examples explain state transitions and data constraints.
  Data modelFoundational in this standard
• Uses reproduction, logs, and small experiments to diagnose routine problems and brings evidence when seeking help.Evidence to inspect: Provides reproduction steps, eliminated hypotheses, and verification records.
  DebuggingFoundational in this standard

Owns a feature or component end to end, delivers reliably, follows operational feedback, and supports peers when relevant to the role.

• Designs a maintainable component solution and identifies interfaces, state, and major failure modes.Evidence to inspect: Design supports requirements and explains capacity, migration, or rollback.
  System designFoundational in this standardData modelFoundational in this standard
• Adds tests, observability, or security checks to important paths to reduce foreseeable failures.Evidence to inspect: Tests or runtime signals demonstrate that key constraints are protected.
  Quality, security, and safetyFoundational in this standardReliability and incidentsFoundational in this standard
• When AI is used, validates generated or suggested work according to impact and risk; escalates or rejects what cannot be explained or verified.Applies when: Assess only when AI is actually used or the role is expected to evaluate AI output.Evidence to inspect: Evidence includes tests, comparison cases, reference checks, or human approval.
  AI evaluation and governanceFoundational in this standardDebuggingFoundational in this standard
• Maps business rules into component data, states, and interfaces and plans compatibility and migration.Evidence to inspect: The model explains exceptions, historical data, and migration checks.
  Model evolutionDifferentiating here
• Tracks a component after release, rolls back or diagnoses failures, and verifies repairs.Evidence to inspect: Release monitoring, rollback conditions, and verified repairs form a closed loop.
  Reliability and incidentsDifferentiating here

Clarifies ambiguous problems, weighs cross-component options, and drives project outcomes while making authority and decision boundaries explicit when proposing plans or pivots.

• Designs across component boundaries, balancing domain rules, system constraints, evolution cost, and reversibility.Evidence to inspect: Proposal covers boundaries, trade-offs, migration/rollback, and failure paths.
  System designDifferentiating hereModel evolutionDifferentiating here
• Validates the problem with users and product partners before choosing an implementation.Evidence to inspect: Research, prototypes, experiments, or data narrow or invalidate an approach.
  Product discovery and experience designDifferentiating hereProduct judgmentDifferentiating here
• Defines quality and security checks for high-impact solutions; where AI is involved, selects evaluation, human review, or non-use according to risk rather than treating adoption as a goal.Applies when: The AI portion applies only when the solution or its risks involve AI; assess ordinary quality and security against the actual work.Evidence to inspect: Shows evaluation cases, monitoring/escalation conditions, privacy/access controls, or human handoff.
  Quality, security, and safetyDifferentiating hereAI evaluation and governanceDifferentiating here
• Sets a technical roadmap for the owned domain, balancing architecture, technical debt, and staged migration; includes AI investment only when relevant opportunities, risks, and validation conditions are clear.Applies when: AI investment applies only when the domain has a relevant opportunity or risk; a decision not to adopt based on value, total cost, and risk is valid.Evidence to inspect: The roadmap includes dependencies, cost, risk, checkpoints, and exit options.
  Engineering systemsDifferentiating here
• Evolves cross-component domain and data models while preserving definitions, compatibility, and historical meaning.Evidence to inspect: Data meaning and migration correctness remain traceable after business-rule changes.
  Model evolutionDifferentiating here

Creates sustained professional value in a critical domain or across teams, scaling impact through reusable practices and collaboration without assuming company-wide governance or formal succession duties.

• Sets evolvable domain architecture and professional standards while balancing product experience and engineering boundaries.Evidence to inspect: Multiple teams adopt the approach and track quality, cost, and evolution outcomes.
  System designDifferentiating hereModel evolutionDifferentiating hereProduct discovery and experience designRelevant when context applies
• Builds quality evaluation proportionate to product risk; for AI systems, includes representative evaluations and regression monitoring.Applies when: AI evaluation applies only to AI systems or risks within the actual responsibility.Evidence to inspect: Reusable baselines, production monitoring, and clear human-intervention/rollback conditions exist.
  AI evaluation and governanceDifferentiating hereQuality, security, and safetyDifferentiating here
• Identifies cross-team complexity or technical debt and makes the overall system simpler and more reliable.Evidence to inspect: Consumers repeat less work and incidents, change cost, or complexity decline.
  Engineering systemsDifferentiating hereQuality, security, and safetyDifferentiating here
• Coordinates cross-team technical roadmaps, sequencing architecture, data, platform, and relevant AI work with compatibility boundaries.Applies when: Include AI work when relevant to the opportunity or risk; when it is not relevant, explain the technical or product basis.Evidence to inspect: The roadmap explains cross-team dependencies, migration sequence, and acceptance standards.
  System designDifferentiating here
• Builds shared business semantics and data contracts across teams to prevent inconsistent local models.Evidence to inspect: Key metrics, entities, and rules have owners and change mechanisms.
  Data modelDifferentiating here

Owns first-line management responsibilities for team outcomes, people development, collaboration, and operating mechanisms; understands the business and domain boundaries and uses professional judgment to review and delegate.

• Understands the team’s business flow, key domain rules, and data definitions; reviews product, technical, and quality risks, engaging AI experts when relevant, without being measured by personal coding depth.Applies when: Assess AI risk only when the team’s products, tools, or workflows involve AI.Evidence to inspect: Asks the right questions, involves appropriate experts, and owns the decision.
  System designRelevant when context appliesAI evaluation and governanceDifferentiating hereQuality, security, and safetyDifferentiating here
• Builds testing, release, and incident-response practices proportionate to business risk; adds AI verification and human oversight when AI is used.Applies when: Does not require AI adoption; when applicable, assess verification, fallback, and accountability.Evidence to inspect: Quality and recovery are measurable without excessive manager approval.
  Engineering systemsDifferentiating hereReliability and incidentsDifferentiating here
• Enables product, design, and engineering to discover problems and validate outcomes end to end.Evidence to inspect: The team tracks adoption and outcomes, not just on-time releases.
  Product discovery and experience designDifferentiating hereBusiness outcomes and validationDifferentiating here
• Builds technical roadmaps with technical leads, allocating capacity, cost comparison, and risk validation for technical debt, architecture, and relevant AI options.Applies when: Include AI options based on business fit, total cost, quality, and risk.Evidence to inspect: Technical plans align with business cadence and have owners and staged validation.
  Engineering systemsDifferentiating here

Within actual authority, leads managers to deliver across teams and is accountable for resource direction and organizational capability; strategy, budget, and reorganization authority depend on the role mandate.

• Ensures clear ownership and controls for critical technical, product, privacy, and security risks, adding proportionate evaluation and oversight when AI is involved.Applies when: The AI governance portion applies only where the organization actually uses or provides AI.Evidence to inspect: Critical risks have decision owners, monitoring, review, and response mechanisms.
  AI evaluation and governanceDifferentiating hereQuality, security, and safetyDifferentiating here
• Sets cross-team quality and operational standards proportionate to business risk.Evidence to inspect: Standards reduce incidents or regressions without unnecessary process burden.
  Engineering systemsDifferentiating hereReliability and incidentsDifferentiating here
• Engages experts on long-term domain and technical choices and understands business, user, and organizational consequences.Evidence to inspect: Can compare paths and reversibility without substituting for specialists on details.
  System designRelevant when context appliesModel evolutionRelevant when context appliesProduct judgmentDifferentiating here
• Governs cross-domain technical roadmaps, connecting platform, architecture, and data investment to business direction, and evaluates AI investment and alternatives where relevant.Applies when: AI project count or adoption is not a goal; explain the basis for adopting, declining, or deferring it.Evidence to inspect: The portfolio has expert review, dependency sequencing, and long-term maintenance ownership.
  Engineering systemsDifferentiating here