The Core Aim of Vocabulary Mastery | AI Agent Supply-Chain Integrity Vocabulary

AI AGENT SUPPLY-CHAIN INTEGRITY · INVENTORY → VERIFY → BUILD → REVIEW → DEPLOY

An AI vocabulary tutor appears to be one helpful assistant, but its answers may depend on a document parser, retrieval index, embedding service, model, packages, prompts and reference library. Every component came from somewhere. A change in one of them can alter what a child reads, even if the interface looks identical. AI agent supply-chain integrity vocabulary explains how to understand and check that chain.

The core aim is traceable trust: identify the parts, their origins and versions; understand what integrity evidence can prove; decide whether third-party changes require security or educational checks; and know why plausible answers are not sufficient evidence. This guide extends the AI Agent Artifact Management Vocabulary and AI Tool Contract Versioning Vocabulary in the eduKateSG Vocabulary Hub.

A simple example: the source search still works but the citations are wrong

Imagine the assistant searches for a Secondary 1 Science term. A third-party indexing package was updated and now associates a paragraph with the wrong document ID. The model continues to write fluent explanations, yet the cited link no longer supports the claim. If the team knows which versions of the parser, index and retrieval code produced the result, it can identify the faulty transition and test the repair. If versions were never recorded, investigation is guesswork.

The supply-chain question is not ‘Which model did we use?’ but ‘Which inputs, software, services and processes led to this response?’ For a teaching system, the answer includes technical dependencies and source-document versions. Those are different sorts of assets, and each requires a relevant review.

Essential vocabulary: the components and their evidence

Term	Plain-English meaning	Question
Supply chain	The contributors and processes behind a delivered system.	Where do its parts come from?
Component	A package, model, service or other building block.	What is this part?
Direct dependency	A component the application deliberately selects.	What did we install?
Transitive dependency	A component brought in through another component.	What came along indirectly?
Supplier	The party providing a component.	Who supplied it?
SBOM	Software Bill of Materials: an inventory of software components.	What software does this release contain?
Dependency graph	The relationships between components and their dependants.	What relies on what?
ML-BOM	A bill of materials adapted to selected machine-learning assets.	Which model-related assets are represented?
Version pinning	Specifying particular supported component versions.	What did we actually test?
Content digest	A digital fingerprint of an artifact.	Do these bytes match the expected ones?
Provenance	Evidence about an artifact’s origin and production.	Where, when and how was it built?
Attestation	A statement of a property or production event, often machine-readable.	Who is making the claim?
Signature verification	Checking a digital signature under a trust policy.	Was this signed by an accepted identity?
Builder	A system that produces an artifact from inputs.	Which build environment created it?
Vulnerability advisory	Information on a discovered security weakness.	Which versions may be affected?
VEX	Vulnerability Exploitability eXchange: a claim about applicability.	Does this issue affect our product?
Release gate	A check before a component is deployed.	Should it enter production?
Integrity	The property of matching expected content or controlled state.	Has something changed unexpectedly?
Dependency update	Replacing or revising a required component.	What downstream tests are needed?
End-of-life	When support is withdrawn or a component is retired.	What replacement is necessary?

An SBOM answers ‘what is inside’, not ‘is everything safe’

An SBOM typically records software components, versions and relationships. OWASP’s Dependency Graph and SBOM guidance stresses direct and transitive relationships and explicit statements of incomplete coverage. If a scanner misses a package, the absence from its output is not proof the package is absent. Nor does listing a vulnerable component automatically prove the particular deployment is exploitable.

CycloneDX is a standard for expressing bills of materials, including software and machine-learning-related categories. It helps teams communicate inventory data, but it does not perform every relevant check by itself. The inventory must be mapped to actual deployed systems and compared with advisories, versions, operational controls and intended use.

Provenance, signing and correctness are different

SLSA—Supply-chain Levels for Software Artifacts—provides a framework for progressively stronger software supply-chain integrity. Its provenance specification represents details of how an artifact was produced. A consumer can verify a signature, builder identity and expected build parameters, depending on the ecosystem and format.

None of that means the produced software is bug-free or the educational explanation is correct. A well-signed artifact can contain a factual error. A matching hash proves that digital content matches a particular expected digest, not that the content is appropriate for Primary 6. A release needs both technical integrity and tests of what the product actually does.

Evidence	Useful for	Not proof of
SBOM	Identifying known components and relations.	A vulnerability-free product.
Verified digest	Matching a specific expected byte sequence.	Educational correctness.
Signed provenance	Checking accepted builder and production details.	All source code is safe.
Vulnerability report	Locating potentially affected releases.	Certain exploitation in this deployment.
Model evaluation	Measuring defined behaviour on test cases.	No unknown failures.
Teacher review	Checking accuracy and suitability of a teaching packet.	Security of every underlying dependency.

A worked case: WordPress publication after a formatter update

