About the proposed examination

The proposed credential assesses integrated recommendations under competing technical, commercial and governance constraints. It does not attest engineering ability, security-auditor status, achievement in a specific job or external accreditation.

Domain weights

Percentages describe the proposed allocation of scored questions by primary domain. Example concepts illustrate scope; examination questions may use different products, facts and fictional organisations. This document contains no answer keys, cases or confidential questions.

Assessable objectives

D1.0 Solution architecture, integration and operating boundaries (14.3%)

D1.1 Given a scenario, frame a scoped technical-commercial pilot from the required outcome and unknown interface capabilities.

Example concepts: included workflows, unproven write path.

D1.2 Given a scenario, trace the producer, consumer, integrator and business approver through a proposed flow.

Example concepts: ownership, accepted records, outcome.

D1.3 Given a scenario, choose an integration pattern that meets timing, replay and duplicate constraints.

Example concepts: batch, webhook, retries, limits.

D1.4 Given a scenario, interpret reliability test measures without hiding retries or failed records.

Example concepts: first-attempt, final state, backlog.

D1.5 Given a scenario, resolve identifier, status, timestamp and version semantics in a two-party data contract.

Example concepts: safe rejection, mapping ownership.

D1.6 Given a scenario, trace technical and approval boundaries across a candidate workflow.

Example concepts: read, draft, human approval, post.

D2.0 Cloud and solution economics (12.5%)

D2.1 Given a scenario, identify the cost meter, period, usage owner and forecast exposure behind a quote.

Example concepts: per-call, capacity, fixed charge.

D2.2 Given a scenario, interpret entitlements, rights and commitment terms under changing demand.

Example concepts: licence scope, minimum, renewal.

D2.3 Given a scenario, reconcile a usage record to a defined billing line and find a mismatch.

Example concepts: meter, exclusions, invoice.

D2.4 Given a scenario, calculate stepped or tiered charges and the cost of unused commitment.

Example concepts: tiers, rounding, carryover.

D2.5 Given a scenario, compare scenarios without treating demand assumptions as confirmed savings.

Example concepts: low/base/high, period.

D2.6 Given a scenario, calculate commercial economics without merging subscription and partner-service revenue.

Example concepts: discount, referral fee, tax.

D2.7 Given a scenario, calculate released operational capacity while separating model from realised return.

Example concepts: workload, review, exclusions.

D2.8 Given a scenario, calculate the full effort model and bound the resulting commercial claim.

Example concepts: capacity, implementation, payroll.

D3.0 Security, assurance and operational trust (12.5%)

D3.1 Given a scenario, identify supported least-privilege and diagnostic controls, and what remains unproven.

Example concepts: service identity, queue age, logs.

D3.2 Given a scenario, translate a scoped security questionnaire into claim-specific evidence requests.

Example concepts: control, tier, population, period.

D3.3 Given a scenario, assign control operation, disclosure and customer-exception decisions to their authorised owners.

Example concepts: RACI, assurance hand-off.

D3.4 Given a scenario, interpret an assurance report within its period, tested services and exceptions.

Example concepts: scope, sampling, coverage.

D3.5 Given a scenario, sequence remediation, retest, customer acceptance and approved messaging.

Example concepts: dependency, retest record.

D3.6 Given a scenario, calculate incident reporting time using the specified clock trigger and authorisation.

Example concepts: detection, confirmation, notice.

D3.7 Given a scenario, respond to an assurance objection without extending supplier evidence to a customer tenant.

Example concepts: report scope, tests, terms.

D3.8 Given a scenario, reconcile supplier assurance with tenant controls and executed customer terms.

Example concepts: certificate scope, data, evidence.

D4.0 AI value, quality and safe-use decisions (14.3%)

D4.1 Given a scenario, frame an AI-supported workflow by decision consequence, source and permitted action.

Example concepts: risk boundary, exclusions, gates.

D4.2 Given a scenario, evaluate a measured model result for the intended population and operating threshold.

Example concepts: sample, denominator, error.

D4.3 Given a scenario, define allowed data, processing purpose, retention and deletion evidence.

Example concepts: input/output, logs, rights.

D4.4 Given a scenario, interpret intervention metrics and choose the owner-led response to drift.

Example concepts: baseline, window, trigger.

D4.5 Given a scenario, distinguish model intent, tool execution and reviewer authority in an AI control event.

Example concepts: untrusted source, gateway, action.

D5.0 Technical-commercial translation and defensible recommendations (12.5%)

D5.1 Given a scenario, deliver a bounded architecture recommendation with explicit exit criteria.

