What's New

VEKTIS is actively evolving. This page tracks what’s changed with each release — what we shipped, why we built it, and how it helps you get more from your metrics. If something sparks an idea or you’d like to see us take a different approach, we’d love to hear from you.

May 7, 2026 — Native analytics, end to end

Summary

Tracking the impact of your features no longer requires manual measurement entry. If your application already records analytics events — through a tracker SDK or the discover skill that finds them for you — VEKTIS now picks those events up automatically and computes Dev Item metrics on your behalf.

This release closes the loop from “install VEKTIS in your codebase” to “see whether a feature actually moved a metric” without you ever copy-pasting a number into a form. The same loop also surfaces in the product itself: dev items that are not yet wired up are flagged, the dashboard shows the freshly-arriving measurements as they happen, and a setup card walks you through what’s left.

We believe that removing the manual measurement step — and making the gaps visible when something is not yet hooked up — will help teams act on real data sooner instead of putting off measurement work. If a step in the flow feels harder than it should be, we’d love to hear about it.

In This Release

Setting up tracking should be guided, not researched

The problem: Installing a tracking SDK in an unfamiliar codebase usually means reading installation guides, hunting for a credential, deciding where init code belongs, and figuring out how to keep that credential out of source control. That’s a lot of context to carry before you’ve measured anything.

What we’re doing about it: A set of customer-facing skills walks you through every install step with diff confirmations, and a browser-based sign-in flow means you never need to handle a raw credential.

Customer Claude Code skills

Install the full set with one command: npx @vektis-io/tracker install-skills
vektis-bootstrap runs the full first-time onboarding (install → discover → instrument) end-to-end
vektis-install detects your framework and writes the init code in the right place
vektis-discover sweeps your codebase for existing analytics calls and proposes which to track
vektis-instrument inserts vektis.track() calls at every approved point in one batch
vektis-update re-scans periodically to find features added since your last instrumentation pass
vektis-troubleshoot diagnoses SDK errors against the live error catalog

CLI authentication

Sign in to VEKTIS from your terminal through your browser — the CLI never asks you to paste a credential
A paste-token fallback is available for environments that cannot open a browser
Skills create the credential they need automatically and store it as an environment variable; you never see or copy it

Connecting your features to VEKTIS should not require manual mapping

The problem: For VEKTIS to compute impact, it needs to know which event in your code corresponds to which Dev Item. Doing that mapping by hand for every feature is tedious and error-prone, especially when you have an existing event taxonomy.

What we’re doing about it: Dev Items now expose a feature ID field that ties them to events in your code, and a bulk-create flow handles many features at once.

Dev Item to feature ID mapping

Every Dev Item can be tied to a feature ID — the identifier you (or the discover skill) put in your tracking calls
Once mapped, every event with that ID flows to that Dev Item without further configuration
The mapping is editable from the Dev Item detail page

Bulk feature instrumentation

The instrument skill creates Dev Items for every approved feature in your discover output in one pass
Dev Items come pre-populated with the feature ID, type, and a sensible title
You review one diff covering all insertions instead of approving each call site individually

Once events flow, you should see results without further configuration

The problem: Even with events flowing, the value of VEKTIS only shows up when those events become visible numbers you can act on. Waiting for the first measurement to arrive, knowing whether burn-in is complete, and seeing the trajectory over time all need to be obvious in the product.

What we’re doing about it: A timeline chart, automatic burn-in for new features, and explicit source labels on every measurement make the picture clear at a glance.

Native analytics ingestion

Events tracked from your application reach VEKTIS automatically when their feature ID matches a tracked Dev Item
The platform computes baseline and post-release values without you typing them in

Metric timeline chart

Every Dev Item detail page now shows a chart of measurements over time
Hover a point to see the date, value, and source of that measurement
Spot trends, regressions, and burn-in stabilization at a glance

Automated burn-in for new features

For features that didn’t exist before development, VEKTIS collects your first few automated measurements and uses them as the baseline
A clear indicator on the Dev Item shows when burn-in is in progress versus complete
See Burn-in baselines for the full rationale

Source and details on every measurement

Each measurement now carries a label showing whether it came from a tracking event, a manual entry, or burn-in
Hovering reveals additional details — useful when reconciling unexpected values
The same labels appear on the timeline chart so the provenance of each point is one click away

Knowing whether tracking is healthy should be visible in the product

The problem: “Did I wire this feature up correctly?” should not require leaving the product. If a Dev Item has no events flowing, or your application has feature IDs that don’t match any Dev Item, you should see that the moment it happens.

What we’re doing about it: Three new surfaces flag tracking gaps before they cost you a release worth of data.

Tracking Setup card on Dev Items

Every Dev Item with Impact Tracking enabled now shows a card summarizing whether events are flowing
A built-in “verify events” check polls for incoming measurements so you can confirm setup in real time
See Setting up Impact Tracking for the full first-time flow

“Not tracked” badge on the Dev Items list

Dev Items without Impact Tracking configured display a clear badge so you can spot them at a glance
Click through to configure tracking from the same row

Unmapped Features banner

If your application sends events whose feature IDs do not match any Dev Item, the Dev Items page surfaces them in a banner
Each unmapped feature ID can be promoted into a tracked Dev Item without leaving the page

May 7, 2026 — GitHub-driven Dev Item suggestions

Summary

Every PR you merge can now become a tracked Dev Item without you typing the title. Connect a code repository to VEKTIS, and the platform classifies merged work and proposes Dev Items for the changes worth measuring — leaving you to confirm or skip rather than create from scratch.