A website publishing assistant converts lesson drafts into WordPress blocks. A formatter update changes its table markup. The tool reports a published post, but WordPress strips part of the table and the resulting article is hard to understand. This may not be a cyberattack; it is a component and release-quality failure.

A dependable pipeline records the formatter version, input format, supported editor blocks and produced post ID. A regression test examines a representative table before deployment. After publishing, the workflow reads warnings and checks the saved output. The record makes it possible to identify precisely which articles might have been affected by the changed formatter.

Component	Record	Risk to inspect
Reference source	Owner, document edition, intended educational level	Old or misapplied syllabus.
Parser	Package version, configuration and test results	Lost table relationships.
Retrieval index	Index build identity and source manifest	Misaligned citations.
Model interface	Provider, configuration and output contract	Unexpected result format.
Formatter	Package version and supported markup	Stripped WordPress blocks.
Published artifact	Post ID, revision and returned status	Wrong or incomplete page.

Transitive dependencies hide below the surface

A PDF parser might use a separate image processing package, which in turn requires another library. The team may never refer to that last package directly, yet it can still affect the application. A dependency graph records these paths. When an advisory names a specific affected version, the graph helps identify the installed parent component and impacted deployments.

Response priority also depends on reachability, exposure and actual configuration. Depth in the dependency graph is not a complete risk rating. Teams should investigate whether the vulnerable code is present and reachable and whether an authenticated VEX statement appropriately explains why a reported issue is or is not applicable.

What is an AI supply-chain inventory beyond an SBOM?

For an educational assistant, a useful register may include model identity, training or retrieval assets where the relevant information is available, source registry version, index build, tool-server owner, prompts under change control and software packages. Not all these entries fit into one traditional software bill of materials. A machine-learning BOM or additional registries can represent some of them.

The inventory should explicitly state unknowns. Third-party services can be opaque; teams may know the interface and contractual obligations without knowing every internal component. An honest list of known dependencies and limitations is more useful than a complete-looking diagram that silently invents internal details.

Source-rights verification belongs next to technical integrity

An education library may contain public syllabuses, open materials and link-only third-party teaching resources. The fact that a webpage can be retrieved does not automatically grant permission to reproduce its text or use it for every commercial purpose. Source permissions should be checked independently of software signatures and package licences.

This creates two complementary questions: can the component be trusted and used securely, and can the content be lawfully and appropriately reused? Neither should be answered by a model’s confident summary alone.

A release checklist for an agent-powered teaching site

List the direct and relevant transitive software dependencies, plus key external services.
Capture component versions, source editions and known inventory gaps.
Check applicable security advisories and required licence information.
Verify artifact integrity and expected provenance where supported.
Test document parsing, retrieval relevance and cited passages.
Verify authorization and tool scopes for integrations.
Test real age-appropriate educational examples.
Inspect the saved WordPress content rather than relying only on the draft.
Record which version was deployed, by whom and under what reviewed criteria.
Have a safe plan for withdrawal or urgent restriction of affected components.

A small classroom exercise

An article cites the wrong source after a software update. Ask students to identify three potentially changed objects: the original curriculum document, the extraction or indexing software, and the article artifact. Which tests apply to each? Source verification checks the document; software release tests check parsing and mapping; editorial review checks the final explanation.

Now introduce an advisory affecting a third-party library. Does a package version in the SBOM settle whether the running service is exploitable? No. The team still needs to examine advisory scope, deployment conditions and relevant mitigations.

Common misunderstandings

SBOM means secure: an inventory is not a guarantee.
No recorded vulnerability means no vulnerability: unknown issues may remain.
Signed means accurate: provenance is not an educational fact check.
The model is the whole system: retrieval, data, tools and packages also matter.
One current package version applies everywhere: deployments can differ.
Every advisory requires identical action: assess affected versions and context.
Open website means unrestricted reproduction: check rights.
Passing tests before release proves future sources stay current: monitor changes.

Frequently asked questions

What is AI agent supply-chain integrity?

It is the checking of origins, composition, changes and risks in the software, models, data and processes that contribute to an agent’s operation.

What is an SBOM?

A structured inventory of software components and relationships in a given product or release.

What is a transitive dependency?

A component brought into the application because another component depends on it.

Does a digital signature make software safe?

No. A valid signature can help authenticate an expected producer or statement; safety and correctness require additional assessment.

Why does a vocabulary tutor need provenance?

It helps trace inaccurate or outdated learning outputs back to the relevant sources, models, tools or software changes.

References and connected learning

The AI agent supply-chain integrity vocabulary standard

A learner demonstrates mastery by identifying key components and their dependencies, distinguishing inventory from security assurance, explaining the purpose and limitations of provenance, and choosing tests that cover both software integrity and teaching accuracy. The aim is to make the chain behind an AI answer intelligible and correctable.