Technical work improves through feedback.
A diagram can look finished and still be missing required information. A file can open correctly and still fail to meet the requirements of the activity.
The Feedback System gives you a way to submit a technical artifact, review the feedback returned to you, revise the artifact, and try again.
The important idea is not simply submit.
The useful cycle is:
Create → Submit → Read → Revise → Submit again
That cycle is a normal part of technical work.
Before using the Feedback System, make sure you are working with the current version of your file.
For a Violet activity, that means the editable diagram file you have been saving as you work.
Avoid creating several nearly identical copies unless the course specifically asks you to do so. It is easy to revise one file and accidentally submit another.
Know which file is your current work before you begin the submission process.
Open the Feedback System using the access method provided by the course.
Use the submission area associated with the activity you are currently completing.
The exact screens may differ depending on the activity, so follow the directions displayed by the course and Feedback System rather than relying on a remembered sequence from another task.
When the system asks for your technical artifact, select the current file required by the activity.
When feedback is returned, read it before changing the file.
Do not begin by making random edits.
First determine what the feedback is telling you.
A useful way to read technical feedback is to separate it into three questions:
For example, later UML feedback might identify a problem with an element, value, or relationship.
The goal is not to make the message disappear by experimenting with unrelated changes.
The goal is to understand the difference between the current artifact and the expected requirement.
When possible, fix one clear issue and then review the artifact again.
Suppose several messages are returned.
Start with the first problem you understand.
Open the original editable file, make the focused correction, and save it.
Then look at the artifact again before submitting it.
This approach helps you connect a particular change with the feedback that caused it.
If you change many unrelated things at once, it becomes harder to know which revision solved the problem or created a new one.
As you use the system, feedback may point you toward different kinds of issues.
For example, a technical artifact might have:
Treat the feedback as evidence.
Read the message, return to the actual requirement or Learning Activity, and decide what the artifact should represent.
A feedback message can help you locate a difference, but you are still responsible for understanding the artifact.
Avoid the pattern:
change something → submit → change something else → submit → repeat until the message disappears
That may eventually produce an accepted file without helping you understand why it is correct.
A stronger process is:
read the requirement → inspect the artifact → interpret the feedback → make a reasoned revision → submit again
The goal of feedback is improvement, not guessing.
After making a revision in Violet, save the editable file.
Then make sure the file you are about to submit is the file you just changed.
This matters because an older saved copy may still contain the original problem.
A simple habit can prevent a lot of confusion:
Edit → Save → Confirm the file → Submit
Sometimes a message may not immediately make sense.
When that happens, do not invent a correction.
Return to:
If the issue is still unclear, ask for help using the professional communication habits you practiced earlier in the course.
Include useful evidence about what you submitted and what feedback you received, but do not share passwords, authentication codes, or other private information.
Receiving feedback does not mean that the work was pointless.
The first version gives you something concrete to inspect.
The feedback identifies a difference.
The revision gives you a chance to apply what you have learned.
That pattern appears throughout technical work. Programmers use compiler messages, tests, debugger observations, code review, and user feedback in much the same way: evidence reveals a gap, and the artifact is revised.
For now, your focus is the same with diagrams.
Use the Feedback System to help you move from a first attempt toward a more accurate technical artifact.
When you use the Feedback System, remember this sequence:
Create the current artifact.
Save the current file.
Submit the correct file.
Read the feedback carefully.
Connect the message to a requirement.
Make a focused revision.
Save and submit the revised file.
The purpose is not to satisfy a machine through trial and error. The purpose is to use feedback as evidence that helps you improve your technical work.