This is built for teams that already make decisions in the PR review flow and don’t want to maintain a parallel “what should we track?” workflow. The classification labels each suggestion as a feature, improvement, bug fix, infrastructure change, or documentation change so you can promote only the ones that warrant impact measurement.

We believe that meeting teams where their work already lives — instead of asking them to remember to log it elsewhere — will lift tracking coverage for the work that matters most. If your suggestion stream feels too noisy or too quiet, tell us what you’re seeing.

In This Release

Tracking what you ship should not require remembering to log it

The problem: Most teams know they should track the impact of every meaningful release, but the act of opening VEKTIS and creating a Dev Item for each one falls off the priority list when shipping is busy. Coverage suffers, and so does the picture of overall impact.

What we’re doing about it: A code-repository connection lets VEKTIS read merged PR titles, classify them, and propose Dev Items automatically — turning a manual logging step into a one-click confirmation.

Connect a code repository

Connect a repository through Settings → Integrations
Pick which repository and which branch counts as a release for classification purposes
Connection-status indicators in Settings show whether the integration is healthy

Automatic suggestions from merged work

Merged PRs are classified by type — feature, improvement, bug fix, infrastructure, or documentation
Suggested Dev Items appear in a dedicated Suggestions view in the dashboard
Each suggestion shows the original PR title, a classification, and a link back to the source PR

One-click promote to a tracked Dev Item

Promote any suggestion to a tracked Dev Item — the title, type, and link are pre-populated
Dismiss suggestions that don’t need impact measurement so they don’t reappear
Pre-populated Dev Items can still be edited before saving — the flow is a draft, not a commitment

March 11, 2026

Summary

Tracking development metrics is only useful if you can quickly tell whether things are going well — and trust the data behind that assessment. Until now, VEKTIS gave you the raw numbers, but left it to you to interpret whether a metric was trending in the right direction, whether your measurements were reliable, and how much overall impact your development work was having.

This release focuses on three things: giving you clear signals so you don’t have to interpret raw data yourself, protecting the integrity of the measurements those signals depend on, and making the platform easier to navigate as it grows.

We believe that making metric interpretation automatic and visible — rather than leaving it as a manual exercise — will help teams catch issues earlier and celebrate progress sooner. If you see opportunities to improve how we surface these insights, we’d love to hear from you.

In This Release

Knowing whether you’re on track shouldn’t require digging through data

The problem: Understanding whether your development work is delivering results means clicking into individual dev items, scanning multiple metrics, and mentally aggregating whether things are trending the right way. At the initiative level, there’s been no way to see the bigger picture without doing that work yourself for every dev item underneath it.

What we’re doing about it: Two new capabilities work together to surface clear signals at different levels of detail — so you can start with the big picture and drill down only when something needs attention.

Health Indicators

Show the overall health of each initiative based on how its dev items are performing against their metrics
Performance is weighted directionally — improvements and regressions are scored relative to what “better” means for each specific metric
Navigate to any initiative to see its current health status and quickly identify which ones need attention versus which are on track

VEKTIS Impact Score

Gives each dev item a single score representing the measurable impact of its post-release performance
Metrics are evaluated using a dual-track scoring system — one track for metrics that are improving and another for those that are regressing
Scores are grouped into zones so you can quickly understand the magnitude of impact
View the score on any dev item’s detail page

Your metrics are only as good as the measurements behind them

The problem: Baselines are the foundation of every health indicator and impact score. But early measurements can be volatile, measurement cadences can drift without anyone noticing, and not every metric fluctuation is meaningful. When the underlying data isn’t trustworthy, the signals built on top of it aren’t either.

What we’re doing about it: Three new safeguards work together to protect measurement quality — so you can trust the signals VEKTIS surfaces.

Burn-in baseline freeze

Built for situations where baseline measurements weren’t possible before development — such as entirely new functionality that didn’t exist before or features too complex to measure prior to release
When a dev item is released without baselines, VEKTIS collects your first few post-release measurements and uses them to establish a baseline automatically — so impact scoring can still work even without historical data
While we encourage teams to track baseline data wherever possible — even through indirect measures like time-to-complete-a-task before and after development — burn-in ensures you’re never stuck without a scoring foundation when that isn’t feasible

Measurement regularity warnings

Alerts you when your baseline measurements are being taken at irregular intervals
Prompts you to establish a more regular cadence if timing between measurements is inconsistent
Catching irregularities early helps you build habits that lead to more reliable data over time

Minimum meaningful change

Define the threshold of metric change that actually matters for each dev item
Set this value when creating or editing a dev item
Changes below the threshold won’t be flagged as significant improvements or regressions — filtering out noise so you can focus on real impact

Getting the most out of VEKTIS should be effortless

The problem: As the platform grows with new capabilities, it should be easy to find answers, understand what’s available, and feel oriented — whether you’re a new team member or exploring a feature for the first time.

What we’re doing about it: A combination of documentation, expanded access, and interface refinements designed to reduce friction across the board.

Documentation site

You’re already here — comprehensive guides and reference material are available throughout this site
Browse guides on getting started, managing dev items, working with metrics, and more

Team visibility for all roles

The users list in Settings is now accessible to everyone, not just administrators
See who else on your team is using VEKTIS to make collaboration and communication easier

Interface improvements

Notifications and prompts now use clearer, friendlier language throughout
Clickable elements consistently show a pointer cursor so it’s obvious what you can interact with
Background colors are uniform across all views for a more polished experience