diff --git a/docs/eido/README.md b/docs/eido/README.md
index 1505c01f..65962d4f 100644
--- a/docs/eido/README.md
+++ b/docs/eido/README.md
@@ -35,8 +35,8 @@ An eido schema is written using the JSON Schema vocabulary, plus a few additiona
 
 ## How to use eido
 
-- [Use eido to validate data from the command line](cli.md)
-- [Use eido to validate data from Python](demo.md)
+- [Use eido to validate data from the command line](code/cli.md)
+- [Use eido to validate data from Python](code/demo.md)
 - [Write your own schema](writing-a-schema.md)
 
 ---
diff --git a/docs/eido/api_docs.md b/docs/eido/api_docs.md
deleted file mode 100644
index dd47fac1..00000000
--- a/docs/eido/api_docs.md
+++ /dev/null
@@ -1,214 +0,0 @@
-Final targets: EidoValidationError, convert_project, get_available_pep_filters, get_input_files_size, inspect_project, read_schema, validate_config, validate_input_files, validate_project, validate_sample
-<script>
-document.addEventListener('DOMContentLoaded', (event) => {
-  document.querySelectorAll('h3 code').forEach((block) => {
-    hljs.highlightBlock(block);
-  });
-});
-</script>
-
-<style>
-h3 .content { 
-    padding-left: 22px;
-    text-indent: -15px;
- }
-h3 .hljs .content {
-    padding-left: 20px;
-    margin-left: 0px;
-    text-indent: -15px;
-    martin-bottom: 0px;
-}
-h4 .content, table .content, p .content, li .content { margin-left: 30px; }
-h4 .content { 
-    font-style: italic;
-    font-size: 1em;
-    margin-bottom: 0px;
-}
-
-</style>
-
-
-# Package `eido` Documentation
-
-
-Project configuration
-
-## <a name="EidoValidationError"></a> Class `EidoValidationError`
-Object was not validated successfully according to schema.
-
-
-```python
-def __init__(self, message, errors_by_type)
-```
-
-Initialize self.  See help(type(self)) for accurate signature.
-
-
-
-```python
-def validate_project(project, schema)
-```
-
-Validate a project object against a schema
-#### Parameters:
-
-- `project` (`peppy.Project`):  a project object to validate
-- `schema` (`str | dict`):  schema dict to validate against or a path to onefrom the error. Useful when used ith large projects
-
-
-
-
-```python
-def validate_sample(project, sample_name, schema)
-```
-
-Validate the selected sample object against a schema
-#### Parameters:
-
-- `project` (`peppy.Project`):  a project object to validate
-- `sample_name` (`str | int`):  name or index of the sample to validate
-- `schema` (`str | dict`):  schema dict to validate against or a path to one
-
-
-
-
-```python
-def validate_config(project, schema)
-```
-
-Validate the config part of the Project object against a schema
-#### Parameters:
-
-- `project` (`peppy.Project`):  a project object to validate
-- `schema` (`str | dict`):  schema dict to validate against or a path to one
-
-
-
-
-```python
-def read_schema(schema)
-```
-
-Safely read schema from YAML-formatted file.
-
-If the schema imports any other schemas, they will be read recursively.
-#### Parameters:
-
-- `schema` (`str | Mapping`):  path to the schema fileor schema in a dict form
-
-
-#### Returns:
-
-- `list[dict]`:  read schemas
-
-
-#### Raises:
-
-- `TypeError`:  if the schema arg is neither a Mapping nor a file path orif the 'imports' sections in any of the schemas is not a list
-
-
-
-
-```python
-def inspect_project(p, sample_names=None, max_attr=10)
-```
-
-Print inspection info: Project or, if sample_names argument is provided, matched samples
-#### Parameters:
-
-- `p` (`peppy.Project`):  project to inspect
-- `sample_names` (`Iterable[str]`):  list of samples to inspect
-- `max_attr` (`int`):  max number of sample attributes to display
-
-
-
-
-```python
-def get_available_pep_filters()
-```
-
-Get a list of available target formats
-#### Returns:
-
-- `List[str]`:  a list of available formats
-
-
-
-
-```python
-def convert_project(prj, target_format, plugin_kwargs=None)
-```
-
-Convert a `peppy.Project` object to a selected format
-#### Parameters:
-
-- `prj` (`peppy.Project`):  a Project object to convert
-- `plugin_kwargs` (`dict`):  kwargs to pass to the plugin function
-- `target_format` (`str`):  the format to convert the Project object to
-
-
-#### Raises:
-
-- `EidoFilterError`:  if the requested filter is not defined
-
-
-
-
-```python
-def validate_input_files(project, schemas, sample_name=None)
-```
-
-Determine which of the required and optional files are missing.
-
-The names of the attributes that are required and/or deemed as inputs
-are sourced from the schema, more specifically from `required_files`
-and `files` sections in samples section:
-- If any of the required files are missing, this function raises an error.
-- If any of the optional files are missing, the function raises a warning.
-Note, this function also performs Sample object validation with jsonschema.
-#### Parameters:
-
-- `project` (`peppy.Project`):  project that defines the samples to validate
-- `schema` (`str | dict`):  schema dict to validate against or a path to one
-- `sample_name` (`str | int`):  name or index of the sample to validate. If None,validate all samples in the project
-
-
-#### Raises:
-
-- `PathAttrNotFoundError`:  if any required sample attribute is missing
-
-
-
-
-```python
-def get_input_files_size(sample, schema)
-```
-
-Determine which of this Sample's required attributes/files are missing and calculate sizes of the files (inputs).
-
-The names of the attributes that are required and/or deemed as inputs
-are sourced from the schema, more specifically from required_input_attrs
-and input_attrs sections in samples section. Note, this function does
-perform actual Sample object validation with jsonschema.
-#### Parameters:
-
-- `sample` (`peppy.Sample`):  sample to investigate
-- `schema` (`list[dict] | str`):  schema dict to validate against or a path to one
-
-
-#### Returns:
-
-- `dict`:  dictionary with validation data, i.e missing,required_inputs, all_inputs, input_file_size
-
-
-#### Raises:
-
-- `ValidationError`:  if any required sample attribute is missing
-
-
-
-
-
-
-
-*Version Information: `eido` v0.2.2-dev, generated by `lucidoc` v0.4.4*
diff --git a/docs/eido/plugin_api_docs.md b/docs/eido/code/plugin-api-docs.md
similarity index 91%
rename from docs/eido/plugin_api_docs.md
rename to docs/eido/code/plugin-api-docs.md
index 4ec3a733..a166a7e5 100644
--- a/docs/eido/plugin_api_docs.md
+++ b/docs/eido/code/plugin-api-docs.md
@@ -1,4 +1,3 @@
-Final targets: basic_pep_filter, csv_pep_filter, yaml_pep_filter, yaml_samples_pep_filter
 <script>
 document.addEventListener('DOMContentLoaded', (event) => {
   document.querySelectorAll('h3 code').forEach((block) => {
@@ -93,4 +92,4 @@ This filter can save the YAML to file, if kwargs include `path`.
 
 
 
-*Version Information: `eido` v0.2.2-dev, generated by `lucidoc` v0.4.4*
+*Version Information: `eido` v0.2.1, generated by `lucidoc` v0.4.3*
\ No newline at end of file
diff --git a/docs/eido/code/python-api.md b/docs/eido/code/python-api.md
index 492d33da..fac495f0 100644
--- a/docs/eido/code/python-api.md
+++ b/docs/eido/code/python-api.md
@@ -153,63 +153,6 @@ Convert a `peppy.Project` object to a selected format
 
 
 
-```python
-def basic_pep_filter(p, **kwargs) -> Dict[str, str]
-```
-
-Basic PEP filter, that does not convert the Project object.
-
-This filter can save the PEP representation to file, if kwargs include `path`.
-#### Parameters:
-
-- `p` (`peppy.Project`):  a Project to run filter on
-
-
-
-
-```python
-def yaml_pep_filter(p, **kwargs) -> Dict[str, str]
-```
-
-YAML PEP filter, that returns Project object representation.
-
-This filter can save the YAML to file, if kwargs include `path`.
-#### Parameters:
-
-- `p` (`peppy.Project`):  a Project to run filter on
-
-
-
-
-```python
-def csv_pep_filter(p, **kwargs) -> Dict[str, str]
-```
-
-CSV PEP filter, that returns Sample object representations
-
-This filter can save the CSVs to files, if kwargs include
-`sample_table_path` and/or `subsample_table_path`.
-#### Parameters:
-
-- `p` (`peppy.Project`):  a Project to run filter on
-
-
-
-
-```python
-def yaml_samples_pep_filter(p, **kwargs) -> Dict[str, str]
-```
-
-YAML samples PEP filter, that returns only Sample object representations.
-
-This filter can save the YAML to file, if kwargs include `path`.
-#### Parameters:
-
-- `p` (`peppy.Project`):  a Project to run filter on
-
-
-
-
 ```python
 def validate_input_files(project, schemas, sample_name=None)
 ```
diff --git a/docs/geofetch/code/how_to_convert_fastq_from_sra.md b/docs/geofetch/code/howto-sra-to-fastq.md
similarity index 100%
rename from docs/geofetch/code/how_to_convert_fastq_from_sra.md
rename to docs/geofetch/code/howto-sra-to-fastq.md
diff --git a/docs/geofetch/notebooks/how_to_convert_fastq_from_sra.ipynb b/docs/geofetch/notebooks/howto-sra-to-fastq.ipynb
similarity index 100%
rename from docs/geofetch/notebooks/how_to_convert_fastq_from_sra.ipynb
rename to docs/geofetch/notebooks/howto-sra-to-fastq.ipynb
diff --git a/docs/geofetch/sra_convert.md b/docs/geofetch/sra_convert.md
index 14f07250..6e04cf09 100644
--- a/docs/geofetch/sra_convert.md
+++ b/docs/geofetch/sra_convert.md
@@ -9,10 +9,10 @@ The basic advantages over just using prefetch are:
 - it can automatically delete sra data that has been already converted
 - it allows a more flexible specification of locations, using either environment variables or command-line arguments.
 
-This effectively makes it easier to interact with *project-level* management of sra and fastq data using [looper](http://looper.databio.org) and PEP-compatible projects.
+This effectively makes it easier to interact with *project-level* management of sra and fastq data using [looper](../looper/README.md) and PEP-compatible projects.
 
 
 
 ## Tutorial
 
-See the [how-to](how_to_convert_fastq_from_sra.md) for an example of how to use `sraconvert`.
\ No newline at end of file
+See the [how-to SRA to FASTQ](code/howto-sra-to-fastq.md) for an example of how to use `sraconvert`.
\ No newline at end of file
diff --git a/docs/looper/code/python-api.md b/docs/looper/code/python-api.md
index c477862a..aa3e66b5 100644
--- a/docs/looper/code/python-api.md
+++ b/docs/looper/code/python-api.md
@@ -140,6 +140,61 @@ def description(self)
 
 
 
+```python
+def from_dict(cls, pep_dictionary: dict)
+```
+
+Init a peppy project instance from a dictionary representation of an already processed PEP.
+#### Parameters:
+
+- `pep_dictionary` (`Dict[Any]`):  dict,_samples: list | dict, _subsamples: list[list | dict]}
+
+
+
+
+```python
+def from_pandas(cls, samples_df: pandas.core.frame.DataFrame, sub_samples_df: List[pandas.core.frame.DataFrame]=None, config: dict=None)
+```
+
+Init a peppy project instance from a pandas Dataframe
+#### Parameters:
+
+- `samples_df` (``):  in-memory pandas DataFrame object of samples
+- `sub_samples_df` (``):  in-memory list of pandas DataFrame objects of sub-samples
+- `config` (``):  dict of yaml file
+
+
+
+
+```python
+def from_pep_config(cls, cfg: str=None, amendments: Union[str, Iterable[str]]=None, sample_table_index: Union[str, Iterable[str]]=None, subsample_table_index: Union[str, Iterable[str]]=None, defer_samples_creation: bool=False)
+```
+
+Init a peppy project instance from a yaml file
+#### Parameters:
+
+- `cfg` (`str`):  Project config file (YAML) or sample table (CSV/TSV)with one row per sample to constitute project
+- `sample_table_index` (`str | Iterable[str]`):  name of the columns to setthe sample_table index to
+- `subsample_table_index` (`str | Iterable[str]`):  name of the columns to setthe subsample_table index to
+- `amendments` (`str | Iterable[str]`):  names of the amendments to activate
+- `amendments` (`Iterable[str]`):  amendments to use within configuration file
+- `defer_samples_creation` (`bool`):  whether the sample creation should be skipped
+
+
+
+
+```python
+def from_sample_yaml(cls, yaml_file: str)
+```
+
+Init a peppy project instance from a yaml file
+#### Parameters:
+
+- `yaml_file` (`str`):  path to yaml file
+
+
+
+
 ```python
 def get_pipestat_managers(self, sample_name=None, project_level=False)
 ```
diff --git a/docs/looper/derived-columns.md b/docs/looper/derived-columns.md
deleted file mode 100644
index c13713f4..00000000
--- a/docs/looper/derived-columns.md
+++ /dev/null
@@ -1,74 +0,0 @@
-# Derived columns
-
-On your sample sheet, you will need to point to the input file or files for each sample.
-Of course, you could just add a column with the file path, like `/path/to/input/file.fastq.gz`. For example:
-
-A ***bad* example**:
-
-```CSV
-sample_name,library,organism,time,file_path
-pig_0h,RRBS,pig,0,/data/lab/project/pig_0h.fastq
-pig_1h,RRBS,pig,1,/data/lab/project/pig_1h.fastq
-frog_0h,RRBS,frog,0,/data/lab/project/frog_0h.fastq
-frog_1h,RRBS,frog,1,/data/lab/project/frog_1h.fastq
-```
-
-This is common, and it works in a pinch with Looper, but what if the data get moved, or your filesystem changes, or you switch servers or move institutes?
-Will this data still be there in 2 years? Do you want long file paths cluttering your annotation sheet?
-What if you have 2 or 3 input files? Do you want to manually manage these unwieldy absolute paths?
-
-Looper makes it really easy to do better. You can make one or your annotation columns into a flexible *derived column*
-that will be populated based on a source template you specify in the project configuration file.
-What was originally `/long/path/to/sample.fastq.gz` would instead contain just a key, like `source1`.
-Columns that use a key like this are called *derived columns*.
-Here's an example of the same sheet using a derived column (`file_path`):
-
-A ***good* example**:
-```CSV
-sample_name,library,organism,time,file_path
-pig_0h,RRBS,pig,0,source1
-pig_1h,RRBS,pig,1,source1
-frog_0h,RRBS,frog,0,source1
-frog_1h,RRBS,frog,1,source1
-```
-
-For this to succeed, your project config file must specify two things:
-- Which columns are to be derived (in this case, ``file_path``)
-- A `data_sources` section mapping keys to strings that will construct your path, like this:
-    ```yaml
-    derived_columns: [file_path]
-    data_sources:
-      source1: /data/lab/project/{sample_name}.fastq
-      source2: /path/from/collaborator/weirdNamingScheme_{external_id}.fastq
-    ```
-
-That's it! The source string can use other sample attributes (columns) using braces, as in `{sample_name}`.
-The attributes will be automatically populated separately for each sample.
-To take this a step further, you'd get the same result with this config file,
-which substitutes `{sample_name}` for other sample attributes, `{organism}` and `{time}`:
-
-```yaml
-derived_columns: [file_path]
-data_sources:
-  source1: /data/lab/project/{organism}_{time}h.fastq
-  source2: /path/from/collaborator/weirdNamingScheme_{external_id}.fastq
-```
-
-As long as your file naming system is systematic, you can easily deal with any external naming scheme, no problem at all.
-The idea is this: don't put *absolute* paths to files in your annotation sheet.
-Instead, specify a data source and then provide a regex in the config file.
-
-Then if your data change locations (which happens more often than we would like), or you change servers,
-or you want to share or publish the project, you just have to change the config file and not update paths in the annotation sheet.
-This makes the annotation sheet universal across environments, users, publication, etc. The whole project is now portable.
-
-You can specify as many derived columns as you want. An expression including any sample attributes (using `{attribute}`) will be populated for each of those columns.
-
-Think of each sample as belonging to a certain type (for simple experiments, the type will be the same).
-Then define the location of these samples in the project configuration file.
-As a side bonus, you can easily include samples from different locations, and you can also use the same sample annotation sheet on different environments
-(i.e. servers or users) by having multiple project config files (or, better yet, by defining a `subproject` for each environment).
-The only thing you have to change is the project-level expression describing the location, not any sample attributes.
-Plus, you get to eliminate those annoying `long/path/arguments/in/your/sample/annotation/sheet`.
-
-Check out the complete working example in the [`microtest` repository](https://github.com/databio/microtest/tree/master/config).
diff --git a/docs/looper/implied-columns.md b/docs/looper/implied-columns.md
deleted file mode 100644
index 7879956c..00000000
--- a/docs/looper/implied-columns.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# Implied columns
-
-At some point, you may have a situation where you need a single sample attribute (or column)
-to populate several different pipeline arguments with different values.
-In other words, the value of a given attribute may *imply* values for other attributes.
-It would be nice if you didn't have to enumerate all of these secondary, implied attributes,
-and could instead just infer them from the value of the original attribute.
-
-For example, if my `organism` attribute is `human`, this implies a few other secondary attributes
-(which may be project-specific): For one project, I want to set `genome` to `hg38` and `macs_genome_size` to `hs`.
-Of course, I could just define columns called `genome` and `macs_genome_size`, but these would be constant across samples, so it feels inefficient and unwieldy.
-Plus, changing the aligned genome would require changing the sample annotation sheet (every sample, in fact).
-You can certainly do this with `looper`, but a better way is to handle these things at the project level.
-
-As a more elegant alternative, in a project config file `looper` will recognize a section called `implied_columns`.
-Instead of hard-coding `genome` and `macs_genome_size` in the sample annotation sheet,
-you can simply specify that the attribute `organism` *implies* additional attribute-value pairs
-(which may vary by sample based on the value of the `organism` attribute).
-This lets you specify assemblies, genome size, and other similar variables all in your project config file.
-
-To do this, just add an `implied_columns` section to your project_config.yaml file. Example:
-
-```yaml
-implied_columns:
-  organism:
-    human:
-      genome: "hg38"
-      macs_genome_size: "hs"
-    mouse:
-      genome: "mm10"
-      macs_genome_size: "mm"
-```
-
-There are 3 levels in the `implied_columns` hierarchy.
-The first (directly under `implied_columns`; here, `organism`), are primary columns from which new attributes will be inferred.
-The second layer (here, `human` or `mouse`) are possible values your samples may take in the primary column.
-The third layer (`genome` and `macs_genome_size`) are the key-value pair of new, implied columns
-for any samples with the required value for that primary column.
-
-In this example, any samples with organism set to `"human"` will automatically also have attributes for `genome` (`"hg38"`) and for `macs_genome_size` (`"hs"`).
-Any samples with `organism` set to `"mouse"` will have the corresponding values.
-A sample with `organism` set to `"frog"` would lack attributes for `genome` and `macs_genome_size`, since those columns are not implied by `"frog"`.
-
-This system essentially lets you set global, species-level attributes at the project level instead of duplicating
-that information for every sample that belongs to a species.
-Even better, it's generic, so you can do this for any partition of samples (just replace `organism` with whatever you like).
-
-This makes your project more portable and does a better job conceptually with separating sample attributes from project attributes.
-After all, a reference assembly is not a property of a sample, but is part of the broader project context.
diff --git a/docs/looper/sample-annotation-sheet.md b/docs/looper/sample-annotation-sheet.md
index 0c8a3884..d81dc657 100644
--- a/docs/looper/sample-annotation-sheet.md
+++ b/docs/looper/sample-annotation-sheet.md
@@ -45,3 +45,130 @@ sample_name, library, organism, flowcell, lane, BSF_name, data_source
 
 <sup>1</sup> The sample name should contain no whitespace. If it does, an error will be thrown.
 Similarly, `looper` will not allow any duplicate entries under sample_name.
+
+
+# Derived columns
+
+On your sample sheet, you will need to point to the input file or files for each sample.
+Of course, you could just add a column with the file path, like `/path/to/input/file.fastq.gz`. For example:
+
+A ***bad* example**:
+
+```CSV
+sample_name,library,organism,time,file_path
+pig_0h,RRBS,pig,0,/data/lab/project/pig_0h.fastq
+pig_1h,RRBS,pig,1,/data/lab/project/pig_1h.fastq
+frog_0h,RRBS,frog,0,/data/lab/project/frog_0h.fastq
+frog_1h,RRBS,frog,1,/data/lab/project/frog_1h.fastq
+```
+
+This is common, and it works in a pinch with Looper, but what if the data get moved, or your filesystem changes, or you switch servers or move institutes?
+Will this data still be there in 2 years? Do you want long file paths cluttering your annotation sheet?
+What if you have 2 or 3 input files? Do you want to manually manage these unwieldy absolute paths?
+
+Looper makes it really easy to do better. You can make one or your annotation columns into a flexible *derived column*
+that will be populated based on a source template you specify in the project configuration file.
+What was originally `/long/path/to/sample.fastq.gz` would instead contain just a key, like `source1`.
+Columns that use a key like this are called *derived columns*.
+Here's an example of the same sheet using a derived column (`file_path`):
+
+A ***good* example**:
+```CSV
+sample_name,library,organism,time,file_path
+pig_0h,RRBS,pig,0,source1
+pig_1h,RRBS,pig,1,source1
+frog_0h,RRBS,frog,0,source1
+frog_1h,RRBS,frog,1,source1
+```
+
+For this to succeed, your project config file must specify two things:
+- Which columns are to be derived (in this case, ``file_path``)
+- A `data_sources` section mapping keys to strings that will construct your path, like this:
+    ```yaml
+    derived_columns: [file_path]
+    data_sources:
+      source1: /data/lab/project/{sample_name}.fastq
+      source2: /path/from/collaborator/weirdNamingScheme_{external_id}.fastq
+    ```
+
+That's it! The source string can use other sample attributes (columns) using braces, as in `{sample_name}`.
+The attributes will be automatically populated separately for each sample.
+To take this a step further, you'd get the same result with this config file,
+which substitutes `{sample_name}` for other sample attributes, `{organism}` and `{time}`:
+
+```yaml
+derived_columns: [file_path]
+data_sources:
+  source1: /data/lab/project/{organism}_{time}h.fastq
+  source2: /path/from/collaborator/weirdNamingScheme_{external_id}.fastq
+```
+
+As long as your file naming system is systematic, you can easily deal with any external naming scheme, no problem at all.
+The idea is this: don't put *absolute* paths to files in your annotation sheet.
+Instead, specify a data source and then provide a regex in the config file.
+
+Then if your data change locations (which happens more often than we would like), or you change servers,
+or you want to share or publish the project, you just have to change the config file and not update paths in the annotation sheet.
+This makes the annotation sheet universal across environments, users, publication, etc. The whole project is now portable.
+
+You can specify as many derived columns as you want. An expression including any sample attributes (using `{attribute}`) will be populated for each of those columns.
+
+Think of each sample as belonging to a certain type (for simple experiments, the type will be the same).
+Then define the location of these samples in the project configuration file.
+As a side bonus, you can easily include samples from different locations, and you can also use the same sample annotation sheet on different environments
+(i.e. servers or users) by having multiple project config files (or, better yet, by defining a `subproject` for each environment).
+The only thing you have to change is the project-level expression describing the location, not any sample attributes.
+Plus, you get to eliminate those annoying `long/path/arguments/in/your/sample/annotation/sheet`.
+
+Check out the complete working example in the [`microtest` repository](https://github.com/databio/microtest/tree/master/config).
+
+
+# Implied columns
+
+At some point, you may have a situation where you need a single sample attribute (or column)
+to populate several different pipeline arguments with different values.
+In other words, the value of a given attribute may *imply* values for other attributes.
+It would be nice if you didn't have to enumerate all of these secondary, implied attributes,
+and could instead just infer them from the value of the original attribute.
+
+For example, if my `organism` attribute is `human`, this implies a few other secondary attributes
+(which may be project-specific): For one project, I want to set `genome` to `hg38` and `macs_genome_size` to `hs`.
+Of course, I could just define columns called `genome` and `macs_genome_size`, but these would be constant across samples, so it feels inefficient and unwieldy.
+Plus, changing the aligned genome would require changing the sample annotation sheet (every sample, in fact).
+You can certainly do this with `looper`, but a better way is to handle these things at the project level.
+
+As a more elegant alternative, in a project config file `looper` will recognize a section called `implied_columns`.
+Instead of hard-coding `genome` and `macs_genome_size` in the sample annotation sheet,
+you can simply specify that the attribute `organism` *implies* additional attribute-value pairs
+(which may vary by sample based on the value of the `organism` attribute).
+This lets you specify assemblies, genome size, and other similar variables all in your project config file.
+
+To do this, just add an `implied_columns` section to your project_config.yaml file. Example:
+
+```yaml
+implied_columns:
+  organism:
+    human:
+      genome: "hg38"
+      macs_genome_size: "hs"
+    mouse:
+      genome: "mm10"
+      macs_genome_size: "mm"
+```
+
+There are 3 levels in the `implied_columns` hierarchy.
+The first (directly under `implied_columns`; here, `organism`), are primary columns from which new attributes will be inferred.
+The second layer (here, `human` or `mouse`) are possible values your samples may take in the primary column.
+The third layer (`genome` and `macs_genome_size`) are the key-value pair of new, implied columns
+for any samples with the required value for that primary column.
+
+In this example, any samples with organism set to `"human"` will automatically also have attributes for `genome` (`"hg38"`) and for `macs_genome_size` (`"hs"`).
+Any samples with `organism` set to `"mouse"` will have the corresponding values.
+A sample with `organism` set to `"frog"` would lack attributes for `genome` and `macs_genome_size`, since those columns are not implied by `"frog"`.
+
+This system essentially lets you set global, species-level attributes at the project level instead of duplicating
+that information for every sample that belongs to a species.
+Even better, it's generic, so you can do this for any partition of samples (just replace `organism` with whatever you like).
+
+This makes your project more portable and does a better job conceptually with separating sample attributes from project attributes.
+After all, a reference assembly is not a property of a sample, but is part of the broader project context.
diff --git a/docs/peppy/code/python-api.md b/docs/peppy/code/python-api.md
index 7c3f7dc5..a8376e10 100644
--- a/docs/peppy/code/python-api.md
+++ b/docs/peppy/code/python-api.md
@@ -234,19 +234,19 @@ def description(self)
 
 
 ```python
-def from_dict(self, pep_dictionary: dict) -> 'Project'
+def from_dict(cls, pep_dictionary: dict)
 ```
 
 Init a peppy project instance from a dictionary representation of an already processed PEP.
 #### Parameters:
 
-- `pep_dictionary` (`dict`):  in-memory dict representation of pep.
+- `pep_dictionary` (`Dict[Any]`):  dict,_samples: list | dict, _subsamples: list[list | dict]}
 
 
 
 
 ```python
-def from_pandas(self, samples_df: pandas.core.frame.DataFrame, sub_samples_df: List[pandas.core.frame.DataFrame]=None, config: dict=None) -> 'Project'
+def from_pandas(cls, samples_df: pandas.core.frame.DataFrame, sub_samples_df: List[pandas.core.frame.DataFrame]=None, config: dict=None)
 ```
 
 Init a peppy project instance from a pandas Dataframe
@@ -259,6 +259,35 @@ Init a peppy project instance from a pandas Dataframe
 
 
 
+```python
+def from_pep_config(cls, cfg: str=None, amendments: Union[str, Iterable[str]]=None, sample_table_index: Union[str, Iterable[str]]=None, subsample_table_index: Union[str, Iterable[str]]=None, defer_samples_creation: bool=False)
+```
+
+Init a peppy project instance from a yaml file
+#### Parameters:
+
+- `cfg` (`str`):  Project config file (YAML) or sample table (CSV/TSV)with one row per sample to constitute project
+- `sample_table_index` (`str | Iterable[str]`):  name of the columns to setthe sample_table index to
+- `subsample_table_index` (`str | Iterable[str]`):  name of the columns to setthe subsample_table index to
+- `amendments` (`str | Iterable[str]`):  names of the amendments to activate
+- `amendments` (`Iterable[str]`):  amendments to use within configuration file
+- `defer_samples_creation` (`bool`):  whether the sample creation should be skipped
+
+
+
+
+```python
+def from_sample_yaml(cls, yaml_file: str)
+```
+
+Init a peppy project instance from a yaml file
+#### Parameters:
+
+- `yaml_file` (`str`):  path to yaml file
+
+
+
+
 ```python
 def get_description(self)
 ```
@@ -533,7 +562,6 @@ def to_dict(self, extended: bool=False, orient: Literal['dict', 'list', 'series'
 Convert the Project object to a dictionary.
 #### Parameters:
 
-- `expand` (`bool`):  whether to expand the paths
 - `extended` (`bool`):  whether to produce complete project dict (used to reinit the project)
 - `orient` (`Literal`):  orientation of the returned df
 
@@ -561,6 +589,12 @@ Initialize self.  See help(type(self)) for accurate signature.
 
 
 
+```python
+def attributes(self)
+```
+
+
+
 ```python
 def copy(self)
 ```
@@ -661,4 +695,4 @@ Initialize self.  See help(type(self)) for accurate signature.
 
 
 
-*Version Information: `peppy` v0.40.0a4, generated by `lucidoc` v0.4.3*
\ No newline at end of file
+*Version Information: `peppy` v0.40.0, generated by `lucidoc` v0.4.3*
\ No newline at end of file
diff --git a/docs/peppy/models.md b/docs/peppy/models.md
index 5f4628d5..bc053ca0 100644
--- a/docs/peppy/models.md
+++ b/docs/peppy/models.md
@@ -26,7 +26,7 @@ and used.
 
 ## Extending sample objects
 
-By default we use *generic* models (see [API docs](autodoc_build/peppy.md) for more) that can be used in many contexts
+By default we use *generic* models (see [Peppy API docs](code/python-api.md) for more) that can be used in many contexts
 via Python import, or by object serialization and deserialization via YAML.
 
 Since these models provide useful methods to store, update, and read attributes in the objects created from them
diff --git a/docs/pipestat/code/python-api.md b/docs/pipestat/code/python-api.md
index cb2abc32..9dbdab18 100644
--- a/docs/pipestat/code/python-api.md
+++ b/docs/pipestat/code/python-api.md
@@ -668,7 +668,7 @@ Pipestat standardizes reporting of pipeline results and pipeline status manageme
 
 
 ```python
-def __init__(self, project_name: Union[str, NoneType]=None, record_identifier: Union[str, NoneType]=None, schema_path: Union[str, NoneType]=None, results_file_path: Union[str, NoneType]=None, database_only: Union[bool, NoneType]=True, config_file: Union[str, NoneType]=None, config_dict: Union[dict, NoneType]=None, flag_file_dir: Union[str, NoneType]=None, show_db_logs: bool=False, pipeline_type: Union[str, NoneType]=None, pipeline_name: Union[str, NoneType]='default_pipeline_name', result_formatter: staticmethod=<function default_formatter at 0x7fd2d859a040>, multi_pipelines: bool=False, output_dir: Union[str, NoneType]=None)
+def __init__(self, project_name: Union[str, NoneType]=None, record_identifier: Union[str, NoneType]=None, schema_path: Union[str, NoneType]=None, results_file_path: Union[str, NoneType]=None, database_only: Union[bool, NoneType]=True, config_file: Union[str, NoneType]=None, config_dict: Union[dict, NoneType]=None, flag_file_dir: Union[str, NoneType]=None, show_db_logs: bool=False, pipeline_type: Union[str, NoneType]=None, pipeline_name: Union[str, NoneType]='default_pipeline_name', result_formatter: staticmethod=<function default_formatter at 0x7f2b10515b80>, multi_pipelines: bool=False, output_dir: Union[str, NoneType]=None)
 ```
 
 Initialize the PipestatManager object
@@ -1023,4 +1023,4 @@ def table(self, *args, **kwargs)
 
 
 
-*Version Information: `pipestat` v0.6.0a8, generated by `lucidoc` v0.4.3*
\ No newline at end of file
+*Version Information: `pipestat` v0.8.0, generated by `lucidoc` v0.4.3*
\ No newline at end of file
diff --git a/docs/pipestat/code/python_api.md b/docs/pipestat/code/python_api.md
index b116ad50..28a21553 100644
--- a/docs/pipestat/code/python_api.md
+++ b/docs/pipestat/code/python_api.md
@@ -23,10 +23,6 @@ The changes reported using the `report` method of `PipestatManger` will be secur
 2. a **PostgreSQL database** (pass a path to the pipestat config to the constructor)
 This option gives the user the possibility to use a fully fledged database to back `PipestatManager`. 
 
-Note: Beginning with v0.6.0 if you wish to use the database backend, you must install the optional dependencies via: 
-```bash
-pip install pipestat['dbbackend']
-```
 
 ## Initializing a pipestat session
 
diff --git a/docs/pypiper/README.md b/docs/pypiper/README.md
index 339ef145..6ec7517b 100644
--- a/docs/pypiper/README.md
+++ b/docs/pypiper/README.md
@@ -21,7 +21,7 @@ With Pypiper, **simplicity is paramount**. Prerequisites are few: base python an
 2. easy to modify, so they are simple to update and maintain;
 3. simple to understand for an outsider, so they can be approached by others.
 
-These traits make pypiper ideally suited for **pipelines under active development**. Read more about the [pypiper philosophy](philosophy).
+These traits make pypiper ideally suited for **pipelines under active development**. Read more about the [pypiper philosophy](philosophy.md).
 
 ## Installing
 
diff --git a/docs/pypiper/code/python-api.md b/docs/pypiper/code/python-api.md
index 977f99a2..d3d7ba0b 100644
--- a/docs/pypiper/code/python-api.md
+++ b/docs/pypiper/code/python-api.md
@@ -1744,7 +1744,7 @@ undergo is trimming of any space characters from each end.
 
 
 ```python
-def check_all_commands(cmds, get_bad_result=<function <lambda> at 0x7fd2d57840d0>, handle=None)
+def check_all_commands(cmds, get_bad_result=<function <lambda> at 0x7f2b0d6c50d0>, handle=None)
 ```
 
 Determine whether all commands are callable
@@ -1768,7 +1768,7 @@ Determine whether all commands are callable
 
 
 ```python
-def determine_uncallable(commands, transformations=((<function <lambda> at 0x7fd2d57841f0>, <function <lambda> at 0x7fd2d5784280>),), accumulate=False)
+def determine_uncallable(commands, transformations=((<function <lambda> at 0x7f2b0d6c51f0>, <function <lambda> at 0x7f2b0d6c5280>),), accumulate=False)
 ```
 
 Determine which commands are not callable.
diff --git a/docs/pypiper/faq.md b/docs/pypiper/faq.md
index 94105ac6..67eaeb7f 100644
--- a/docs/pypiper/faq.md
+++ b/docs/pypiper/faq.md
@@ -2,11 +2,11 @@
 
 ## How can I run my pipeline on more than 1 sample?
 
-Pypiper only handles individual-sample pipelines. To run it on multiple samples, write a loop, or use [looper](http://looper.readthedocs.io/). Dividing multi-sample handling from individual sample handling is a conceptual advantage that allows us to write a nice, universal, generic sample-handler that you only have to learn once.
+Pypiper only handles individual-sample pipelines. To run it on multiple samples, write a loop, or use [looper](../looper/README.md). Dividing multi-sample handling from individual sample handling is a conceptual advantage that allows us to write a nice, universal, generic sample-handler that you only have to learn once.
 
 ## What cluster resources can pypiper use?
 
-Pypiper is compute-agnostic. You run it wherever you want. If you want a nice way to submit pipelines for samples any cluster manager, check out [looper](http://looper.readthedocs.io/), which can run your pipeline on any compute infrastructure using the [divvy python package](http://code.databio.org/divvy).
+Pypiper is compute-agnostic. You run it wherever you want. If you want a nice way to submit pipelines for samples any cluster manager, check out [looper](../looper/README.md), which can run your pipeline on any compute infrastructure using the [divvy python package](http://code.databio.org/divvy).
 
 ## What does it mean for a sample to be in the "waiting" state?
 
@@ -18,7 +18,7 @@ The "elapsed" time is referring to the amount of time since the preceding timest
 
 ## How should I run a QC step to check results of one of my commands?
 
-Usually, you only want to run a QC step if the result was created in the same pipeline run. There's no need to re-run that step if you have to restart the pipeline due to an error later on. If you use `run()` for these steps, then they'll need to run each time the pipeline runs. Instead, this is exactly why we created [the follow argument](../advanced-run-method/#the-follow-argument) This option lets you couple a QC step to a `run()` call, so it only gets excecuted when it is required.
+Usually, you only want to run a QC step if the result was created in the same pipeline run. There's no need to re-run that step if you have to restart the pipeline due to an error later on. If you use `run()` for these steps, then they'll need to run each time the pipeline runs. Instead, this is exactly why we created [the follow argument](advanced-run-method.md#the-follow-argument) This option lets you couple a QC step to a `run()` call, so it only gets excecuted when it is required.
 
 ## How do I solve installation errors involving `psutil` and/or a compiler like `gcc` or `clang`?
 
diff --git a/docs/pypiper/ngstk_intro.md b/docs/pypiper/ngstk_intro.md
index 36f11f0e..de22e200 100644
--- a/docs/pypiper/ngstk_intro.md
+++ b/docs/pypiper/ngstk_intro.md
@@ -19,4 +19,4 @@ cmd = ngstk.index_bam("sample.bam")
 pm.run(cmd, target="sample.bam")
 ```
 
-A complete list of functions is in the [API](../autodoc_build/pypiper) or in the [source code for NGSTk](https://github.com/databio/pypiper/blob/master/pypiper/ngstk.py).
+A complete list of functions is in the [API](code/ngstk.md) or in the [source code for NGSTk](https://github.com/databio/pypiper/blob/master/pypiper/ngstk.py).
diff --git a/docs/spec/howto-geofetch.md b/docs/spec/howto-geofetch.md
index 14030b3f..6670c584 100644
--- a/docs/spec/howto-geofetch.md
+++ b/docs/spec/howto-geofetch.md
@@ -6,6 +6,6 @@ title: "Create a PEP from GEO or SRA"
 
 `geofetch` is a command-line utility that converts GEO or SRA accessions into PEP projects. You provide an accession (or a spreadsheet with a list of accessions), and `geofetch` with produce the PEP (both project config and sample annotation). `geofetch` can also download the data from SRA, so your project will be ready for direct input into any PEP-compatible tool.
 
-For more information, see [`geofetch` user documentation and vignettes](/geofetch)
+For more information, see [`geofetch` user documentation and vignettes](../geofetch/README.md)
 
 
diff --git a/docs/spec/howto-multi-value-attributes.md b/docs/spec/howto-multi-value-attributes.md
index 647f886b..39dc42e2 100644
--- a/docs/spec/howto-multi-value-attributes.md
+++ b/docs/spec/howto-multi-value-attributes.md
@@ -99,8 +99,6 @@ Now, this is the `sample_table`, but the `sample_name` column is not unique -- t
 
 ## Further thoughts
 
-- You can find more examples of multi-valued attributes in the examples at [PEP in practice](pep_in_practice.md).
-
 - There are pros and cons to each of these approaches. Representing a single sample with multiple rows in the sample table can cause conceptual and analytical challenges. There is value in the simplicity of being able to see each row as a separate sample, which is preserved in the subsample table approach. However, this leads to the requirement of an additional file to represent samples, which can be problematic in other settings. One advantage of PEP is that either approach can be used, so you can use the approach that fits your situation best.
 
 - Subsample tables are intended to handle multiple values *of the same type*. To handle different *classes* of input files, like read1 and read2, these are *not* the same type, and are therefore *not* put into a subsample table. Instead, these should be handled as different columns in the main sample annotation sheet (and therefore different arguments to the pipeline). It is possible that you will want to have read1 and read2, and then each of these could have multiple inputs, which would then be placed in the subsample table.
diff --git a/docs/spec/peppy.md b/docs/spec/peppy.md
index 79486511..8c3c3929 100644
--- a/docs/spec/peppy.md
+++ b/docs/spec/peppy.md
@@ -4,9 +4,8 @@
 
 ### Code and documentation
 
-* [User documentation and vignettes](/peppy)
-* [peppy API](http://peppy.databio.org/en/latest/autodoc_build/peppy/)
-* [Source code at Github](https://github.com/pepkit/peppy)
+* [User documentation and vignettes](../peppy/README.md)
+* [Source code at GitHub](https://github.com/pepkit/peppy)
 
 ### Quick start 
 
diff --git a/docs/spec/rationale.md b/docs/spec/rationale.md
index 29123a7a..60c12512 100644
--- a/docs/spec/rationale.md
+++ b/docs/spec/rationale.md
@@ -23,7 +23,7 @@ PEP makes it easy to:
 5. analyze data in both R *and* Python
 
 
-This web page outlines the PEP specification. Once you have a PEP, you will be able to process that metadata using tools in *pepkit*. You can find tools to use at [PEP in practice](pep_in_practice.md).
+This web page outlines the PEP specification. Once you have a PEP, you will be able to process that metadata using tools in *pepkit*. You can find tools to use at [PEP statistics](../statistics.md).
 
 # User stories
 
diff --git a/mkdocs.yml b/mkdocs.yml
index 1c7306c2..ab92e67a 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -45,7 +45,7 @@ markdown_extensions:
       custom_fences:
         - name: mermaid
           class: mermaid
-          format: !!python/name:pymdownx.superfences.fence_code_format
+          format: "!!python/name:pymdownx.superfences.fence_code_format"
 
 extra_css:
   - stylesheets/extra.css
@@ -99,7 +99,7 @@ nav:
       - How to cite: citations.md
       - Example schemas: eido/example-schemas.md
       - Eido Python API: eido/code/python-api.md
-      - Built-in filters API: eido/plugin_api_docs.md
+      - Built-in filters API: eido/code/plugin-api-docs.md
       - Support: https://github.com/pepkit/eido/issues
       - Contributing: eido/contributing.md
       - Changelog: eido/changelog.md
@@ -133,6 +133,7 @@ nav:
         - Hello world: looper/code/hello-world.md
     - How-to guides:
         - Defining a project: looper/defining-a-project.md
+        - Details of a project: looper/sample-annotation-sheet.md
         - Running a pipeline: looper/running-a-pipeline.md
         - Initializing a repository: looper/initialize.md
         - Using pipestat: looper/pipestat.md
@@ -162,6 +163,7 @@ nav:
         - Concentric templates: looper/concentric-templates.md
         - Pre-submission hooks system: looper/pre-submission-hooks.md
         - Looper variable namespaces: looper/variable-namespaces.md
+        - Advanced features: looper/advanced.md
         - Usage: looper/usage.md
         - Configuration files: looper/config-files.md
         - API: looper/code/python-api.md
@@ -204,6 +206,7 @@ nav:
       - How to use imply sample modifier: peppy/code/feature2_imply.md
       - How to validate a PEP: peppy/validating.md
     - Reference:
+      - Project models: peppy/models.md
       - How to cite: citations.md
       - API: peppy/code/python-api.md
       - Support: peppy/support.md
@@ -259,14 +262,32 @@ nav:
   - How to cite: citations.md
   - Stats: statistics.md
 
-lucidoc:
-  peppy: peppy/code/python-api.md
-  looper: looper/code/python-api.md
-  pipestat: pipestat/code/python-api.md
-  pypiper: pypiper/code/python-api.md
-  ngstk: pypiper/code/ngstk.md
-  eido: eido/code/python-api.md
-  geofetch: geofetch/code/python-api.md
+lucidoc_kwargs:
+  - pkg: peppy
+    outfile: docs/peppy/code/python-api.md
+  - pkg: looper
+    outfile: docs/looper/code/python-api.md
+  - pkg: pipestat
+    outfile: docs/pipestat/code/python-api.md
+  - pkg: pypiper
+    outfile: docs/pypiper/code/python-api.md
+  - pkg: geofetch
+    outfile: docs/geofetch/code/python-api.md
+  - pkg: eido
+    outfile: docs/eido/code/python-api.md
+    blacklist: 
+      - basic_pep_filter
+      - yaml_pep_filter
+      - csv_pep_filter
+      - yaml_samples_pep_filter
+  - outfile: docs/eido/code/plugin-api-docs.md
+    pkg: eido
+    whitelist: 
+      - basic_pep_filter
+      - yaml_pep_filter
+      - csv_pep_filter
+      - yaml_samples_pep_filter
+
 
 jupyter:
   - in: eido/notebooks
diff --git a/update_python_autodocs.py b/update_python_autodocs.py
index 1f2f8b93..e504dab0 100644
--- a/update_python_autodocs.py
+++ b/update_python_autodocs.py
@@ -10,17 +10,18 @@
 	cfg = yaml.safe_load(stream)
 
 # Process auto-documented Python code
-if "lucidoc" in cfg:
-	for pkg, dest in cfg["lucidoc"].items():
-		print(f"Documenting '{pkg}' at {dest}")
-		lucidoc.run_lucidoc(pkg, "rst", outfile=f"docs/{dest}")
+if "lucidoc_kwargs" in cfg:
+	for bundle in cfg["lucidoc_kwargs"]:
+		print(f"Documenting kwargs '{bundle['pkg']}' at {bundle['outfile']}")
+		lucidoc.run_lucidoc(parse_style="rst", **bundle)
+
 
 import glob
 import nbconvert
 import os
 from pathlib import Path
 
-# Render Juptyer notebooks to markdown
+# # Render Juptyer notebooks to markdown
 if "jupyter" in cfg:
 	for item in cfg["jupyter"]:
 		files = glob.glob(f"docs/{item['in']}/*.ipynb")