# `Lightning.Collaboration.Instance`
[🔗](https://github.com/OpenFn/lightning/blob/main/lib/lightning/collaboration/instance.ex#L1)

Names the three pieces of collaboration infrastructure that a single
`Lightning.Collaboration.Supervisor` owns: its `Registry`, its
`DynamicSupervisor`, and its `:pg` scope.

A plain value (no process), threaded from the public API down into child
specs so the whole tree can be addressed under a chosen base name. Production
uses `default/0`, which pins the three names to the application-wide
singletons started in `application.ex`. Tests can `derive/1` a fresh, isolated
set from a unique base, letting independent supervisor instances coexist.

# `t`

```elixir
@type t() :: %Lightning.Collaboration.Instance{
  dynamic_supervisor: atom(),
  pg_scope: atom(),
  registry: atom()
}
```

# `default`

```elixir
@spec default() :: t()
```

The production instance: the application-wide singletons.

These are the literal names started by the collaboration supervision tree in
`application.ex`, so every defaulted public call resolves to the same global
infrastructure it always has.

# `derive`

```elixir
@spec derive(atom()) :: t()
```

Derive an instance from a base name.

Passing `Lightning.Collaboration.Supervisor` (the production base) yields the
exact `default/0` names. Any other base produces a distinct, isolated set,
which is how tests run independent supervisor instances side by side.

---

*Consult [api-reference.md](api-reference.md) for complete listing*