Continuous authorization and DevSecOps evidence
Retest the workflow when a component or data path changes.
In this lesson · G5 of 9
All lessons in this track →Progress for this track is saved in this browser only. No completion badge is issued. View your learning.
Start with the idea
Retest the workflow when a component or data path changes.
Changing search can change answers even if the generator stays the same. Keep versioned evidence. Automated checks support review; they do not grant themselves permission.
False green: A passing signal that misses an important failure.
See the example and check your understanding
A made-up teaching example
Release R2 changes the numeric representations used for search, called embeddings. Individual code tests pass, but search selects an outdated notice in four of twenty cases. Hold the release and recheck the sources.
Ask yourself
Does an unchanged generator prove unchanged answer quality?
Show the explanation
No. Inspect the whole workflow. Reopen relevant boundary reviews when data paths change.
Start with these checks
- Retain versioned test results.
- Test source currency and support.
- Match each signal to the claim it actually proves.
Use the different practice case below and check every requirement in its full instructions.
The video explains the main idea. Use the sources, instructions and checks below to complete the practice.
Captions appear here during playback.
Continuous authorization and DevSecOps evidence
Retest the workflow when a component or data path changes.
Video playback is unavailable. Read the descriptive transcript below, go directly to practice, or open the video file.
Source-based teaching example · Fictional data · Reviewed 2026-10-03. Microsoft Mark · locally synthesized. On a small screen, use fullscreen for diagram details or read the transcript.
Read the descriptive transcript
0:00 · What you will learn
Retest the workflow when a component or data path changes.
What appears on screen
Retest the workflow when a component or data path changes.
0:06 · The idea
Changing search can change answers even if the generator stays the same. Keep versioned evidence. Automated checks support review; they do not grant themselves permission.
What appears on screen
Changing search can change answers even if the generator stays the same. Keep versioned evidence. Automated checks support review; they do not grant themselves permission.
0:20 · One useful term
False green. A passing signal that misses an important failure.
What appears on screen
A passing signal that misses an important failure.
0:27 · A worked example
Release R2 changes the numeric representations used for search, called embeddings. Individual code tests pass, but search selects an outdated notice in four of twenty cases. Hold the release and recheck the sources.
What appears on screen
Release R2 changes the numeric representations used for search, called embeddings. Individual code tests pass, but search selects an outdated notice in four of twenty cases. Hold the release and recheck the sources.
0:45 · Your turn to think
Does an unchanged generator prove unchanged answer quality? Pause and decide before continuing.
What appears on screen
Does an unchanged generator prove unchanged answer quality? Pause the video if you need more time.
1:02 · Why this answer works
No. Inspect the whole workflow. Reopen relevant boundary reviews when data paths change.
What appears on screen
No. Inspect the whole workflow. Reopen relevant boundary reviews when data paths change.
1:12 · Check 1
Retain versioned test results.
What appears on screen
Retain versioned test results.
1:17 · Check 2
Test source currency and support.
What appears on screen
Test source currency and support.
1:22 · Check 3
Match each signal to the claim it actually proves.
What appears on screen
Match each signal to the claim it actually proves.
1:28 · Now try a different case
Open the lesson and try its different practice case. Use every check in the full task. Watching alone does not mark the lesson complete.
What appears on screen
Open the lesson Try the new case Check and revise The full task and its requirements are in the linked lesson.
Watching explains the example. Complete the lesson practice to check what you can do. Explore all visual lessons →
Prerequisites: distinguish generated output from source evidence; review the AI workflow reference. Public self-study is not official agency training, accreditation or a credential.
What you will be able to do
This lesson develops the ability to design continuous evidence without claiming continuous authorization. The setting is ORION Service Navigator, a fictional public-benefits information service using public guidance and wholly synthetic constituent questions; it never determines eligibility or takes an action on a person. Every person, organization, system record, metric, and outcome in the case is fictional. Do not replace the case with operational, classified, CUI, export-controlled, proprietary, employer-confidential, or third-party personal information.
By the end of the lesson, you will be able to:
- Demonstrate how to design continuous evidence without claiming continuous authorization.
- Apply that model to the synthetic ORION Service Navigator environment.
- Produce a reviewable artifact that separates evidence, assumption, uncertainty, and authority.
- Recognize the critical failure and select a safe remediation path.
The performance standard is not confident language. It is a traceable decision, an artifact another qualified reviewer can inspect, a clear boundary around the learner’s authority, and a safe response to uncertainty. Knowledge checks are formative and do not award a certification or endorsement.
This curriculum runs self-study on VetsLearn. Where the text calls for an instructor, peer or formal review, use the stated acceptance criteria for self-review. Reflection questions support reflection; they do not replace independent assessment. A peer review is optional unless your actual organization requires it.
Part 1 Continuous attributable evidence
Continuous authorization needs an established approach, monitoring, change boundaries and decision authority. A green CI pipeline cannot authorize a service. Record artifact version, collector identity, environment, timestamp, method and retained result. Dependency scans test known package issues, not source-supported answers. Retrieval tests cover access; tool tests cover permission denial; reviewer tests measure detection. Model, prompt, corpus, embedding, tool and hosting changes invalidate different evidence.
Link evidence to a release
Use a release identity such as R2 = application commit C2 + prompt P1 + corpus D4 + embedding E2 + generator M1 + permission policy T0. Each test record names that tuple, environment, timestamp and output. If a report says only “tests passed,” reviewers cannot know whether the deployed tuple was tested.
| Change | Evidence reopened | Evidence possibly retained |
|---|---|---|
| E1 → E2 embedding | Retrieval relevance, source currency, role filtering | Unchanged physical hosting evidence |
| Read-only → write tool | Permission denial, recipients, duplicate actions, recovery | Source fixture provenance |
| Internal → hosted traces | Data boundary, access, retention | Unchanged answer-format checks |
Fictional release results: R1 finds current notice S2 in 20/20 cases. R2 finds old S1 in four cases. A dependency scan is green for both. Keep the scan result as package evidence, but do not use it to negate the retrieval failure. Restore E1 only through the authorized change process and rerun the affected suite.
Feedback: “continuous” means evidence and decisions remain connected as the system changes. It does not mean every automated success is risk acceptance.
Part 2 Synthetic worked example
Release R2 changes embeddings only. Unit tests pass, but retrieval selects an outdated notice in four of twenty cases. The generator is unchanged; the workflow quality is not. Hold the changed retrieval release, retain versioned results and reopen currency and source-support evidence.
Guided practice: identify the unsupported conclusion, name missing evidence and rewrite with its scope intact. Change one assumption and identify which decision reopens.
Part 3 Feedback and repair
Pass when signals prove bounded claims, false-green results are possible and changed data paths reopen boundary review. Automation does not issue its own permission.
Keep failed evidence beside the repair. Explain the criterion, correct the artifact and test a different invented case.
Next step: carry your versioned artifact and failures into the next federal lesson; the capstone returns to these records. Check live policy and authorization with current official sources and responsible owners.