Criteria are used to specify when an advancement is completed by a player. They consist of two parts: triggers and conditions. Triggers are used to detect certain events happening in the game, for example the inventory changing or the player breeding two animals. The conditions can then be used to specify certain details, so instead of the advancements being granted for breeding whatever animal you can tell the game to only grant it when the player breeds two wolves.

{
  "criteria": {
    "Criteria_Name": {
      "trigger": "minecraft:TRIGGERNAME"
    },
    "Another_Criteria_Name": {
      "trigger": "minecraft:TRIGGERNAME",
      "conditions": {
        "CONDITIONNAME": "VALUE"
      }
    }
  }
}
Above you will see the basic format of a custom advancement with two criteria. You can replace "Criteria_Name" and "Another_Criteria_Name" with whatever text you want, but "TRIGGERNAME" and "CONDITIONNAME" must be picked from a list of available criteria which are coded into the game. An example is given below.

{
  "criteria": {
    "Criteria_Name": {
      "trigger": "minecraft:bred_animals",
      "conditions": {
        "parent": {
          "type": "minecraft:cow"
        }
      }
    },
    "Another_Criteria_Name": {
      "trigger": "minecraft:location",
      "conditions": {
        "biome": "minecraft:desert"
      }
    }
  }
}
This advancement will be granted when the player has both bred a cow and has visited the desert, doing them simultaneously is NOT necessary however. So you can visit the desert and leave it, then breed a cow and still obtain the advancement. You don't necessarily have to specify any conditions, in which case the criteria will be full-filled when its trigger has been activated. For triggers like "enter_block" and "location" this means that they will be granted basically immediately.

This is not everything however, since you can have some more optional control over criteria using the "requirements" parameter. This is a list of lists. In the code below, the requirement list includes one list, which then contains the two criteria. Having criteria in the same list means either one of them has the be completed for that whole list to count as completed. In more technical terms, the requirements are in conjuctive normal form.
{
  "criteria": {
    "Criteria_Name": {
      "trigger": "minecraft:bred_animals",
      "conditions": {
        "parent": {
          "type": "minecraft:cow"
        }
      }
    },
    "Another_Criteria_Name": {
      "trigger": "minecraft:location",
      "conditions": {
        "biome": "minecraft:desert"
      }
    }
  },
  "requirements": [
["Criteria_Name", "Another_Criteria_Name"]
]
}
To see how this truly works a more complex example might help clear things up.
"requirements": [
  ["A", "B", "C"],
["D"],
["E", "F"]
]In this example above, the advancement will be granted when a player has completed (A or B or C) and (D) and (E or F). So they can complete A, D, and F to get the advancement, but also C, D, and E (and many other combinations). This jumble of ands and ors also gave rise to another common name for this logic, an "AND of ORs". The simplest way to think about it is by realizing a player just needs to complete each list which can be done by completing any of its criteria.

You hopefully have a working advancement now, but it's not doing anything. For this we need some other elements.

Rewards are an optional part of advancements. As the name suggests they reward the player for completing the advancement. They are 4 different types of rewards, all of which are shown here:
{
  "criteria": {
    "Criteria_Name": {
      "trigger": "minecraft:bred_animals",
      "conditions": {
        "parent": {
          "type": "minecraft:cow"
        }
      }
    },
    "Another_Criteria_Name": {
      "trigger": "minecraft:location",
      "conditions": {
        "biome": "minecraft:desert"
      }
    }
  },
  "rewards": {
   "recipes": [],
"loot": "",
"experience": 0,
"function": ""
}
}
Recipes will grant the player certain recipes for in their recipe book. It's a list containing the namespace and name of the recipes you want to give the player.
Loot will give the player items based on loot tables from mob drops and chests spawned in structures (this will completely mimic the behavior of loot, including randomization). Custom loot tables are also a thing so giving items is extremely customizable.
Experience is pretty straight forward, it will grant experience points (NOT levels) to the player.
Function will run the commands from the function you specified.

As always you do not need to specify something you're not using. If you only want to grant the player experience you only have to include the "experience" reward.

