---
name: characterize-analog-block
description: Analyze, plan, and review backend-independent analog-block behavior and characterization through OpenADA semantic intents. Use for qualitative schematic or topology reasoning, transient-phase and scaling analysis, device-sizing tradeoffs, defining a characterization matrix for an amplifier, regulator, comparator, reference, oscillator, data converter, or other analog block, choosing the next justified analysis, coordinating specialist workflows, or separating simulation evidence from derived simulation results, specification results, and signoff.
---

# Characterize an Analog Block

Act as the characterization coordinator. Turn the application and specifications
into the smallest justified sequence of OpenADA intents, then delegate focused
reviews to the other engineering skills. Use `$openada:openada` for capability discovery,
invocation, and result interpretation. Keep native design data, testbenches, PDKs,
models, and artifacts authoritative.

## Preserve the contract ladder

Keep these conclusions separate at every step:

| Layer | Exact semantic boundary | Strongest allowed conclusion |
|---|---|---|
| Analysis evidence | `openada.operation/circuit.simulate/v1alpha2` with `openada.assertion/simulation.evidence.valid/v1alpha1` | The requested OP, DC, AC, or transient analysis produced valid evidence, or conclusively did not converge |
| Series extraction | `openada.operation/result.series.extract/v1alpha1` with `openada.assertion/series.extraction.valid/v1alpha1` | Exact native vectors were bound to a canonical real series with verified artifact lineage |
| Scalar simulation result | `openada.operation/result.measure/v1alpha2` with `openada.assertion/measurement.valid/v1alpha1` | The declared metric was validly extracted from identified source evidence |
| Spectral simulation result | `openada.operation/result.spectral.measure/v1alpha1` with `openada.assertion/spectral.measurement.valid/v1alpha1` | One declared coherent SNR, SINAD, THD, or SFDR ratio was validly derived |
| AC transfer simulation result | `openada.operation/result.transfer.measure/v1alpha2` with `openada.assertion/transfer.measurement.valid/v1alpha1` | One declared gain, driving-point impedance, bandwidth, unity-frequency, or negative-feedback phase-margin scalar was validly derived, over single-ended or differential operands |
| Specification | `openada.operation/specification.evaluate/v1alpha1` with `openada.assertion/specification.satisfied/v1alpha1` | The declared simulation result satisfies or violates the explicit limit under its recorded conditions |
| Signoff | Outside these assertions | Only a separately qualified flow and accountable reviewer may make a signoff claim |

Never promote a lower layer into a higher one. In particular, simulation
`engineering.status: pass` is not a performance pass, and simulation
`engineering.status: fail` is the profile's defined solver failure rather than
a failed design specification.

## Freeze the design context

Create or update a compact context ledger before selecting analyses:

- **Decision:** application class, block role, design phase, topology, loop or
  sampled-data structure, and the immediate engineering question.
- **Technology:** exact PDK/model identity, process or device family, supply and
  body domains, temperature range, and pre-layout or extracted representation.
- **Conditions:** stimulus, source impedance, common mode, load, clocking,
  startup state, corner, and any enabled modes or paths.
- **Specifications:** metric, limit or interval, units, condition, priority,
  tolerance, and source of authority. Keep goals distinct from approved limits.
- **Evidence:** target and configuration identities, prior request/result IDs,
  artifact hashes, simulation-result definitions, and known provenance gaps.
- **Unknowns:** assumptions whose resolution could change the testbench,
  analysis, simulation result, or conclusion.

Do not fill missing values with conventional numbers or substitute collateral.
Ask one narrow blocking question when multiple authoritative choices remain.

## Resolve the engineering question before selecting a tool

Read [references/qualitative-reasoning.md](references/qualitative-reasoning.md)
when the question depends on a schematic, switched phases, parameter scaling,
or a device-sizing tradeoff. Use its topology, interval, dependency, and
limiting-case checks to produce one explicit qualitative claim before planning
an analysis.

Classify the claim as one of:

- **source-derived:** follows from the supplied topology, stated assumptions,
  and symbolic device relationships;
- **evidence-testable:** an authoritative target, models, conditions, and a
  supported OpenADA operation can test the same claim;
- **not evaluable:** missing topology, state, model, condition, or semantic
  capability could change the conclusion.

