Appearance

Projects & Jobs ​

Projects ​

A project is a space to run jobs. Projects can be created by any lab user regardless of their lab role. By default, projects are private and can only be viewed by the lab user who created them. If a lab user shares a project, the lab users that obtained the shared access implicitly gain read access to the jobs inside of it. Projects can be shared with the entire lab or specific lab users within the same lab space.

Jobs ​

Jobs are executions of modules created under a project. There are three main requirements for creating a job:

  • A Project Space - A job must be created inside a project.
  • Module - A job is an execution of a specific module. Therefore, access to the module is required.
  • Module Inputs - A module takes a variable amount of inputs. All input requirements must be satisfied.

There are different states or statuses of a job:

  • Draft - A draft can be edited multiple times. No processing is done on jobs with this status.
  • Ready - A ready state can be created directly or it can be changed from a draft state. Processing will be done on jobs with this status.
  • Processing - A process is currently running the job. This state is usually temporary.
  • Errors - A job is processed but contains errors. At this stage, the job record is immutable.
  • Completed - A job is processed without any system errors. However, it is possible to have logical errors. At this stage, the job record is immutable.

Digital Signature ​

While each job has a unique ID (UUID), a job may also have a digital signature. The main difference between a job's UUID and a digital signature is that two or more jobs can have the same digital signature. We only calculate the digital signature after a successful job execution.

We calculate a job's digital signature based on the module, inputs, and outputs. The reason is that some jobs can have the same input but different output. We can observe such cases with LLM interactions. We can uniquely identify inputs by storing the hash of the input. In most cases, if the input is a file, we store the file's hash. That way, the file can be safely deleted without affecting the calculation.

How we calculate the job's digital signature:

  • h = H(E || Si || So) - Where H() is the hashing function, E is the hash of the module ID, Si is the hash of the inputs, and So is the hash of the output.
  • Si and So - Both are results of S() function such that S = H(S1 || S2 || S3 || ... || Sn) where n is the number of inputs/outputs, and S1, S2, etc. are the hash of the inputs/outputs.
  • Hashing function - We use md5 as the hashing function.

Here is an example of a digital signature calculation using pseudocode:

  1. Let's say that we have a module ID value of 1
E = md5("1")
E = "c4ca4238a0b923820dcc509a6f75849b"
  1. For input, we have two values foo and bar
Si1 = md5("foo")
Si2 = md5("bar")
Si1 = "acbd18db4cc2f85cedef654fccc4a4d8"
Si2 = "37b51d194a7513e45b56f6524f2d51f2"
  1. Therefore, we have this hash for Si
Si = md5("acbd18db4cc2f85cedef654fccc4a4d8" || "37b51d194a7513e45b56f6524f2d51f2");
Si = "a84ffba5c71c24627a369146227d701a"
  1. Let's say the output is a file with the hash 73feffa4b7f6bb68e44cf984c85f6e88
So = "73feffa4b7f6bb68e44cf984c85f6e88"
  1. Finally, we have the hash of 56eca9636ab105d73325538b28d85899 for h
h = md5(E || Si || So)
h = md5("c4ca4238a0b923820dcc509a6f75849b"  || "a84ffba5c71c24627a369146227d701a" || "73feffa4b7f6bb68e44cf984c85f6e88")
h = "56eca9636ab105d73325538b28d85899"

Databases/Datasets ​

Database or datasets are collections of data. They can be a physical file uploaded to the system or an end-point that a job can have access to. The most common format of the dataset is csv. Note: The csv format does not always follow a strict standard. For example, a delimiter can be a ,, ;, or sometimes |. Within our may expect the format to use ,.

Fields/Topics ​

A field may be an academic field/field of study or area of specialization that a user is associated with in a lab space. Topics and sub-topics fall under a field. Each lab space is free to define its sets of fields/topics and sub-topics. Users are expected to select a field when joining a lab. Unless a lab user has permission to change their fields freely, a field association is permanent.