You have a pretty nice custom advancement now, but to make it even nicer we can make your advancements display in the actual Minecraft advancement list and make them pop up when a player has completed them.
Before we do this we need to talk about how to structure multiple advancements together, which is actually pretty easy. The "root" or "start" of an advancement tree is the first advancement in branching of multiple advancements and is defined by NOT having a "parents" parameter in the json file. So the advancement we made previously is a root advancement (with a path file of for example: .minecraft/saves/<world name>/datapacks/<data pack name>/data/custom/advancements/stuff/root.json which means its namespace is "custom") , but with no other advancements after it yet. So let's make another advancement to branch of the root advancement now.

data/custom/advancements/stuff/BranchA_advancement.json

https://pastebin.com/r4cAJGwU

This advancement has its parent defined as "custom:stuff/root". "custom" being the namespace and stuff/root being the remaining path to the root advancement. Keep in mind that these names are arbitrary and can be changed to your liking. You can even have an advancement in a one folder be the parent of an advancement in another folder (even an entirely different namespace)!

You can have multiple advancements referring to the same parent, making different branches. Or you can make a line of advancements each having the previous one as a parent. Having multiple parent advancements is however not possible. Keep in mind that parents don't prevent other advancements from being achievable. So you can complete a branched advancement without achieving its parent.

Now that you can link advancements together, let's actually make them display. To make an advancement tree branch display in the advancement list, you need to add the display parameter to the root files and all its branches. You must specify icons, titles and descriptions for each advancement. For the root advancement you can also specify the background for the advancement tab. You can set the frame of the advancement to 3 different shapes: "task", "challenge" and "goal" ("task" being the default when not specified). On top of that, you can specify if you want the advancement to be announced in chat or pop up on screen using "announce_to_chat": true/false and "show_toast": true/false respectively (they both default to true when not specified).
You can also use "hidden": true/false. This determines whether or not to hide this advancement and all its children from the advancement screen until the hidden advancement have been completed (after which all its children will also become visible as long as they're not set to be hidden themselves). This has no effect on root advancements since they are always hidden.

For example:

custom/advancements/stuff/root.json

https://pastebin.com/yBqjrVhn

custom/advancements/stuff/BranchA_advancement.json

https://pastebin.com/BmGbkq8D

This will produce an advancement tab like this once one of the two advancements has been completed. Adding the display parameter for an advancement will also make it pop up when it has been completed (unless "show_toast" is set to false). If you want branched advancements to pop up but you don't want them to display on the advancement screen, simple remove the display parameter from the root advancement, but keep it on the branched advancements.



As you saw, for titles and descriptions you can simply provide a string of text but you can also add some text formatting the same as you would with text components from /tellraw and /title commands (except for event listeners, scores and selectors). An example:

"title": {"text":"Hello World","obfuscated":true,"italics":true,"bold":true,"color":"dark_red"}

There are 3 main commands associated with advancements:

- /advancement <grant|revoke> <player> <only|until|from|through|everything> [​advancement] [​criterion]
This command can either grant (give) or revoke (remove) advancements or advancement criteria.
"only" -> Grants/revokes only the specified advancement from the player.
"until" -> Grants/revokes the specified advancement, its parent advancement, its parent's parent advancement, etc. from the player. From the start until the specified advancement. The exact order of granting/revoking is "parent" > "parent's parent" > ... > "start" > "specified advancement".
"from" -> Grants/revokes the specified advancement, its children advancements, its children's children advancements, etc. from the player. All the way forward from the specified advancement. The exact order of granting/revoking is "specified advancement" > "child" > "child's child", when a branch is found it will iterate through the top branch entirely before going through the other branches. Because the order of branches depends on how the operating system reads the files, this order will be inconsistent across different operating systems.
"through" -> Acts as until and from combined; all advancements through the specified advancement, going both backwards and forwards. The exact order of granting/revoking is the same as for until and from, until being done before from.
"everything" -> Grants/revokes every loaded advancement from the player.

- /advancement test <player> <advancement> [​criterion]
This command will test if a player has completed an advancement or one of its criteria.

- /reload
This command will reload all advancement, function and loot table files from the disk in case they have been updated during a session.

There are 2 main commands associated with functions:

- /function <function>
This command will execute all commands from the function file you specify through the player or commandblock that uses this command. An example: /function example:pep/test will run the function file located at data/example/functions/pep/test.mcfunction
- /reload
This command will reload advancement, functions and loot table files from the disk in case they have been updated during a session.