Menu

#2 Structure of Wiki

closed
nobody
P0 (19)
2025-12-11
2025-12-07
Anonymous
No

Originally created by: alirezamshi
Originally owned by: alirezamshi

Description

This is the structure that we used for the product wiki which has Workflow → Concept → Implementation:

  • src/knowledge/wiki_structure/old_product_structure.md

This is its extension:

  • src/knowledge/wiki_structure/extension_of_product.md

The extension adds the following node types:

  • Artifacts - Data objects, schemas, configs
  • Heuristics - Tribal knowledge, decision frameworks, optimizations
  • Environment - Hardware, OS, dependencies

Goal

Define node types and possible edge relationships between them. For each node type (which becomes a wiki page), define:

  • What sections should each page include
  • What content belongs in each section

Test Unit

  1. Clone a sample repo like TRL (Transformer Reinforcement Learning)
  2. Use Claude Code in src/execution/coding_agents to execute on it based on the instruction
  3. Evaluate if the structure makes sense or not

Deliverable

A markdown file describing:

  1. Node types - All wiki page types with their definitions
  2. Edge types - Potential relationships between nodes (agent can extend if needed)
  3. Page structure - Sections and content requirements for each node type

References

Related

Tickets: #10
Tickets: #3
Tickets: #4
Tickets: #5
Tickets: #7
Tickets: #8
Tickets: #9

Discussion

  • Anonymous

    Anonymous - 2025-12-09
     
  • Anonymous

    Anonymous - 2025-12-09

    Originally posted by: alirezamshi

    WIP in [#31]

     

    Related

    Tickets: #31

  • Anonymous

    Anonymous - 2025-12-10

    Originally posted by: AlirezaNadafN

    • The brain only supports bottom-up, shouldn't we have some kind of top-down mechanisms too? For example, we have a workflow, and then we create and build some concepts for it.
    • Almost every component uses heuristic, why shouldn't it be a part of the content of each type and be a separated type?
    • From the executability point of view, shouldn't we define env for workflows and not concepts? I am not sure about this myself. let's say that a workflow says do step 1 and step 2 and step3, the env that is superset of steps and support all of them together matters.
     
  • Anonymous

    Anonymous - 2025-12-10

    Originally posted by: alirezamshi

    The brain only supports bottom-up, shouldn't we have some kind of top-down mechanisms too? For example, we have a workflow, and then we create and build some concepts for it.

    It doesn't say how to construct this graph, it's defining what are the edges and nodes. Can you clarify how the top-down work? like given a resource, what is the step by step instruction to build KG top-down?

    Almost every component uses heuristic, why shouldn't it be a part of the content of each type and be a separated type?

    Mainly for better indexing/retrieval. it can be inside them. what are benefits of putting it inside?

    From the executability point of view, shouldn't we define env for workflows and not concepts? I am not sure about this myself. let's say that a workflow says do step 1 and step 2 and step3, the env that is superset of steps and support all of them together matters.

    I think currently it's defined for "Implementation" as it's the lowest level node that is connected to the execution hardware. so, Environment node basically says what hardware to choose and what to install on it when running an implementation node. How can we connect it to workflow or concept? conceptually, what does it mean?

     
  • Anonymous

    Anonymous - 2025-12-10

    Originally posted by: alirezamshi

    Done in [#31]

     

    Related

    Tickets: #31

  • Anonymous

    Anonymous - 2025-12-10

    Ticket changed by: alirezamshi

    • status: open --> closed
     
  • Anonymous

    Anonymous - 2025-12-11

    Originally posted by: AlirezaNadafN

    1- Regarding the top-down I think we discussed it in the meeting. Let me know if any part needs explanations.

    2- I assumed just less complexity in the grammar would be beneficial. but we can keep it anyway.

    3- I mean let's say for text classification you need - read data with "pyspark", - use "deberta": probably need "GPU with Ram x" -Use "roberta" wth a "GPU with a lower memory than x" - print confusion matrix of "sklearn". Basically what I am saying is env is something collective and not for a single concept. again it depends on our definition of env and usage.

     

Log in to post a comment.