Do not create a netlist, choose device parameters, or invoke a simulator only
to make a qualitative question executable. If the claim is source-derived but
not evidence-testable, answer at that level and identify the missing evidence
boundary. Do not describe algebra, visual inspection, or a hypothetical
testbench as OpenADA evidence.

## Inspect capabilities before planning execution

Inspect the selected driver's complete operation, assertion, and feature IDs.
For circuit simulation, require the exact advertised analysis feature:

- `openada.feature/simulation.analysis.op/v1alpha1`
- `openada.feature/simulation.analysis.dc/v1alpha1`
- `openada.feature/simulation.analysis.ac/v1alpha1`
- `openada.feature/simulation.analysis.tran/v1alpha1`

Run `openada capabilities`, then use `openada profile show OPERATION_PROFILE_ID`
to inspect the installed parameter schema before constructing result-operation
or specification requests. Use semantic metric names in the characterization
plan, but do not invent result-operation parameter names, backend expressions,
or feature IDs that the installed profile does not define.

If an operation, feature, locator, or transport is unavailable, mark that row
**not evaluated — capability unavailable**. Do not bypass OpenADA with a native
command and then describe the result as contract evidence. A native executable
being installed does not itself make a semantic capability available.

## Build the characterization matrix

Read [references/application-recipes.md](references/application-recipes.md)
after identifying the application class. Adapt a recipe to the actual circuit;
do not force an unfamiliar block into the nearest label.
Then read [references/intent-routing.md](references/intent-routing.md) and map
only rows whose required primitives are actually implemented.

For every proposed metric, record:

| Field | Required content |
|---|---|
| Question | The design decision this metric informs |
| Testbench | Exact authoritative target and mode |
| Conditions | Supply, stimulus, load, clock, corner, and temperature |
| Analysis intent | One supported `circuit.simulate` analysis feature |
| Simulation result | Semantic metric and source signals, units, interval, and method |
| Specification | Explicit bound and condition, or `not supplied` |
| Dependencies | Earlier gate or specialist skill that must complete first |
| State | planned, pass, fail, unknown, unavailable, or not evaluated at the appropriate layer |

Compile each row into an immutable intent ledger before execution:

| Ledger field | Required content |
|---|---|
| Row identity | Stable characterization-row ID and immediate engineering question |
| Semantic request | Exact operation, assertion, required feature, target, configuration, parameters, and evidence destination |
| Prerequisites | Authoritative choices and prior row/result identities required before dispatch |
| Evidence binding | Request ID, result ID, native artifact path/hash, canonical series hash, and operating conditions as each becomes available |
| Layer status | Separate analysis, extraction, simulation-result, and specification state; never one blended pass |
| Blocker | One missing authority or capability and the smallest action that resolves it |

Do not rewrite an executed row in place. If a target, model, condition, method,
or limit changes, append a new row revision and preserve comparability.

Order the matrix by dependency, not by convenience:

1. Prove target, configuration, and baseline identity.
2. Run nominal OP evidence first and use a supported result operation to derive
   the simulated bias/headroom facts needed by the topology.
3. Run DC sweeps needed to establish range, transfer, or regulation behavior.
4. Run application-specific AC or transient analyses only after their gates are
   meaningful.
5. Expand into specialist reviews and then PVT/statistical coverage only after
   nominal behavior is plausible.

Invoke one primary assertion per operation. Use fresh evidence destinations and
preserve lineage from analysis artifacts to simulation results and
specifications. Retain the passing extraction envelope beside downstream
results: the extraction assertion verifies the native binding, while the
immutable result-operation profiles continue to label embedded native lineage
as `unverified`.

## Execute one ready intent

Select the first dependency-ready ledger row, not the easiest metric. Execute
only its next unproven layer:

```text
circuit.simulate
  -> result.series.extract when a native vector is needed
  -> result.measure, result.spectral.measure, or result.transfer.measure
  -> specification.evaluate only when an authoritative limit exists
```

**Preferred: a typed experiment against a DUT artifact.** When the block is a
published Simra DUT schematic (no sources, no ground instance, artifact
`lifecycle.state: "simulation_candidate"`), describe the whole characterization
step as one `simra.experiment/v1` JSON — DUT bundle digests and port
connections; fixture elements with kinds exactly `vdc`, `idc`, `vpulse`,
`ipulse`, `vsin`, `isin`, `vpwl`, `ipwl`, `resistor`, `capacitor`,
`inductor`; analyses with ids; observations; exact typed measurement
requests; and `"conditions": {"pdk": {"id": "<pdk-id>", "corner":
"<corner>"}}` — and run the full
chain in one command:

