After the substantial workflow foundation introduced in v1.2.0, this release takes the next practical step: establishing where workflows belong, clarifying the boundaries between different kinds of workflow repositories, and adding a small set of examples that make the existing workflow system easier to understand.
It is a plumbing and documentation release.
There are no new remote workflow commands in v1.2.1. No catalog browsing, installation, publishing, private repository authentication, or remote execution has been added. Instead, the release prepares the project for those capabilities without prematurely building them.
Examples Are Examples
RESERVE now includes four curated workflow examples under:
Together, these examples demonstrate several parts of the workflow model:
a simple single-series observation;
a transformation pipeline;
multi-series analysis;
runtime parameters and workflow contracts.
They are intentionally readable and modest. Their purpose is to show workflow syntax and CLI capabilities, not to serve as production-grade economic research.
The examples also establish an important rule:
examples/workflows/ is educational source-tree content. It is not the official RESERVE workflow catalog.
That distinction matters as the project grows. Examples may demonstrate simplified data, unusual features, or authoring patterns that do not belong in a curated public collection.
A Clearer Workflow Ecosystem
RESERVE workflows now have clearly defined homes:
examples/workflows/
Educational examples shipped with the source tree.
~/.reserve/workflows/personal/
User-created and locally installed workflows.
reserve-workflows/
The future canonical, curated public workflow collection.
Private repositories/
Future user- or organization-controlled collections.
RESERVE workflow API/
The future distribution boundary between the CLI and repositories.
The official repository is named reserve-workflows.
That name now exists as a first-class internal repository descriptor rather than as a collection of hard-coded GitHub URLs or storage-specific assumptions. The CLI’s future repository operations can depend on the concept of an official repository while remaining independent of how that repository is authored, published, indexed, or stored.
GitHub may be the source of truth for the curated workflow collection. A cloud-based API and supporting distribution services may eventually provide access to that collection. Those implementation details should remain behind the RESERVE workflow API boundary.
The Official Repository Boundary
The internal official repository descriptor identifies:
id: official
name: reserve-workflows
type: official
endpoint: https://api.reservecli.dev/v1
This does not yet enable remote workflow operations. It simply establishes the abstraction that future releases can build upon.
The initial API boundary is intentionally small:
GET /workflows
GET /workflows/{id}
GET /workflows/{id}/{version}
The exact service implementation can evolve later without requiring the CLI to understand GitHub repository layouts, static object paths, R2 buckets, or other infrastructure details.
What Users Will Notice
For most installed users, v1.2.1 is intentionally quiet.
The existing workflow commands continue to work as before:
The new examples are shipped in the RESERVE source repository for developers and contributors. They are not automatically copied into a user’s ~/.reserve/workflows/ directory, and they are not presented as the official catalog.
That keeps the local-first behavior of RESERVE unchanged while giving workflow authors clearer reference material.
Go 1.27.1
RESERVE v1.2.1 also updates the supported release toolchain note to Go 1.27.1.
This is a small implementation detail, but documenting the toolchain used for the release improves reproducibility and gives users and maintainers a clearer baseline for future builds.
A Small Release With a Long-Term Purpose
The goal of v1.2.1 is not to make the workflow system larger. It is to make its boundaries harder to misunderstand.
Examples should remain examples.
Personal workflows should remain local.
The official catalog should have its own repository.
Private repositories should arrive only when their authentication and authorization model is ready.
And the CLI should communicate with repositories through a stable RESERVE abstraction rather than through infrastructure-specific knowledge.
That gives future releases room to add official workflow browsing and installation without turning the local workflow foundation into a tangle of special cases.
RESERVE v1.2.1 establishes the physical and architectural boundaries of that ecosystem, while keeping the user-facing CLI focused, local, and predictable.
One of the recurring goals in RESERVE development has been making sophisticated economic analysis easier to create, understand, and repeat.
As the project has grown, users have increasingly combined data retrieval, transformation, analysis, and visualization commands into pipelines. These pipelines are one of the CLI’s greatest strengths, but they also introduce a practical challenge: a useful analysis often needs to be reconstructed each time it is performed. For agentic users of RESERVE, that translates to avoidable token consumption.
RESERVE 1.2.0 introduces a foundation for solving that problem.
The release adds workflows, a content-first system for creating, documenting, validating, and sharing reusable economic analyses.
A workflow can describe the purpose of an analysis, the economic concepts it covers, the inputs it requires, and the RESERVE pipeline used to perform it. Static workflows can represent fixed analyses with no runtime inputs, while dynamic workflows can accept ordered values such as a start date, end date, country, series, or comparison period.
Version 1.2.0 does not attempt to solve every part of workflow distribution and execution. Instead, it establishes the document format, command model, filesystem layout, validation rules, and safety boundaries upon which the broader workflow ecosystem can be built.
Introducing the Workflow Command
The new workflow command family provides the tools needed to author and inspect reusable analyses:
The command model follows RESERVE’s noun-verb convention. Workflow is the object being managed, while commands such as create, validate, and render describe the action being performed.
The collection README is a normal repository artifact. It can explain the purpose of the collection, document its workflows, and travel with the collection when it is distributed through Git or another repository service. RESERVE scaffolds the initial README but never overwrites existing documentation.
Static and Dynamic Workflows
Not every analysis requires user input.
A static workflow can define a fixed pipeline that is rendered the same way every time. This is useful for established dashboards, recurring reports, classroom demonstrations, or analyses tied to a specific series and period.
Dynamic workflows add an ordered runtime contract.
For example, a GDP summary workflow might declare two inputs:
contract:
- label: start date
format: YYYY-MM-DD
sample: 2020-01-01
description: First date in the analysis period.
- label: end date
format: YYYY-MM-DD
sample: 2024-12-31
description: Final date in the analysis period.
The workflow pipeline refers to these inputs positionally:
pipeline:
- reserve obs get GDP --start @1 --end @2 --format jsonl
- reserve analyze summary
The first supplied value replaces @1, the second replaces @2, and the pattern can continue through @X.
Users and AI agents can inspect the required inputs before rendering the workflow:
reserveworkflowcontractgdp-summary
RESERVE displays the label, expected format, sample value, and description for each input:
personal/economic-growth/gdp-summary contract:
@1 = start date
format: YYYY-MM-DD
sample: 2020-01-01
description: First date in the analysis period.
@2 = end date
format: YYYY-MM-DD
sample: 2024-12-31
description: Final date in the analysis period.
Zero-input workflows are supported as a first-class use case. A workflow only needs a contract when its pipeline contains runtime slots.
Safe Rendering Instead of Execution
An important design decision in RESERVE 1.2.0 is that workflows do not execute pipeline content.
It does not invoke Bash, start another shell, or execute the rendered pipeline.
This boundary is intentional.
Shell execution introduces significant security and cross-platform questions, especially when workflow definitions may eventually come from public, educational, community, or private repositories. Version 1.2.0 keeps the operator or calling agent in control. The rendered command can be reviewed, copied, modified, audited, or executed through an environment chosen by the user.
A future release may introduce explicit rendering targets or controlled execution semantics. Those capabilities may only be added after their portability, trust, and security models are clearly defined.
Validation as a First-Class Feature
Because workflows are intended to become portable artifacts, validation must be more rigorous than simply checking whether a YAML file can be opened.
The new validator checks workflow structure, runtime contracts, pipeline placeholders, and collection-aware references:
Version 1.2.0 also adds several production safeguards:
Unknown YAML fields are rejected instead of being silently ignored.
Multiple YAML documents in one workflow file are rejected.
Runtime slots must match the declared contract.
Repository-style paths cannot traverse outside the configured workflow root.
Symlinks cannot be used to escape the workflow namespace.
A workflow’s reserve_version requirement is checked against the running CLI.
Rendering fails when required runtime values are missing or incompatible.
These rules help authors catch mistakes before publishing a collection and give users greater confidence when inspecting workflows obtained from another source.
A Repository-Aware Foundation
Workflows are organized using a three-part name:
repository/collection/workflow
For example:
personal/economic-growth/gdp-summary
Each part has a distinct purpose.
The repository identifies the source or trust boundary. The collection groups related analyses. The workflow identifies the individual analytical method.
Version 1.2.0 begins with local filesystem storage and uses personal as the default repository for user-authored workflows. The architecture also anticipates additional repository types:
official for workflows maintained and distributed by the RESERVE project
community for collections curated by organizations or subject-matter communities
education for universities, schools, instructors, and home-school networks
private for internal organizational analysis
Remote search, installation, synchronization, signing, and trust policies are not part of this foundational release. However, establishing repository-aware names now means those capabilities can be added later without redesigning the workflow identity model.
A university could eventually distribute a collection through GitHub. A research group could maintain an internal Git repository. A home-school network could publish a shared economics curriculum. RESERVE’s local commands can remain consistent regardless of how those collections are distributed.
Moving Beyond Snippets
Earlier versions included an exploratory feature called snippet.
Snippets helped test the idea that RESERVE pipelines could be saved and reused, but they did not provide the metadata, validation, contracts, collection structure, or repository model needed for a durable ecosystem.
Version 1.2.0 removes the experimental snippet feature and replaces it with workflows.
Because snippets were introduced as a silent exploratory feature and had not been promoted for general use, this was the right point to make a clean transition. Workflows now provide the foundation on which future sharing and distribution capabilities will be built.
Built with Go 1.27
RESERVE 1.2.0 also moves source builds to Go 1.27.
For a data-oriented CLI, the move to Go 1.27 is especially relevant. The release introduces the new encoding/json/v2 implementation, with the established encoding/json API now backed by the newer engine while preserving compatibility. The Go team reports significantly faster JSON unmarshalling, an important improvement for software that regularly processes API responses and JSONL observation streams.
Because RESERVE relies heavily on JSON responses from the FRED® API, we ran our own benchmarks against representative observation data. The results were striking.
Simply compiling RESERVE with the Go 1.27 toolchain produced approximately three times the JSON unmarshalling throughput and reduced unmarshalling time by about 68 percent.
Go 1.27 also introduces size-specialized allocation routines that can reduce the cost of small allocations. In our benchmarks, allocations fell by approximately 80 percent when processing large FRED observation payloads.
These are workload-specific benchmark results rather than a claim that every RESERVE command will run three times faster. They do, however, demonstrate a meaningful improvement in one of the CLI’s most important data-processing paths.
Go 1.27 also strengthens the development toolchain by checking for accidental use of standard-library features newer than the version declared by a module.
Together, these improvements provide a faster and stronger runtime foundation without changing how users interact with RESERVE. Prebuilt binaries remain self-contained, so users installing a RESERVE release do not need to install or upgrade Go separately. Go 1.27 or later is required only when building RESERVE from source, and no workflow or command compatibility changes are required.
RESERVE 1.2.0 is intentionally a foundational release.
It establishes:
A stable workflow YAML format
Static and dynamic workflow contracts
Repository and collection namespaces
Strict validation and version compatibility
Safe, non-executing pipeline rendering
Collection-level documentation
Local creation, discovery, inspection, editing, and removal
A clear path toward future workflow distribution
The next phase will be shaped by real workflow authors and real collections.
That means building analyses, documenting them, testing the contract model, determining which metadata proves useful, and learning how individuals, educators, researchers, and organizations want to distribute their work.
RESERVE began as a tool for retrieving economic data from the command line. It has steadily evolved into a composable environment for transforming, analyzing, and visualizing that data.
With version 1.2.0, those commands can now become durable analytical methods.
Create the workflow once. Validate it. Document it. Render it whenever the question returns.
One of the recurring goals in RESERVE development has been making the command-line interface easier to use without making it more complicated.
As the project has grown, the number of commands, pipelines, analysis tools, and configuration options has steadily expanded. Alongside that growth, RESERVE introduced structured onboarding designed not only for human users but also for AI assistants and automated development tools. Rather than treating documentation as something separate from the CLI, onboarding became part of the product itself.
That capability has continued to evolve over several releases.
Version 1.1.9 doesn’t introduce AI onboarding—it makes it easier to reach.
The release adds a global --ai-onboard switch that can be used from virtually any command path while preserving the existing reserve onboard workflow. Both entry points now share the same implementation and produce the same structured guidance, giving users and AI agents a more natural way to discover the CLI without introducing duplicate logic or inconsistent documentation.
AI Onboarding, Wherever You Enter
RESERVE has supported structured onboarding for some time through the reserve onboard command.
At the program level, onboarding can introduce an AI agent to the CLI, explain pipeline semantics, provide verified examples, document common gotchas, and even perform a token-conscious two-step handshake so large language models receive only the context they actually need. Command-specific onboarding has likewise been available for major command groups such as series, obs, transform, analyze, and config.
Version 1.1.9 extends that experience by adding a second, more natural entry point.
Instead of stepping outside the command you’re exploring, onboarding can now be requested directly:
reserveobsgetCPIAUCSL--ai-onboard
The traditional approach continues to work exactly as before:
reserveonboardobs
or, for program-level onboarding:
reserveonboard--topictoc
Both approaches now arrive at the same destination.
The new global switch doesn’t replace the onboarding command—it simply makes onboarding available exactly where users and AI agents are already working.
One Onboarding System
Although there are now two ways to invoke onboarding, there is still only one onboarding implementation.
Whether guidance is requested through reserve onboard or via --ai-onboard, the CLI generates the same structured, machine-readable content from the same source. Examples, pipeline documentation, command references, and operational guidance remain synchronized automatically because they are produced by a shared code path rather than separate implementations.
For AI-assisted development, that consistency is important. Agents no longer need to learn a special onboarding command before asking for help with the command they’re already using. At the same time, maintainers only have one onboarding system to evolve, reducing the possibility that documentation and behavior drift apart over time.
One of the recurring themes in RESERVE development has been that retrieving economic data is only the first step in the workflow.
Most users don’t stop after fetching a series from FRED®. They want to understand it. Is unemployment rising or falling? How closely does it move with interest rates? Has the behavior of a series changed over time? Are recent observations behaving differently than historical ones?
Previous releases gradually introduced analytical capabilities to help answer those questions. Summary statistics, trend analysis, transformations, and pipelines all expanded the platform beyond simple data retrieval. As those capabilities grew, however, it became increasingly clear that analysis needed to feel like a unified part of RESERVE rather than a collection of separate features.
Version 1.1.8 is largely about addressing that.
The release introduces new comparison and regime-analysis capabilities, adds rolling-window summaries and confidence reporting, and makes analysis output more consistent across the platform. Whether you’re summarizing a series, fitting a trend, comparing indicators, or looking for structural changes, the commands now work together more naturally and present results in a more consistent way.
Comparing Economic Indicators
Economic analysis is fundamentally comparative.
Inflation is interpreted relative to interest rates. Employment is evaluated alongside labor force participation. Market indicators are compared against policy measures. Very few economic series are meaningful in complete isolation.
Version 1.1.8 introduces analyze compare, a new command designed specifically for aligned-series analysis.
For example, comparing unemployment against the federal funds rate since 2010 can be performed with a single pipeline:
Even this simple example reveals useful information immediately. The negative correlation reflects the tendency for unemployment and policy rates to move in opposite directions over long periods, while beta and tracking-error metrics provide additional context about the strength and consistency of that relationship.
Comparison results now retain the source information associated with each series. In the example above, the output identifies both the Bureau of Labor Statistics and the Federal Reserve as the underlying data providers. That information now flows consistently through analysis commands and output formats, making it easier to understand where analytical results originated.
Trend Analysis With Additional Context
Trend analysis has been part of RESERVE for several releases, but v1.1.8 expands the information available alongside trend estimates.
A trend can tell you whether a series is moving up or down, but that is only part of the story. Understanding how reliable that estimate may be is often just as important as the estimate itself.
The new --confidence option adds statistical measures that help put trend results into context, including standard errors, p-values, and confidence intervals.
In this case, the analysis identifies a positive trend in the federal funds rate over the period while also reporting measures of uncertainty around that estimate. Rather than presenting a slope alone, RESERVE can now show the supporting statistics used to evaluate the strength and reliability of the result.
This additional context is especially useful when comparing trend estimates across multiple series or evaluating whether an apparent trend is likely to be meaningful rather than simply noise in the data.
Consistency Across Analysis
Many of the improvements in v1.1.8 are less visible than the new commands themselves.
Summary, trend, compare, and regime outputs now share a common table layout and presentation style. Numeric formatting has been standardized to improve readability while JSON and JSONL outputs remain optimized for automation and downstream processing.
The same formatting conventions now extend across observation retrieval, transformation workflows, and analysis commands. The goal is simple: users should spend less time adapting to different output formats and more time focusing on the data.
Version 1.1.8 also introduces rolling-window summaries through analyze summary --window N, allowing users to evaluate trailing periods instead of treating an entire series as a single historical block. Combined with the new comparison and trend enhancements, this creates a more complete analytical toolkit within the existing pipeline architecture.
Keeping Sources Attached to Results
One smaller but important improvement in v1.1.8 is that analysis output now handles source information more consistently.
In the comparison example above, RESERVE reports not only the analytical results but also the organizations responsible for the underlying data:
One of the goals of v1.1.8 was greater consistency across analytical workflows. Source information attached to data retrieval now remains attached as that data moves through analysis commands, helping ensure that results stay connected to the underlying series and organizations that produced them.
This is a relatively small change, but it becomes increasingly valuable as workflows grow more complex. The more transformations and analyses that occur between data retrieval and interpretation, the more important it becomes to keep the connection to the original data source visible.
Reliability Behind the Scenes
Version 1.1.8 also includes a number of infrastructure improvements that most users will never notice directly.
Live FRED traffic is now paced more conservatively, retry behavior better respects server guidance, and rate-limit handling has been refined to behave more predictably under constrained conditions. Testing infrastructure has likewise been updated to distinguish more effectively between live and offline environments.
These changes may not appear in screenshots, but they contribute to something equally important: confidence that analytical workflows behave consistently over time.
From Data Retrieval to Data Interpretation
The broader theme of v1.1.8 is analytical maturity.
RESERVE began as a way to make economic data easier to access. Over time it expanded into transformations, pipelines, caching, visualization, and reusable workflows. This release focuses on strengthening the next layer of that stack: helping users interpret the data they retrieve.
Comparison analysis, rolling summaries, confidence-aware trend reporting, provenance preservation, and experimental regime detection all support that objective.
The individual features matter, but the larger change is that analysis now feels increasingly like a coherent part of the platform rather than a collection of independent tools.
That’s an important step forward for RESERVE, and it lays the groundwork for future analytical capabilities still to come.
The original design goals of RESERVE were straightforward: provide intuitive access to the FRED® API while extending that foundation with pipelines, transformations, and analysis capabilities in a single command-line environment.
As the platform has evolved, another design goal has emerged. RESERVE is no longer focused solely on executing commands; it is increasingly focused on helping users capture, repeat, and share economic data workflows.
Economic analysis is rarely a single command invocation. It is often a sequence of retrieval, transformation, filtering, summarization, and visualization steps that users repeat over time.
Version 1.1.7 introduces the first foundation for treating those workflows as reusable assets.
Introducing Snippet Libraries
The headline feature of this release is a new snippet command family:
Snippets provide a mechanism for storing and reusing commonly executed command sequences.
Rather than maintaining shell history entries, personal notes, or external documentation, users can begin building a catalog of repeatable RESERVE workflows directly within the platform.
Importantly, snippets are backed by a filesystem-based library model rather than a temporary or session-oriented implementation.
This establishes a foundation that can scale beyond simple local convenience.
Today’s snippets may be personal workflow shortcuts.
Tomorrow they could become shared libraries, team standards, educational examples, or domain-specific analysis recipes.
Version 1.1.7 is intentionally a soft launch of that capability.
The goal is to establish the foundation before expanding the ecosystem around it.
Reproducibility Matters
Reusable workflows are only valuable if they produce consistent results.
A significant portion of this release focuses on strengthening the reliability of RESERVE’s batch-processing infrastructure through deterministic concurrency testing.
Batch observation and series retrieval now have dedicated testing coverage for:
Concurrency limits
Ordering guarantees
Warning behavior
Fallback paths
Previous test approaches relied on timing assumptions and sleep-based coordination.
The new test framework uses deterministic synchronization mechanisms that make behavior reproducible and easier to validate.
Most users will never see these changes directly.
But they contribute to something important:
Confidence that the same workflow behaves the same way every time it runs.
Preserving Attribution Through Pipelines
Another important improvement in v1.1.7 addresses metadata fidelity.
Recent releases have emphasized citations, provenance, and source attribution as first-class concerns within RESERVE.
This release extends that philosophy into transformation workflows.
Pipeline transformation commands now preserve citation metadata from upstream JSONL inputs, ensuring source attribution remains attached to data as it moves through transformations and resampling operations.
The principle is simple.
Transforming data should not erase information about where that data came from.
As workflows become more sophisticated, preserving provenance becomes increasingly important.
Small Improvements Matter
Not every enhancement in a release needs to be architectural.
Version 1.1.7 also improves ASCII chart rendering by standardizing numeric value labels to fixed two-decimal formatting.
Values such as:
59.00
now align consistently within chart output.
This is a small visual refinement, but one that improves readability when scanning larger datasets.
Polish accumulates over time.
And often the most frequently used features benefit the most from incremental improvements.
Building Beyond Individual Commands
The broader theme of v1.1.7 is not snippets themselves.
It is the idea that economic analysis consists of workflows rather than isolated commands.
Users retrieve data.
Transform it.
Compare it.
Visualize it.
Share the process.
Repeat it.
The new snippet library begins creating a place where those processes can be captured, reused, and eventually shared.
That makes this release more than a quality-of-life improvement.
It represents an early step toward a larger vision for RESERVE: not just a collection of economic data commands, but a platform for building repeatable economic data workflows.
Economic data is only as trustworthy as its provenance.
An observation may tell us what happened. Metadata tells us where that information came from, who produced it, and how it should be interpreted.
As RESERVE has evolved, an increasingly important design principle has emerged: metadata should not be treated as secondary information. Source attribution, citation requirements, and dataset provenance are part of the data itself.
Version 1.1.6 continues that philosophy by improving attribution fidelity throughout the platform, strengthening support for multi-source datasets, and expanding structured metadata for both human and agent-driven workflows.
Economic Data Often Has Multiple Sources
Many users think of a series as having a single producer.
In reality, economic datasets are often assembled from multiple contributing organizations. A published series may represent work performed by several agencies, institutions, or data providers.
Representing that relationship accurately becomes increasingly important as data moves through analytical pipelines.
Version 1.1.6 expands RESERVE’s metadata model to support:
Multiple source attributions per series
Structured source name arrays
Normalized citation display names
Richer source metadata in release payloads
These additions ensure attribution information can remain complete even when a dataset’s provenance extends beyond a single organization.
Clear Attribution for Multi-Series Workflows
As support for comparative and multi-series analysis has grown, citation presentation has become more challenging.
A single observation query may involve several series, each with different attribution requirements and source organizations.
Previous releases consolidated citations where possible. Version 1.1.6 takes the next step by providing per-series source attribution blocks for multi-series observation output.
This approach prioritizes clarity over brevity.
When multiple datasets appear together, users should be able to determine exactly which sources contributed to each series without ambiguity.
Single-series workflows retain concise source presentation, while multi-series output now emphasizes attribution precision.
Better Metadata for Downstream Systems
Increasingly, RESERVE serves as more than an interactive command-line tool.
Outputs are consumed by:
Scripts
Pipelines
Dashboards
Analytical workflows
AI systems
To support these use cases, release metadata payloads now expose complete structured source information through JSON interfaces.
Commands such as release metadata retrieval now include full source arrays, allowing downstream systems to preserve attribution information without relying on human-readable formatting.
The objective is straightforward:
Source metadata should be available as structured data whenever possible.
Building for Human and Agent Consumers
One of the more notable additions in v1.1.6 is expanded onboarding metadata intended for automated consumers.
Structured onboarding payloads now include information such as:
Primary audience
Human versus agent targeting
Explicit content classification
These additions help language models and automation systems better understand the purpose and intended usage of onboarding materials.
While subtle, this reflects an increasingly important reality: modern software documentation is consumed by both people and machines.
Supporting both audiences requires metadata that clearly communicates intent.
Improving Attribution Quality
Several refinements in this release focus on the presentation and consistency of source information.
Citation display names are now normalized when upstream metadata is provided in inconsistent formats.
Duplicate source footers are eliminated for shared datasets.
Serialization edge cases involving incomplete attribution records have been addressed.
These improvements may appear minor, but they contribute to a larger goal: ensuring attribution remains accurate, readable, and reliable regardless of where the data originated.
Metadata Is Not an Afterthought
A recurring theme throughout recent RESERVE releases has been responsible data stewardship.
Permissions matter.
Citations matter.
Provenance matters.
Version 1.1.6 extends that philosophy by improving how source information is represented, preserved, and communicated throughout the platform.
Economic observations are the most visible part of a dataset.
But understanding who produced those observations—and ensuring that information survives every step of the workflow—is equally important.
In RESERVE, metadata is no longer treated as an accessory to the data.
It is part of the data.
And v1.1.6 continues the work of making sure it stays that way.
As software matures, progress increasingly comes from refinement rather than expansion.
New features remain important, but long-term usability often depends on something less visible: consistency. Users should be able to trust that commands behave predictably, that metadata is presented correctly, and that edge cases are handled without surprises.
Version 1.1.5 focuses on exactly those areas.
This release improves alias management, strengthens citation presentation, resolves structured output edge cases, and closes several correctness gaps discovered during real-world usage.
Together, these changes make RESERVE a more reliable platform for everyday economic data workflows.
Aliases Gain Context
Aliases have always provided a convenient way to create memorable shortcuts for frequently used series.
With v1.1.5, aliases become more than simple mappings.
Users can now attach optional notes when creating aliases:
reserve alias set CPI CPIAUCSL --note "Headline CPI inflation"
Alias metadata now supports:
Required series identifiers
Optional user-authored notes
Richer listing and display behavior
The result is a lightweight documentation layer that allows users to capture intent directly alongside their shortcuts.
As collections of aliases grow, that additional context becomes increasingly valuable.
A name can tell you what something is.
A note can remind you why it matters.
Citations Should Be Predictable
Previous releases introduced citation-aware data handling as part of RESERVE’s broader commitment to responsible economic data stewardship.
Version 1.1.5 continues that effort by improving how citations are presented across observation commands.
Table output now uses a consistent citation model:
Single-source results produce a single Source footer
Multi-source results produce a consolidated Sources footer
Duplicate source entries are automatically removed
Most users will simply notice cleaner output.
More importantly, citation behavior is now predictable regardless of whether a workflow involves one series or many.
Consistency reduces ambiguity and helps ensure attribution remains visible as analysis becomes more complex.
Structured Output Should Stay Structured
One of the most important fixes in this release addresses a subtle but significant interoperability issue.
Certain economic series contain missing observations represented internally as NaN values.
When exported as JSON, these values could previously trigger errors such as:
json: unsupported value: NaN
Version 1.1.5 now converts missing observation values to JSON null.
This change aligns RESERVE output with standard JSON expectations and improves compatibility with downstream tools, scripts, databases, and AI workflows.
The principle is straightforward:
Structured output should remain valid structured output, even when the underlying data contains gaps.
Stronger Alias Ownership Semantics
Several fixes in this release improve how aliases behave across local and user-level configuration files.
Alias deletion now correctly removes entries from the configuration file that actually owns the alias, avoiding situations where merged configuration views could make ownership unclear.
Collision detection has also been strengthened.
When upstream validation services experience transient failures, alias creation now fails closed rather than assuming success.
These changes prioritize correctness over convenience and help prevent subtle configuration inconsistencies from accumulating over time.
Preserving Compatibility
As configuration models evolve, existing users should not be forced into disruptive migrations.
To support that goal, RESERVE now tolerates legacy string-based alias definitions during reads while continuing to write the newer structured format.
This allows older configurations to remain functional while gradually moving users toward the canonical representation.
The migration path becomes effectively automatic.
Small Improvements, Bigger Reliability
Many releases are remembered for a single headline feature.
Version 1.1.5 is different.
Its value comes from dozens of small improvements that collectively strengthen the user experience.
Aliases now carry richer context.
Citation behavior is more consistent.
Structured outputs are more reliable.
Configuration ownership is clearer.
Compatibility is stronger.
None of these changes dramatically alter what RESERVE can do.
They improve confidence in how RESERVE does it.
And for a tool intended to support serious economic analysis, that confidence matters.
The design goals of RESERVE have always been straightforward: provide intuitive wrappers around the FRED® API while extending those capabilities with pipeline processing and analytical tooling in a single command-line environment. Rather than forcing users to stitch together multiple utilities, scripts, and output formats, RESERVE is designed as an integrated economic data workbench where retrieval, transformation, and analysis can occur within a consistent workflow.
Early releases focused on establishing reliable access to economic data. Version 1.1.4 represents a further step toward the broader vision—making multi-series analysis a first-class workflow rather than an afterthought.
Installing the CLI.
Managing local data.
Handling permissions and citations.
Keeping installations current.
Those capabilities remain essential, but they are ultimately in service of a larger goal: helping users analyze economic data.
Version 1.1.4 takes an important step in that direction by improving how RESERVE works with multiple series at once and refining the workflows used by both humans and AI assistants.
The result is a release focused less on individual commands and more on how analysis actually happens.
Economic Analysis Is Usually Comparative
Very few macroeconomic questions can be answered by looking at a single series in isolation.
How does inflation compare to wage growth?
How does unemployment compare to labor force participation?
How do interest rates relate to housing activity?
The most useful analysis often begins with multiple series observed across the same time window.
Version 1.1.4 improves support for exactly these workflows.
Multi-Series Summaries
The headline addition is:
reserve analyze summary --by-series
This new mode allows RESERVE to summarize multi-series JSONL streams on a per-series basis.
Rather than treating a collection of observations as a single aggregate stream, RESERVE can now preserve series-level context during analysis.
That distinction becomes increasingly important as users move from retrieving data toward comparing and interpreting it.
The feature is backed by new grouped JSONL support in the pipeline layer, allowing multi-series observation streams to flow through analysis commands in a more structured and predictable way.
Promoting Better Retrieval Patterns
One lesson that emerged from onboarding and user workflows is that many analyses begin with several related series collected over the same observation window.
Version 1.1.4 updates onboarding guidance and examples to encourage this pattern directly.
Instead of retrieving series one at a time, users are now guided toward batched requests:
reserve obs get CPIAUCSL UNRATE FEDFUNDS
followed by analysis operations such as:
reserve analyze summary --by-series
This workflow reduces friction, keeps time windows aligned, and produces cleaner comparative analysis.
In short, it reflects how economic questions are typically explored in practice.
Improving the LLM Experience
As more users incorporate RESERVE into AI-assisted workflows, onboarding content has become increasingly important.
Prior versions attempted to expose a large portion of the command surface during onboarding.
While comprehensive, this often created unnecessary noise.
Version 1.1.4 shifts toward a more focused approach.
The default onboarding experience now provides a concise routing brief instead of a complete command catalog.
Topic-oriented guidance has also been streamlined to emphasize workflows rather than command memorization.
This makes onboarding more approachable for both human users and language models that need to understand the structure of the tool quickly.
Correctness Matters
Several fixes in this release address situations where RESERVE was being overly permissive.
Invalid global options now fail immediately rather than silently falling back to defaults.
Configuration validation has been strengthened to reject malformed values and unsupported settings.
Unknown output formats now produce explicit errors.
Malformed configuration files now surface problems instead of being ignored.
These changes may seem small, but they improve trust in the system.
When software accepts invalid input without warning, users can easily develop incorrect assumptions about how it behaves.
Failing fast makes problems easier to identify and easier to fix.
Protecting Machine-Readable Workflows
One of the more important operational improvements in this release involves structured output.
Commands such as:
JSON
JSONL
CSV
TSV
Markdown
are frequently consumed by scripts, pipelines, and AI systems.
Version 1.1.4 now routes warnings and informational footers to stderr rather than stdout when structured formats are requested.
This preserves machine-readable output while still allowing users to see warnings and diagnostics.
For automation-heavy workflows, this distinction is critical.
Data should remain data.
Diagnostics should remain diagnostics.
A Shift Toward Workflow Design
The broader theme of v1.1.4 is not a single command.
It’s workflow design.
The release encourages users to think in terms of:
Multiple related series
Shared observation windows
Structured analytical pipelines
Machine-readable outputs
Clear and validated configuration
Those concepts are foundational to serious economic analysis.
As RESERVE continues to evolve, that perspective becomes increasingly important.
The goal is no longer simply retrieving economic data.
The goal is helping users move efficiently from data retrieval to insight.
Version 1.1.4 is an important step in that direction.
As software matures, one of the most important questions shifts from:
“What can it do?”
to
“How easily can it stay current, healthy, and operational?”
RESERVE v1.1.3 is focused on answering that second question.
While this release doesn’t introduce new macroeconomic analysis capabilities, it lays important groundwork for long-term maintainability through self-updating infrastructure, improved cache visibility, and stronger release plumbing.
These changes are largely operational by design.
Their purpose is to make managing RESERVE simpler as the project continues to grow.
The First Step Toward Self-Updating
The headline feature in v1.1.3 is the introduction of:
reserve update apply
for macOS and Linux installations.
Until now, RESERVE could tell users when a newer version existed through:
reserve update check
but the installation process remained manual.
Version 1.1.3 introduces the first phase of an integrated update workflow, allowing RESERVE to retrieve and apply new releases directly.
This is foundational infrastructure that will support a smoother upgrade experience moving forward.
Safe Testing for the Update Path
Updating software is one of the highest-risk operations any application performs.
To support validation and troubleshooting, RESERVE now includes a dry-run mode:
reserve update apply --dry-run
This allows users to exercise the entire update workflow—from manifest retrieval through asset resolution—without replacing the installed binary.
For developers and power users, this provides confidence that the update path is functioning correctly before any changes are made.
Combined with:
reserve update apply --dry-run --force
the complete update process can be tested even when the installed version already matches the latest available release.
The result is a safer and more observable update experience.
Platform-Specific Behavior Matters
Different operating systems have different expectations around software updates.
Rather than attempting a fragile in-place update workflow on Windows, RESERVE now resolves and displays the exact release asset URL required for manual installation.
This keeps behavior predictable while avoiding platform-specific edge cases that could negatively affect reliability.
The goal is not to force identical behavior across operating systems.
The goal is to provide the most reliable experience for each platform.
Making the Local Cache Easier to Understand
RESERVE’s local cache continues to play an important role in performance, offline workflows, and operational resilience.
Version 1.1.3 introduces:
reserve cache path
which displays the active local database location.
While simple, this command eliminates guesswork when troubleshooting installations, inspecting local state, or working across multiple environments.
Understanding where data lives is often the first step toward understanding how a system behaves.
Better Visibility Into Local Storage
This release also expands cache diagnostics through enhanced statistics reporting.
The updated:
reserve cache stats
command now includes:
Database schema version
On-disk database size
Per-bucket row counts
Per-bucket storage consumption
These additions provide a more complete operational picture of local storage and make it easier to understand how cached data evolves over time.
As RESERVE accumulates more metadata, permissions information, observations, and local indexes, visibility into storage becomes increasingly important.
Strengthening the Foundation
Most users will not install v1.1.3 because they need a specific new economic data command.
They will install it because it makes the platform itself stronger.
Self-update infrastructure.
Safer release validation.
Better platform-aware behavior.
Improved cache visibility.
Stronger operational tooling.
These improvements may not be the most visible features in the project, but they are the kind of investments that make future features easier to deliver and easier to maintain.
Building Toward a More Self-Sufficient Tool
The broader theme of v1.1.3 is autonomy.
RESERVE can now do more to understand its own state, manage its own lifecycle, and help users maintain healthy installations.
That’s not a new macroeconomic capability.
It’s something just as important.
It’s the beginning of RESERVE becoming a tool that not only helps users manage data—but increasingly helps manage itself.
As RESERVE has matured, it became increasingly important to recognize that reality.
Version 1.1.2 introduces the first comprehensive permissions and compliance framework within RESERVE.
Respecting the Source
Good data stewardship starts with acknowledging where data comes from.
Many FRED series are effectively public-domain resources. Others request attribution. Some require citation. Others may require prior approval before redistribution or use in certain contexts.
Historically, these distinctions were easy for users to overlook because the focus naturally falls on retrieving observations and performing analysis.
RESERVE now treats rights metadata as a first-class concern.
The goal is simple: help users understand and respect the requirements associated with the data they consume.
Introducing Rights-Aware Access
Version 1.1.2 adds rights and permissions classification for FRED series metadata, including support for:
Copyrighted series requiring pre-approval
Copyrighted series requiring citation
Public-domain series where citation is requested
Ambiguous or unknown rights situations
Rather than assuming every series can be treated identically, RESERVE now evaluates available rights information and responds accordingly.
When a series requires prior authorization—or when rights information is insufficiently clear—RESERVE can block access and explain why.
That behavior is intentional.
When rights are uncertain, the safest assumption is not unrestricted use.
Citations Now Travel with the Data
One of the biggest changes in this release is citation-aware output.
Required or requested citation information now flows through RESERVE output formats:
Citation footers in table output
Citation fields in JSON output
Citation text columns in CSV exports
This means attribution information remains attached to the data as it moves between workflows, scripts, reports, and downstream systems.
Instead of treating citations as documentation that users must remember to revisit later, RESERVE keeps attribution closer to the data itself.
Supporting Authorized Access
Not every restricted series should be blocked forever.
Many users legitimately obtain permission to work with copyrighted or restricted datasets.
To support those workflows, RESERVE now includes a local authorization model:
reserve config grant <SERIES_ID>reserve config revoke <SERIES_ID>reserve config list-grants
These commands allow users to explicitly manage locally authorized series while preserving the broader protections introduced by the permissions framework.
The result is a system that balances compliance with practical usability.
Rights Metadata Is Part of the Cache
Permissions are only useful if they remain consistent and available.
Version 1.1.2 introduces local persistence for rights metadata, including support for rebuilding and refreshing the local rights index.
A new cache backfill reset workflow allows users to rebuild rights metadata cleanly when needed:
reserve cache reset-backfill
This ensures compliance information remains available even when working from cached datasets.
Improving Cache Reliability
Alongside permissions work, this release includes significant improvements to cache management and observation retrieval.
RESERVE now:
Selects the widest available observation set when multiple local variants exist
Warns when multiple cached versions of the same series are present
Provides richer cache inventory reporting
Supports targeted cache cleanup by series
Improves visibility into metadata coverage and local data quality
These changes help make local data management more predictable while reducing ambiguity about which observations are being used.
Building Trust Through Transparency
Software often focuses on making data easier to access.
This release focuses on making data easier to use responsibly.
The addition of rights-aware access controls, citation propagation, permissions management, and rights metadata persistence represents an important step in RESERVE’s evolution.
Not because it unlocks a new analytical capability.
Because it acknowledges an important reality: economic data has producers, owners, and usage expectations.
Good tooling should help users respect those relationships.
Version 1.1.2 is RESERVE’s first major investment in that principle.
And it will continue to shape how the platform evolves moving forward.
