SyntheraOS University

HANDBOOK / PRACTICAL DETAILS

Make project information useful.

Give a record enough context to be understood, reviewed and used after it leaves your hands.

Give every record enough context to travel

Use this checklist when creating or handing over project information. Some details belong in linked evidence or interface documents; explain where the recipient can find them.

01

ID

Refer to the same object across conversations, diagrams and evidence.

TRAIN-REQ-001

Is it unique, stable and linked rather than copied into competing records?

02

Owner

Make responsibility for review and the next action explicit.

Training display engineer

Does the owner know what they need to decide or provide?

03

Source

Explain where the statement came from.

TRAIN-NED-001 and a fictional workshop note

Can the recipient inspect the source and distinguish fact from assumption?

04

Units and timing

Make quantities and intervals interpretable.

SOC in percent; seconds from receipt to display

Are units, start/end events and any clock assumptions stated?

05

Revision

Identify the version used in a design, review or test.

TRAIN-REQ-001 revision 2

Do linked results and documents identify the corresponding revision?

06

Status

Show where the record sits in the agreed workflow.

Proposed, in review or approved

What action and authority justify this state? What remains open?

07

Evidence

Support a particular conclusion with inspectable material.

TRAIN-RES-002 and its training timing log

Does the evidence exist, match the conditions and support this claim?

08

Relationships

Preserve purpose, dependencies and the route to supporting checks.

Need → requirement → display → verification case

Do the link types mean what you intend? Are affected records missing?

Four examples. One connected feature.

FICTIONAL TRAIN- RECORDS

EXAMPLE 01

From a requirement to a result

The fictional crew needs battery condition visible at the bridge. Revision 1 of TRAIN-REQ-001 requires the display to update within five seconds after receiving a valid SOC value.

TRAIN-NED-001TRAIN-REQ-001TRAIN-VER-001TRAIN-RES-001

Inputs

  • Receipt event at 120.0 seconds
  • Display update at 123.2 seconds
  • Revision 1 criterion: delay ≤ 5 seconds

Actions

  1. Link TRAIN-VER-001 to the requirement revision.
  2. Define receipt and visible update events in the procedure.
  3. Record the observed interval and supporting training log.

Output

TRAIN-RES-001 records 3.2 seconds and PASS against revision 1. This conclusion concerns receipt-to-display delay, not data freshness.

Keep the tested revision with the result. A later criterion change does not rewrite what this earlier test established.

EXAMPLE 02

Hand over a message both sides understand

TRAIN-CMP-002 provides SOC to TRAIN-CMP-001, the bridge display. The fictional interface carries value, unit, source timestamp and quality.

TRAIN-IFC-001TRAIN-CMP-002TRAIN-CMP-001TRAIN-REQ-002

Inputs

  • SOC: 80 percent; quality: valid
  • Source timestamp: 119.0 seconds
  • Evaluation at display: 123.2 seconds
  • Separate training freshness rule: source age ≤ 5 seconds

Actions

  1. Agree producer, consumer and field interpretation.
  2. Use the shared training clock to calculate source age.
  3. Define visible stale/invalid behavior and its verification.

Output

The value is 4.2 seconds old at evaluation, so it meets this training freshness rule. Receipt-to-display delay remains a separate calculation.

A quickly displayed value can already be old. Define clock handling and freshness behavior instead of treating fast display as proof of current information.

EXAMPLE 03

Turn a risk response into checkable work

Source updates might stop while the display keeps presenting the old SOC number as current. In the fictional exercise, this could confuse the crew.

TRAIN-RSK-001TRAIN-IFC-001TRAIN-ISS-001

Inputs

  • Cause: source updates stop
  • Event: old value remains apparently current
  • Candidate response: visible stale-data indication

Actions

  1. Link the risk to the interface and display requirement.
  2. Assign an owner to define the freshness behavior.
  3. Test loss of updates and inspect the displayed indication.
  4. Record unexpected observed behavior as TRAIN-ISS-001.

Output

The team has a linked mitigation action and evidence to review. Writing the mitigation alone does not show it was implemented or effective.

Explain the basis of any residual rating. Keep proposed response, implementation and verification as distinguishable states.

EXAMPLE 04

Change the target and check again

TRAIN-CR-001 proposes reducing receipt-to-display delay from five seconds to two seconds. The separate five-second source-age rule is unchanged.

TRAIN-CR-001TRAIN-REQ-001TRAIN-VER-002TRAIN-RES-002

Inputs

  • Proposed requirement revision 2: delay ≤ 2 seconds
  • Affected interface, display and verification records
  • A new fictional run measures 3.2 seconds

Actions

  1. Review the reason, alternatives and dependent work.
  2. Record the change disposition before applying the revision.
  3. Update the case and assess the new run against revision 2.

Output

TRAIN-RES-002 is FAIL: 3.2 seconds exceeds two seconds. Preserve TRAIN-RES-001 as the earlier PASS against revision 1, then assign follow-up work.

Do not reuse the older PASS as evidence for the tighter criterion. A freshness pass also cannot cancel a timing failure.

SYSTEM ASSESSMENT / WHAT THIS MEANS FOR USERS

Use the connected model with informed review.

What the system helps organize

The assessed prototype brings project context, engineering definition, assurance, decisions, delivery and learning into linked records. Its graph and summaries help users find dependencies and inspect the information behind a claim.

The reference covers 60 assessed information-flow records across eight groups. The nine diagrams explain their relationships, including return paths for changes and operating lessons.

What a screen alone cannot establish

  • A quality score does not establish accepted evidence or release authority.
  • A proposed action still needs a disposition, owner and follow-through.
  • A report card must be distinguished from an actual, readable file.
  • A modeled sensor or connector does not establish a live, current data feed.
  • Prototype behavior and deployment settings can change. Check the current workspace before applying a procedure.
Learning rule: inspect the source, identify the revision, understand the conditions, and assign the next decision to a person. The module reference retains specific behavior limits from the assessment.

Questions teammates commonly ask

Where should a new teammate begin?

Start with one need and follow its requirement, design and check. Use the first twenty minutes above, then choose the role playbook closest to your work.

Does a high score mean the work is ready?

Use scores to locate questions. Inspect the underlying records, evidence and agreed review criteria before deciding what is ready for the next step.

Can I apply an AI recommendation immediately?

First inspect its sources, assumptions and affected records. Turn useful advice into a proposal for the appropriate review rather than treating confidence as approval.

How do I know an export is usable?

Find the actual file, open it and inspect its content and version. Check which formats your workspace supports; a document card or success message alone is not an artifact.

What if my telemetry screen has no readings?

Check whether it shows a modeled source, a connected feed or an actual observation. Confirm source, timestamp, units and quality before using a value as current information.

Does finishing this course approve a real project?

No. Completion records learning practice. Real project decisions follow your team’s responsibilities, review process and evidence requirements.

About this learning site

This is a learning companion based on the SyntheraOS assessment and project information models prepared on 14 September 2026. It uses a simplified SyntheraOS University learning interface. The coastal e-ferry prototype (new tab) is the product reference.

Exercises use fictional TRAIN- records and simplified teaching values. This site stores personal exercise progress in your browser and does not connect to a project backend, write project records or share learner results with a manager. Download a learning record when you want to hand it to a facilitator.

Coverage describes the assessed prototype. It is not a claim that every deployment, integration or operational workflow has been independently verified. Course completion is a learning record; project approval follows your team’s own responsibilities and evidence review.