Principles for the work
Show the source, including its limits.
If a scenario uses a fictional document, label it. If a product panel is illustrative, say so beside the panel. A reader should not have to reach the footer to discover what is real.
For an actual deployment, the equivalent discipline would be to connect each answer to accessible evidence and make conflicting or outdated sources visible. That is a design principle, not a claim about an available Oprill runtime.
Make the source visible.
- Name the approved input.
- Keep a citation beside the claim.
- Show where the source ends.
Give the task a boundary.
- Define the expected output.
- Leave missing facts unresolved.
- Separate a draft from an action.
Make review useful.
- Check meaning before tone.
- Record the reason for a correction.
- Revisit the example after a change.
Leave a clear handoff.
- Preserve the original question.
- Explain the remaining uncertainty.
- Identify who decides what happens next.
Illustrative working practice
Make the next decision smaller.
A useful draft narrows the work for its reviewer. It separates the proposed action from its assumptions and tells the reviewer what must be checked before proceeding.
For example, a project handoff should distinguish agreed tasks from suggested tasks. Both can belong in the same summary, but they should never look equally approved.
Start with shared context.
An illustrative project handoff begins with an approved brief and the question it must answer. The reviewer should be able to distinguish background information from a current decision.
Make the correction inspectable.
Keep a short note explaining what was wrong and which source resolved it. That gives the next reviewer something concrete to check instead of a silent revision.
Carry the limits forward.
A summary should preserve uncertainty when it is relevant to the next decision. A missing date, unconfirmed owner or conflicting source belongs in the handoff, not behind a confident sentence.
Illustrative settings · not office locations
Respect the person on the other side.
Writing should explain the consequence of an action in plain language. Controls should work with a keyboard and on a phone. A disabled service should explain its availability without pretending to accept a request.
These principles describe the work we intend to hold ourselves to. They do not stand in for claims about an established workplace culture, employee benefits or hiring policies.
At a project handoff
A fictional brief, a changed requirement and the note explaining the change.
During a review
A draft beside its source, with open questions kept visible.
Before sharing
An audience check that happens before an external message or export.
After a correction
A record of the failure and the revised review instruction.