Example concepts: operating boundary, owner, acceptance.

D5.2 Given a scenario, compare options under complete first-year costs and nonfinancial gates.

Example concepts: migration, service, risk.

D5.3 Given a scenario, give a conditional purchasing decision with named triggers and accountable owners.

Example concepts: assumptions, variance, escalation.

D5.4 Given a scenario, assemble a conditional offer from cost, capability and customer acceptance evidence.

Example concepts: offer, dependency, wording.

D5.5 Given a scenario, deliver a governed customer/partner handover with review and exit conditions.

Example concepts: authority, trigger, expiry.

D5.6 Given a scenario, sequence reversible pilot gates and the earliest evidence-backed next action.

Example concepts: dependency, rollback, approval.

D5.7 Given a scenario, deliver an integrated recommendation distinguishing observed, modeled and unknown outcomes.

Example concepts: scope, owners, expiry, stop.

D6.0 Discovery, stakeholders and decision sequencing (12.5%)

D6.1 Given a scenario, calculate and order dependent testing, security and acceptance activities.

Example concepts: critical path, independent gates.

D6.2 Given a scenario, prepare a conditional deployment handover with monitoring and reversal gates.

Example concepts: approved scope, owner, stop.

D6.3 Given a scenario, calculate eligible weighted pipeline without counting booked or unqualified opportunities.

Example concepts: customer next step, owner, weight.

D6.4 Given a scenario, frame a customer decision with technical, financial and governance constraints.

Example concepts: permitted workflow, approval.

D6.5 Given a scenario, target discovery questions to the owner and the gate each answer changes.

Example concepts: purpose, tenant controls, baseline.

D6.6 Given a scenario, calculate the dependency path for reversible expansion and acceptance.

Example concepts: parallel work, rehearsal, gate.

D6.7 Given a scenario, frame a multi-party, multi-domain decision into a bounded customer recommendation.

Example concepts: outcome, gate, stakeholder.

D7.0 Partner, channel and contracting boundaries (10.7%)

D7.1 Given a scenario, define a partner motion while preserving the customer and supplier boundaries.

Example concepts: referral, resale, services.

D7.2 Given a scenario, apply deal-registration and conflict evidence before allocating attribution.

Example concepts: timestamps, customer choice.

D7.3 Given a scenario, distinguish sourced, influenced and disputed co-sell evidence.

Example concepts: attribution, permission, status.

D7.4 Given a scenario, apply capability and performance evidence to reversible enhanced-term gates.

Example concepts: certification, exercise, support.

D7.5 Given a scenario, protect customer continuity, renewal ownership and exit responsibilities.

Example concepts: handover, terms, transition.

D7.6 Given a scenario, prepare a governed channel handover with economics, owners, gaps and expiry.

Example concepts: scope, review, dispute.

D7.7 Given a scenario, resolve vendor, partner and customer authority in a proposed transaction.

Example concepts: customer choice, price, support.

D8.0 Evidence governance, approvals and responsible claims (10.7%)

D8.1 Given a scenario, link budget, admission and approval controls to cost and service continuity.

Example concepts: threshold, owner, pause.

D8.2 Given a scenario, evaluate retention and subprocessor evidence across the actual data lifecycle.

Example concepts: model input, output, logs.

D8.3 Given a scenario, distinguish AI assurance evidence from claims it does not establish.

Example concepts: tenant, prompt, tool boundary.

D8.4 Given a scenario, assemble a conditional response across evidence, missing controls and owner actions.

Example concepts: status, source, approval.

D8.5 Given a scenario, assign business, data, model and execution approval decisions to the correct owners.

Example concepts: governance authority, segregation.

D8.6 Given a scenario, sequence the review, version binding and release checks for a consequential action.

Example concepts: human approval, gateway, record.

D8.7 Given a scenario, decide which provider or model changes require retest before deployment.

Example concepts: version, regression, rollback.

D8.8 Given a scenario, classify observed, modeled and unestablished outcomes within one commercial claim.

Example concepts: sample, model, guarantee.

Important candidate notes

• A programme learning-completion record is not the assessed credential. Completion of ASTRA Ready lessons is not required for assessment-only entry where eligibility conditions are met.

• Practice assessments, module exercises, formative simulations and planned mocks are disclosed learning activities; their results do not award a credential or predict a pass.

• The final blueprint, examination time, availability and pass standard require pilot evidence, ASTRA Ready review, founder approval, examination-engine tests and confirmation of the issuing legal entity.

• Assessment examples are fictional and judge decisions within supplied contracts and artefacts; they do not substitute for laws, vendor attestations or live system validation.