Chapter 4.1 opens part 4, the profile library, after part 3, the project library, and precedes chapter 4.2, The six documentation artifacts.
The profile library, the collection of documents that describes documentation treatments, contains the inventory, normative documents, status labels, words that record profile conditions, the entry-point index, file-kind glossary, application model, and profile metrics. The profile index, the table that lists profiles and their attributes, records the identifiers, names, statuses, intended roles, payload targets, primary phases, payload shares, relationship edges, decision notes, built variants, and build dates.
4.1.1 Ladder scroll sequence of the documentation profiles
A rung, a position on the documentation ladder, receives a dose, the amount of documentation assigned to it. Payload, the measured size of that documentation, is recorded for each profile. An artifact, a piece of documentation written into the codebase, belongs to a profile. The ladder uses cumulative nesting: higher rungs contain the artifact kinds used by lower rungs, while each profile is applied independently with its own caps. The scroll sequence shows the ladder progression in nine stills. Its measurements come from the measurement file and replace the outline-only dose-ladder.svg image. source: operations/site-ia/A6-page-briefs.md section L0.
Figure D-L0-1. The eight documentation doses in ladder order and the measured payload of each
%% figure D-L0-1 flowchart TB subgraph ladder["Ladder"] n1_1["step"] --> n1_2["0. Plan/Appendix B, Normative Reference.md"] n1_2 --> n1_3["payload_budget.json"] n1_3 --> n1_4["AGENT_CONTEXT.md"] end subgraph measurement["Measurement"] n2_1["traceability.json"] --> n2_2["LAP_LEVELS_GUIDE.md"] n2_2 --> n2_3["3. LAP Profile Library/api_reported_measurement_2026-08-06.json"] n2_3 --> n2_4["rungs"] n3_1["api_reported_tokens"] --> n3_2["payload_chars_uniform_basis"] n3_2 --> n3_3["H-STR"] n3_3 --> n3_4["source_basis"] n4_1["measurement_policy.md"] --> n4_2["1. Harness/scripts/instrument_profile.py"] n4_2 --> n4_3["compute_payload_pct()"] n4_3 --> n4_4["check_payload()"] n5_1["run_gate()"] --> n5_2["lap_profile_index.csv"] n5_2 --> n5_3["lap_profile_id"] n5_3 --> n5_4["payload_target"] n6_1["payload_pct_chars"] --> n6_2["relationship_edges"] n6_2 --> n6_3["decision_notes_per_kloc"] n6_3 --> n6_4["variant_built"] n1_4 --> n2_1 n2_4 --> n3_1 n3_4 --> n4_1 n4_4 --> n5_1 n5_4 --> n6_1 n1_1 -- "3. LAP Profile Library/LAP_LEVELS_GUIDE.md" --> n1_1_reference["reference"] end
source: operations/site-ia/A3-diagram-specification.md
source: operations/site-ia/A6-page-briefs.md section L0.
The ladder scroll sequence, with regenerated measurements and cumulative nesting across the documentation doses.
source: LAP_LEVELS_GUIDE.md sections one to four
4.1.2 Directory layout of the documentation profiles
The folder map places the profile index at the library root and groups the normative profile files beneath their profile folders. It shows the relationship between the index, profile folders, and shared library documents.
Figure D-L0-2. The profile folders, the library files, and the instrumentation kit
%% figure D-L0-2 flowchart TB subgraph g1[" "] n1_1["profile.md"] --> n1_2["artifact_rules.md"] n1_2 --> n1_3["traceability_rules.md"] n1_3 --> n1_4["payload_budget.json"] end subgraph g2[" "] n2_1["profile_manifest.json"] --> n2_2["example_snippets.md"] n2_2 --> n2_3["step"] n2_3 --> n2_4["ls"] end subgraph g3[" "] n3_1["L2T-targeted-trace-comments/"] --> n3_2["README.md"] n3_2 --> n3_3["step"] n3_3 --> n3_4["lap_profile_index.csv"] end subgraph g4[" "] n4_1["measurement_policy.md"] --> n4_2["traceability_schema.md"] n4_2 --> n4_3["api_reported_measurement_2026-08-06.json"] n4_3 --> n4_4["HASP Instrumentation/"] end n1_4 --> n2_1 n2_4 --> n3_1 n3_4 --> n4_1 n2_3 -- "LAP_LEVELS_GUIDE.md" --> n2_3_reference["reference"] n3_3 -- "LAP_LEVELS_GUIDE.md" --> n3_3_reference["reference"]
source: operations/site-ia/A3-diagram-specification.md
source: operations/site-ia/A6-page-briefs.md section L0.
The folder map of the profile index, library documents, and profile folders.
4.1.3 Profile ladder statuses of the documentation profiles
The index holds ten rows because its final two rows repeat L4P and L5P with the status, the recorded condition of a profile, frozen. The repeated rows are retained for the operator. The profile ladder and its statuses are: source: operations/site-ia/A6-page-briefs.md section L0.
source: LAP_LEVELS_GUIDE.md sections one to four source: lap_profile_index.csv rows 2 to 9
4.1.4 Status vocabulary of the documentation profiles
Each status label, a word that records a profile’s condition, is a name for one condition of a profile. The label planned means that the profile is named on the ladder without a complete definition. The label defined means that the profile has a complete and internally consistent definition without a built variant. The label instrumented means that the variant is built to the profile and passed through the Literate/Anchored Programming quality gate, a review of documentation quality. The label frozen means that the hashes and build record of an instrumented variant are retained.
The index uses these status values in its status column. The variant_built column identifies the related variant, and the manifest’s instrumented_variants block records the same association.
4.1.5 File-kind glossary of the documentation profiles
The file-kind glossary assigns a role to each profile file in the profile folders. The profile folders define profile identity and scope, set artifact order and review requirements, define traceability population, check payload caps, record status and instrumented variants, and supply worked code-level references.
The rule, example, and budget files remain as authored. Their contents are not rewritten by the operator.
4.1.6 Application model of the documentation profiles
The application model applies each profile independently to the same code. Each variant receives a fresh instrumentation pass governed by its profile rules and caps. Higher rungs contain the artifact kinds used by lower rungs, while budgets remain absolute for each profile. The model is specified in the ladder guide and in the instrumentation application-order document.
The profile files describe the artifact kinds and the rules for placing them in a variant.