Obsidian System

Vault structure

00 Inbox/
01 Home/
├── University Dashboard.md
└── Obsidian System.md
10 Courses/
├── Computer Architectures.md
└── Computer Architectures/
    └── Lectures/
20 Concepts/
└── Computer Architectures/
    ├── RISC-V.md
    ├── Registers and Immediates.md
    ├── Memory Addressing.md
    ├── Stack.md
    ├── Function Calls.md
    ├── Branches.md
    └── Pipelining.md
30 Templates/
├── Course Template.md
├── Lecture Template.md
├── Lab Template.md
├── Exercise Template.md
└── Concept Template.md
40 Projects/
50 Labs/
└── Computer Architectures/
    ├── Lab 01 - gem5 and ASE Studio.md
    └── lab_01 1.docx
90 Archive/
Course Name.md (template placeholder)

Documentation rules

Cloud Computing Technologies

The Cloud Computing Technologies hub follows the same lecture/concept structure as Computer Architectures:

• Lecture notes: 10 Courses/Cloud Computing Technologies/Lectures/
• Original slides: 10 Courses/Cloud Computing Technologies/Resources/
• Reusable concepts: 20 Concepts/Cloud Computing Technologies/
• Lab notes, when supplied: 50 Labs/Cloud Computing Technologies/

Retain source numbering when it is available. Mark historical figures and distinguish slide content from added study explanations.

Course notes

Store under:

10 Courses//Lectures/

Purpose:

• what the professor covered
• professor-specific examples
• lecture-specific details
• links to concepts

Concept notes

Store under:

20 Concepts//

Purpose:

• polished long-term knowledge
• simple explanations
• examples
• important rules
• common mistakes
• related concepts

Avoid duplicating the whole lecture inside the concept note.

Labs

Store under:

50 Labs//

Lab notes should contain:

• course
• deadline
• status
• objective
• submission requirements
• setup
• exercises
• results
• observations
• problems encountered
• what I learned
• questions
• related concepts

Linking

Use Obsidian wiki links:

Pipelining
Branches
Computer Architectures

Link labs, lectures, exercises, and concepts together whenever relevant.

Style

• clean Markdown
• practical rather than overly academic
• explain difficult concepts simply
• preserve professor terminology when working from lecture PDFs
• distinguish professor material from extra explanation
• use code blocks for assembly
• use checklists for tasks
• use tables for experimental results