{"@context":{"ixo":"https://w3id.org/ixo/ns/protocol/","@id":"@type","type":"@type","@protected":true},"type":"ixo:entity#surveyTemplate","question":{"title":"IXO Solutions Engineer — Gate 1","description":"Theoretical Knowledge Exam · Reworked, higher-discrimination form\nEstimated time 45 minutes · Passing bar 70% (12/16)","pages":[{"name":"sectionA","elements":[{"type":"radiogroup","name":"ixo:examResponse_q01","title":"Q1. Backing up a wallet recovery phrase","description":"Scenario. A Solutioneer in Lusaka sets up their IXO mobile wallet and screenshots the 12-word recovery phrase, saving it to their phone's cloud-synced photo roll so they cannot lose it. A colleague reassures them it is fine because the wallet is PIN-locked, so 'the phrase is just a backup that no one can reach.' Which statement correctly characterises the security posture and the required action?","choices":[{"value":"A","text":"It is fine as described: the wallet PIN protects the account, so the screenshotted phrase adds no risk and needs no action."},{"value":"B","text":"The recovery phrase is compromised the moment it lands in cloud-synced storage, regardless of the wallet PIN. Create a fresh wallet offline, write the new phrase on paper, register a new DID, and re-issue any authz grants that pointed at the old account before decommissioning it."},{"value":"C","text":"Only the wallet PIN needs changing; a new PIN re-derives the underlying keys, so the existing phrase and DID can be kept."},{"value":"D","text":"No new wallet is needed; deleting the screenshot from the photo roll removes the exposure and restores the account's security."}]},{"type":"radiogroup","name":"ixo:examResponse_q02","title":"Q2. Placing four data items across the tiers","description":"Scenario. A youth-employment registry must satisfy a funder audit while protecting SSI. You have four data items: (i) the youth's national ID number, (ii) the SHA-256 hash of that ID, (iii) the claim's current on-chain status, and (iv) the encrypted evaluation notes shared between two named evaluators. Which placement is correct across all four?","choices":[{"value":"A","text":"(i) Private store; (ii) Public reference; (iii) Public reference; (iv) Shared (Matrix room, restricted access)."},{"value":"B","text":"(i) Public reference; (ii) Private store; (iii) Public reference; (iv) Shared."},{"value":"C","text":"(i) Shared; (ii) Public reference; (iii) Shared; (iv) Private store."},{"value":"D","text":"(i) Private store; (ii) Private store; (iii) Public reference; (iv) Public reference."}]},{"type":"radiogroup","name":"ixo:examResponse_q03","title":"Q3. Mapping an assertion through to its receipt","description":"Scenario. A candidate asserts on their CV that they finished an advanced plumbing course. An authority evaluates the assertion against a rubric and issues a signed statement of the achievement; separately, the evaluation run produces a signed record of exactly which checks passed and the facts they were run against. Map the three artefacts.","choices":[{"value":"A","text":"CV assertion = unverified Claim; signed achievement = Verifiable Credential; signed evaluation record = the evaluation receipt (UDID)."},{"value":"B","text":"CV assertion = Verifiable Credential; signed achievement = Claim; signed evaluation record = block-explorer entry."},{"value":"C","text":"CV assertion = Claim; signed achievement = evaluation receipt; signed evaluation record = Verifiable Credential."},{"value":"D","text":"CV assertion = Claim Collection; signed achievement = Deed Request; signed evaluation record = Verifiable Credential."}]},{"type":"radiogroup","name":"ixo:examResponse_q04","title":"Q4. Relying on a presented credential","description":"Scenario. A youth applies for a cash disbursement that requires proof of identity. They present an Impact VC: your tool resolves the issuer's DID, confirms a recognised programme, validates the signature and integrity, and returns active status within the freshness window. The credential asserts a project contribution and carries a national ID number recorded by the issuer as self-attested. You must decide what this successful verification does and does not let you rely on. Which reading is correct?","choices":[{"value":"A","text":"The verification result covers the whole credential uniformly, so the contribution and the national ID stand on the same footing; you may rely on the ID as proof of identity exactly as you rely on the validated signature and active status."},{"value":"B","text":"Because the ID field is self-attested, the whole credential drops to self-attested assurance, so you cannot rely on the contribution claim either until an authoritative source re-issues the entire VC with the ID checked."},{"value":"C","text":"The container checks — issuer, signature, integrity, status, freshness — do not establish how each claim was evidenced; the contribution rests on issuer assurance, while the self-attested ID cannot serve as proof of identity without an authoritative-source-verified credential."},{"value":"D","text":"Since the credential passed status and freshness checks its assurance is sufficient as proof of identity; record the national ID from the credential and re-request the VC on a shorter freshness cycle to keep that assurance current."}]},{"type":"radiogroup","name":"ixo:examResponse_q05","title":"Q5. Naming the artefacts in a claim architecture","description":"Scenario. A waterpoint programme has published a reusable Blueprint that defines the required fields, evidence schema, evaluation rubric, and payout rule for a 'log a waterpoint delivery' task. From that Blueprint the programme creates a specific executable instance — a work-package assigned to a named youth for the pump at Site 14; the youth then pumps water, captures a GPS-tagged photo, a manager confirms delivery, and payment fires, all logged as an execution record. Four artefacts are proposed as 'the Deed'. Which one is the Deed?","choices":[{"value":"A","text":"The published reusable Blueprint that defines the fields, evidence schema, rubric, and payout rule."},{"value":"B","text":"The specific executable instance created from the Blueprint and assigned to the named youth for Site 14."},{"value":"C","text":"The GPS-tagged photograph, since it is the evidence that anchors the claim."},{"value":"D","text":"The execution record of this delivery — the timestamps, evaluation outcome, and payout event."}]},{"type":"radiogroup","name":"ixo:examResponse_q06","title":"Q6. Registering a pump as a digital twin","description":"Scenario. You are registering a community water pump as a CDT. You must (a) stream live telemetry from its IoT controller, (b) link an off-chain maintenance-history data room, and (c) establish verifiable ownership. A junior proposes storing the telemetry URL and the maintenance PDF as free-text notes in the entity description. What is the correct schema wiring, and why is the proposal wrong?","choices":[{"value":"A","text":"Put the telemetry URL and PDF in the description as proposed; free-text is sufficient because the DID already establishes ownership."},{"value":"B","text":"Telemetry integration goes in a Service Endpoint; the maintenance room goes in Linked Resources; ownership is anchored by the DID/controller. Free-text notes are not machine-resolvable and carry no integrity proof, so services and indexers cannot act on them."},{"value":"C","text":"Both telemetry and maintenance data belong in Linked Resources; Service Endpoints are only for payment rails."},{"value":"D","text":"Both belong in Service Endpoints; Linked Resources are only for images."}]},{"type":"radiogroup","name":"ixo:examResponse_q07","title":"Q7. Onboarding forty training centres","description":"Scenario. A youth-employment programme is onboarding forty training centres across three countries. Every centre must enforce the same enrolment rules, verification rubric, and credential schema, yet each is a distinct entity with its own operators, learners, and data. A colleague proposes registering all forty as one shared entity to guarantee identical rules. How should a Solutions Engineer model this network so the rules are shared but the centres stay independent?","choices":[{"value":"A","text":"Register all forty centres as a single shared entity so they are guaranteed to run identical rules from one record."},{"value":"B","text":"Define a Blueprint for 'training centre' once — carrying the shared enrolment rules, rubric, and credential schema in a Protocol POD — then create an executable instance of it for each of the forty centres, so every centre inherits the Blueprint's rules while keeping its own operators, learners, and data."},{"value":"C","text":"Register each of the forty centres as a fully bespoke entity with its own custom rules, then manually keep the forty rule-sets in sync by hand."},{"value":"D","text":"Model each centre as an Oracle so it can self-certify its own learners without a shared rule source."}]},{"type":"radiogroup","name":"ixo:examResponse_q08","title":"Q8. Listing pending claims on a dashboard","description":"Scenario. An ops dashboard must list all 'Pending' claims for a forestry project, filtered by claimant and updated in near-real-time, without hammering mobile data. A developer proposes four data paths. Which is correct?","choices":[{"value":"A","text":"Query the chain node's RPC directly for every block and filter client-side on the device."},{"value":"B","text":"Query the Blocksync indexer over GraphQL, selecting only the needed fields (claim id, claimant, status)."},{"value":"C","text":"Read the claim state out of the YoID wallet using JSON-LD framing."},{"value":"D","text":"Poll a raw SQL replica of the Yoma application database over the public internet."}]},{"type":"radiogroup","name":"ixo:examResponse_q09","title":"Q9. Auditing a fragmented coordination setup","description":"Scenario. A municipal water project coordinates over Google Sheets and WhatsApp. You run a Coordination State Audit and propose a target design. A colleague drafts four candidate designs. Only one both traces the correct set of coordination flows and places each flow at the right trust boundary. Which is it?","choices":[{"value":"A","text":"Trace Information and Capital only; move both fully on-chain for maximum transparency, including participant names."},{"value":"B","text":"Trace Information, Claims, Permissions, and Capital; keep coordination in encrypted Matrix rooms and commit only reference hashes on-chain."},{"value":"C","text":"Trace Information, Claims, and Capital; migrate coordination to a private cloud database and publish a weekly CSV to the explorer."},{"value":"D","text":"Trace Information, Claims, Permissions, and Capital; commit all four flows on-chain in full so the audit trail is complete."}]},{"type":"radiogroup","name":"ixo:examResponse_q10","title":"Q10. Two builds of an AI approval check","description":"Scenario. A vision model scores solar-panel wiring correctness. Two builds are proposed:\nBuild X: 'if model_confidence > 0.90 then auto-approve, else escalate,' with the threshold and the model version pinned in config.\nBuild Y: 'auto-approve when the model is confident,' with the model auto-updating to the latest weights nightly.\nA reviewer claims both are deterministic because both are rule-based. Where is the reviewer wrong?","choices":[{"value":"A","text":"Both are deterministic; the reviewer is correct, because any if/else rule guarantees identical outputs."},{"value":"B","text":"Only X is deterministic. Determinism requires a fixed typed threshold AND a pinned model version — Y's nightly weight updates mean identical inputs can yield different outputs over time, so the state transition is not reproducible."},{"value":"C","text":"Only Y is deterministic, because letting the model self-update removes the human bottleneck."},{"value":"D","text":"Neither is deterministic, because any use of an AI model anywhere in the pipeline makes the whole flow probabilistic."}]},{"type":"radiogroup","name":"ixo:examResponse_q11","title":"Q11. Designing a dMRV loop for carbon minting","description":"Scenario. In a SupaMoto clean-cooking deployment, a device emits messy telemetry (fuel weight, temperature traces). Carbon must not be mintable from unverified data. Four pipelines are proposed. Which one is a safe dMRV loop, and what specifically makes the others unsafe?","choices":[{"value":"A","text":"Write raw telemetry straight to the explorer and let a rubric read it from there; transparency substitutes for normalisation."},{"value":"B","text":"An AI step normalises telemetry into typed facts (cumulative runtime, fuel type) on a Fact Ledger; deterministic rubrics then run over those typed facts to transition claim state and gate minting."},{"value":"C","text":"An LLM reads the raw telemetry and decides directly whether to mint, with its natural-language verdict stored as the claim."},{"value":"D","text":"Mint provisionally on device signal, then have a human spot-check a sample afterwards and claw back if wrong."}]},{"type":"radiogroup","name":"ixo:examResponse_q12","title":"Q12. Configuring an automated payout agent","description":"Scenario. You are configuring an automated claim-evaluation agent that can, in principle, trigger payouts. You must prevent out-of-scope financial actions while keeping it useful. Four control designs are proposed. Which one actually bounds the agent?","choices":[{"value":"A","text":"Set the LLM temperature to 0 so its outputs become deterministic and therefore safe."},{"value":"B","text":"Define a Manifest Policy that declares the exact tools the agent may call, hard caps on payout amounts, and explicit escalation triggers that route out-of-bounds cases to a human."},{"value":"C","text":"Put standard password authentication on the agent's database connection."},{"value":"D","text":"Require a human to re-key every transaction into a wallet after the agent recommends it."}]},{"type":"radiogroup","name":"ixo:examResponse_q13","title":"Q13. A check returns below its confidence threshold","description":"Scenario. An AI-assisted step compares an uploaded certificate to registration records and returns 72% confidence on a blurry image; the configured auto-pass threshold is 90%. A second reviewer suggests just lowering the threshold to 70% 'so the flow does not stall.' What is the correct routing, and what is wrong with the suggestion?","choices":[{"value":"A","text":"Auto-pass at 72% because it is a majority; the threshold is advisory."},{"value":"B","text":"The escalation boundary fires: pause the automated transition and route to a human reviewer. Lowering the threshold to clear a stuck case defeats the purpose of the boundary and silently widens the auto-pass zone for all future claims."},{"value":"C","text":"Auto-reject and delete the claim, since it fell below threshold."},{"value":"D","text":"Re-run the AI until it reaches 100% confidence, then auto-pass."}]},{"type":"radiogroup","name":"ixo:examResponse_q14","title":"Q14. Editing a live workflow mid-visit","description":"Scenario. A community health programme runs a home-visit Qi Flow. Its Blueprint defines the task list [confirm consent] to [record vitals] to [flag follow-up] to [submit claim]. Mid-morning, a field supervisor decides all future visits should also capture a medication check, and opens the builder to add a [medication check] step to the Blueprint. Meanwhile a health worker, Thandi, is partway through an executable instance of a real visit — she has completed consent and vitals and is on flag follow-up. A teammate says 'the Flow is whatever Thandi is doing right now, so editing it will change her live visit.' What is actually true about the Blueprint versus the act of editing it?","choices":[{"value":"A","text":"The teammate is right: the Flow is Thandi's live instance, so the supervisor's new step immediately inserts itself into her in-progress task list."},{"value":"B","text":"Editing the Blueprint is a separate authoring act on the reusable definition; it produces an updated Blueprint that governs future executable instances. Thandi's live instance keeps running the Blueprint it was created from, and her completed steps stay in her own immutable record regardless of the edit."},{"value":"C","text":"The supervisor cannot edit the Blueprint at all while any instance is in progress, because Blueprints are locked whenever an instance is running."},{"value":"D","text":"Editing the Blueprint rewrites every instance including completed ones, so past visits retroactively gain a medication-check step."}]},{"type":"radiogroup","name":"ixo:examResponse_q15","title":"Q15. A team sharing one installation flow","description":"Scenario. On a large building site, a team of technicians works a single installation Qi Flow. Each technician owns a separate component — electrical, plumbing, HVAC, fire — and updates the state of their own tasks as they progress, while the supervisor watches overall progress in the same Flow. The supervisor must ensure that each technician can advance only their own tasks and cannot alter another technician's task state, without splitting the work into four separate Flows. How should this be configured?","choices":[{"value":"A","text":"Give every technician edit rights to the whole Flow and brief them, in the task descriptions, to only touch their own component — relying on the team to respect the boundary."},{"value":"B","text":"Apply block-level permissions that scope each technician's 'Act' authority to the specific task blocks for their component, so the system rejects any attempt to update another technician's tasks while all work stays in the one shared Flow."},{"value":"C","text":"Split the installation into four separate Flows, one per technician, so no one can see or touch another's tasks — accepting the loss of shared coordination and combined progress view."},{"value":"D","text":"Issue the whole team a single shared account with full Flow permissions, and reconstruct who changed what afterwards from the activity log."}]},{"type":"radiogroup","name":"ixo:examResponse_q16","title":"Q16. Testing another Solutioneer's setup with your account","description":"Scenario. Another Solutioneer asks you to help test their setup, so you use one of your own accounts. From it you submit a bid into their programme, are granted claim-submission authority on their claim collection, and submit several test claims. Separately, that same account is a controller (admin) on two of your own domains. A teammate worries that 'taking a submit grant in someone else's programme will change what your account can do on your own domains.' Demonstrate your understanding of the permission model: which statement is correct?","choices":[{"value":"A","text":"Correct worry — receiving claim-submission authority in their programme reduces your account to a submitter role, so it loses its controller rights on your own domains until the grant is revoked."},{"value":"B","text":"Correct worry — the grant redefines your account's role globally, so on your own domains it can now only submit claims and can no longer perform controller actions like updating domain configuration."},{"value":"C","text":"Unfounded — permissions are additive and scoped to where they are granted. The submit authority applies only to their claim collection; your controller rights on your own domains are held independently and are entirely unchanged. Your account simply now holds both, each valid only in its own domain."},{"value":"D","text":"Unfounded, but only because the two domains are yours — if the account held controller rights on a domain owned by a third party, the external submit grant would override those controller rights."}]}],"title":"SECTION A — QUESTIONS"}],"questionErrorLocation":"bottom","showProgressBar":true,"progressBarType":"questions","pagePrevText":"Back","pageNextText":"Next","completeText":"Submit"}}