When “Standard” Isn’t Quite Enough: Assessible Earns PCI Certification

Digital assessment platforms live and die by their question types. Can you ask a student to drag elements into place? Match items on a canvas? Record their spoken answer? The richer the interaction, the richer the assessment, and the better picture you get of what a student actually knows.

The QTI standard (Question and Test Interoperability) already covers a solid set of interactions: multiple choice, text input, drag and drop, hotspot, and more. For the majority of exam scenarios, that is plenty. But education is not a majority-scenario business. It is a “this particular class of students, with these particular learning goals, taking this particular assessment” business. And eventually, every platform hits a use case that the standard does not cover.

So what do you do when you need something bespoke?

Enter the Portable Custom Interaction

The QTI3 standard has an answer for this: the Portable Custom Interaction, or PCI. A PCI is a defined mechanism for building novel interaction types that remain interoperable across any QTI-compliant delivery engine.

The key idea is a set of standard hooks. Your custom interaction communicates with the delivery engine through these hooks, and as long as both sides implement the spec, the interaction just works. Build it once, and it runs in any compliant engine.

That property is what makes PCI different from the older approach.

The old answer: just build it yourself

Before PCI, the practical answer to a missing interaction type was simple: build it as custom code. Write your own interaction, wire it into your platform, and ship it. This works fine right up until someone wants to move that content, or run it in a different delivery engine, or share it with a partner institution that uses a different tool.

At that point, you discover that your custom interaction belongs entirely to your platform. The open standard you thought you were operating within suddenly has a private extension stapled to the side of it. Governments and large educational institutions, many of whom write open-standard requirements directly into their procurement tenders, tend to notice this sort of thing.

PCI removes that compromise. The interaction is novel, but the way it plugs into the engine is not.

What certification actually means

The organisation behind QTI is 1EdTech. They run a certification programme that gives platforms a way to prove, and publicly demonstrate, that their implementation genuinely conforms to the standard. Assessible has held the main QTI3 certification for both its editor and player for some time. PCI certification is the next layer of that same programme.

PCI certification specifically covers what a delivery engine needs to do with a PCI item: import it as part of a content package, present it to a student, and export the results. That is the full cycle: show it, run it, score it. Without all three, you do not really have PCI support; you have a partial implementation that may or may not work in practice.

What made this particular certification interesting is that Assessible was part of the 1EdTech working group developing the certification requirements themselves. Some of the original draft referenced features that belong more naturally in the advanced QTI tier than in a basic PCI certification, and working through those distinctions with the group took several sessions. The result is a better-scoped certification, and ours was one of the early implementations to pass it.

The certification session used a standardised test package from 1EdTech: a mathematical graph interaction where a student can plot points and draw curves. Not a use case we had built for a client, but a well-defined example that exercises exactly the right parts of the spec, the PCI loading, the hooks, and the scoring output.

So what do we actually do with it?

Passing the certification is one thing. Using it is another.

The work currently in progress is on the authoring side: connecting custom PCI implementations to the content editor so that assessment authors can package a PCI, configure it, and have it run correctly in the player.

The first PCI we built was a Likert interaction, developed as a practical example to prove the implementation out end-to-end: could we actually build a PCI, plug it into the standard hooks, and have it score correctly? It worked.

The second is client-driven and currently in development: an audio recording interaction, something a client building language assessments needed specifically to test speaking ability rather than just reading and writing. A text input question does not help you there. Neither does multiple choice. You need the student to record themselves, and you need that recording to be part of the scored assessment in a standards-compliant way.

That is precisely the use case PCI was designed for. We build the interaction, connect it through the standard hooks, and it can run in any PCI-compliant delivery engine, not just ours.

Once the authoring support lands, adding new interaction types becomes a matter of implementing the specific use case and connecting it to the existing PCI infrastructure, rather than building something that lives entirely outside the standard.

What’s next

PCI support is one piece of a larger update to the Assessible Exam Player that is currently in the final stages of development. We expect to begin rolling it out to client deployments before summer, and by the time the new school year starts, at least one client should have a PCI-based interaction in active use with their students.

More to follow on the wider release in a separate post.