```bash
openada experiment run experiment.json --pdk <pdk-id> --output-dir <evidence-dir>
```

It validates the whole document before anything simulates (every refusal names
the exact JSON path — fix the named field, never work around it), then
simulates each analysis, extracts every observation, runs every measurement,
and retains the complete typed chain including the request preimages.
Propagation delay is a `derivations` entry subtracting two same-analysis
crossings; there is no primitive delay kind.

**Legacy: a drawn testbench artifact.** `circuit.simulate` still takes the
block in whatever form it arrived. Hand it a published Simra testbench
artifact and it verifies the digests, splits a multi-analysis testbench into
one deck per declared analysis and binds an installed PDK; hand it a bare deck
and it does the same without the split:

```bash
openada simulate <path>/schematic.artifact.json \
  --pdk <pdk-id> --pdk-root <pdk-root> --output-dir <evidence-dir>
```

Name the technology; never write it into the deck. Devices are canonical roles
(`nmos.core`, `.svt` / `.lvt` / `.hvt` / `.io`) with SI geometry, and the driver
owns the model vocabulary, instance prefix, parameter spelling, geometry units,
library prelude, corner and any Verilog-A preload. Run `openada simulate --help`
for the PDKs it can bind, and pass `--corner` only when the request names one.
Do not edit the published deck to suit a PDK: a deck that had to be edited is no
longer the artifact whose digests the result binds, and a deck carrying
`pre_osdi` or a PDK `.lib` is refused with `pdk.collateral.hand_bound`.

**Never hand-write model cards to get past a failed bind.** An invented `.model`
line is not the PDK however closely its name matches a real device: it
substitutes different physics for the foundry's while still looking like a
credible simulation result. Report the bind failure instead.

Record the result before scheduling another intent. A simulation pass advances
only to extraction; an extraction pass advances only to its declared
result operation; a result-operation pass advances to specification evaluation
only if the row already carries a bound. Stop at the first unknown, unavailable
capability, or missing authoritative choice and ask one narrow question.

## Compose focused skills

- Invoke `$openada:analyze-feedback-stability` for differential, common-mode, nested,
  feed-forward, or regulator-loop questions after the DC gate.
- Invoke `$openada:analyze-spectral-linearity` for FFT, harmonic, SFDR, sampled-data,
  or waveform-linearity questions after transient evidence is valid.
- Invoke `$openada:assess-pvt-and-yield` only after nominal analyses,
  simulation-result definitions, and specification limits are frozen.

Do not duplicate their metric rules inside this coordinating workflow. Accept
their blocked or unknown result as a characterization state, not as an excuse to
skip the metric.

## Route each result honestly

| Observed state | Next action |
|---|---|
| Analysis evidence pass | Request only supported result operations bound to that exact evidence |
| Series extraction pass | Use only the emitted canonical series and exact selector/condition ledger |
| Series extraction unknown | Repair native artifact, plot, selector, component, unit, or digest binding |
| Analysis evidence fail | Retain the conclusive solver evidence and diagnose that failure before interpreting performance |
| Analysis evidence unknown | Resolve the cited request, provenance, freshness, or structural gap and rerun the same intent |
| Result-operation pass | Evaluate an explicit specification if one exists |
| Result-operation fail or unknown | Repair the result-operation definition or evidence; do not classify circuit performance |
| Specification pass or fail | Record the result only for its exact condition and limit |
| Any required capability unavailable | Preserve the gap as not evaluated and propose the smallest missing semantic primitive or capable driver |

## Report the next engineering decision

Return:

1. the immediate engineering claim, its assumptions, and whether it is
   source-derived, evidence-testable, or not evaluable;
2. the frozen context and unresolved assumptions;
3. the ordered characterization matrix and coverage by contract layer;
4. per-run backend identity, exact profile/feature, result status, diagnostics,
   and artifact lineage;
5. simulation results and specification results without collapsing their statuses;
6. application-specific open risks and unsupported primitives;
7. one smallest next experiment that can change the decision.

End with `signoff: not claimed` unless an external, explicitly qualified
signoff process has been supplied and reviewed. OpenADA evidence can support
that review; these skills do not confer signoff authority.