Charty is a Ruby data visualization library that provides a high-level, seaborn-inspired plotting API over multiple rendering backends. It is not a standalone application or pipeline, but a reusable gem designed for Ruby scripts and Jupyter/IRuby notebooks. The core abstractions are Charty::Table and Charty::Vector, which normalize heterogeneous data sources such as Arrays, Hashes, Daru DataFrames, Numo::NArray, NMatrix, Pandas DataFrames, Arrow tables, ActiveRecord relations, and red-datasets into a common interface. On top of these, plotters such as bar, box, count, scatter, line, and histogram compute mappings, statistics, and confidence intervals, then delegate rendering to a pluggable backend. The main entry points are the high-level Charty.bar_plot/line_plot/scatter_plot methods, the older Charty::Plotter DSL with methods like to_bar and to_curve, and backend-specific notebook integration helpers for inline Matplotlib output. The architecture follows a layered adapter and backend-registry pattern. Table adapters and vector adapters isolate data-source differences; plotters implement chart semantics independent of output format; backends convert normalized plot objects into Matplotlib, Plotly, Gruff, Rubyplot, Bokeh, Google Charts, or UnicodePlots output. The codebase also includes reusable statistical helpers for bootstrap confidence intervals, histogram computation, and percentile-based summaries, as well as a layout system for composing subplots. In practice, the most mature and actively exercised backends are Pyplot (Matplotlib via PyCall) and Plotly, while several other backends remain partial or experimental and raise NotImplementedError for common chart types. The repository is a library rather than a data research pipeline, though it has a strong data-analysis orientation. Its primary use case is exploratory visualization in notebook environments, and it integrates deeply with the Ruby data science ecosystem. The overall design is clean and modular, with genuinely reusable adapter and mapper patterns, but the codebase shows signs of early-stage maturity: numerous TODOs, some obvious typos in backend code, legacy example notebooks using outdated APIs, and incomplete coverage across backends. As a result, it is useful and well-structured for library consumers, but some backends and edge cases should not be relied on in production without verification.