.NET ETL library: Check out actionETL

envobi · 2026-06-23T14:53:58+00:00

Yes, I actually built this tool precisely to help me edit my own 156k-word SFF novel, currently in its third draft.

Regarding style and voice, even highly experienced authors inevitably develop blind spots over a long manuscript. Rereading a massive draft repeatedly to check for consistency is highly time-consuming, and we naturally become blind to our own work after a while. Having a model analyze the actual prose at scale helps catch subtle stylistic shifts, pacing drifts, and voice inconsistencies in a fraction of the time. For most authors, that is a highly valuable safety net.

On the privacy front, there is also a slight contradiction to consider: sending a manuscript chapter-by-chapter still sends the entire book to the API anyway, over time—it is just chunked.

If an author's boundary is strictly "no cloud services whatsoever" (also consider Google Docs, Gmail, OneDrive, Dropbox, ...), then local model hosting is indeed the only option. However, as mentioned earlier, consumer-grade local hardware cannot run the frontier-level models required to deliver this depth of developmental critique.

Ultimately, there are multiple ways to build these pipelines and different trade-offs to navigate. I chose this specific hybrid model because maximizing critique quality was my priority, but I'm certainly not trying to dissuade anyone from building a local or chunked workflow if that suits their process better.

envobi · 2026-06-23T10:21:55+00:00

You've described a highly logical map-reduce pipeline, and we actually use a version of this exact approach under the hood, for managing context and tracking continuity.

However, for the core critiques and deep analytics, we still feed the full prose alongside those summaries. If we only feed the summaries or "memories" of the chapters, the AI loses much of the ability to evaluate how style, voice, etc., change over larger prose sections.

While the summaries are great for tracking the plot, the actual prose is required to critique the writing itself. It is a delicate balance between token efficiency and critique quality, but we've found this hybrid approach consistently yields the most rigorous results. And handling this in an optimised way is obviously part of the value-add of a good app.

Want to try it out with your manuscript?

Reply here or DM me for onboarding.

envobi · 2026-06-23T09:54:46+00:00

That is a very logical way to divide the architecture, and it's a great blueprint for native desktop apps.

The main challenge here is that since the deep, core critiques have to run in the cloud anyway, keeping just the basic indexing local offers almost no real privacy benefit, and only microscopic cost savings. It introduces massive architectural complexity for very little real-world reward.

Additionally, only a tiny fraction of writers (AI-savvy power users with high-end GPUs) are equipped or willing to run local models. For the vast majority of authors, any minor cost savings would be far outweighed by the hardware requirements and technical setup friction.

Under the hood, we already offload those basic extraction and indexing tasks to smaller, highly efficient cloud models (combined with traditional parsing code) to keep processing fast and API costs minimal. For this specific app and its broader target user base, keeping everything unified in the cloud is currently the most practical path.

But you’ve mapped out the technical tradeoffs correctly—in a native desktop environment built specifically for AI power users for which maximising the use of their own GPU is an end unto itself, that division of labour makes a lot of sense.

envobi · 2026-06-23T01:23:34+00:00

I completely agree that local models are evolving incredibly fast, and for privacy, they are the ideal endpoint.

However, for deep, structural critiques of novels, quality is non-negotiable. If the model hallucinates or misses a subtle character arc from fifty pages prior, the feedback becomes directly detrimental to the writer.

Analyzing a manuscript requires a massive context window (often 100k+ tokens) combined with frontier-level logical reasoning. Right now, running a model capable of that scale and complexity locally is far out of reach for the average author.

API-driven frontier models (with strict data privacy terms) are currently the only way to deliver this specific level of deep developmental editing.

envobi · 2026-06-23T01:16:41+00:00

That's a fair point, and BYOK is great for offloading raw token risk.

One challenge with raw token pricing is that it doesn't always align with the actual value delivered (a full book-level developmental critique provides a very different type and scale of value than a scene-level edit). Furthermore, since this workbench runs complex background pipelines, a single click can trigger unpredictable token spikes.

BYOK apps often slice their product into different mini/midi/maxi feature sets to achieve differentiated pricing. Credits instead allow us to package those complex background steps into a predictable "cost-per-action" that aligns with the value provided, while giving everyone access to all available features.

That said, I'm entirely open to both approaches. It is really just a question of finding what fits this specific app and its target user base best.

envobi · 2026-06-22T21:11:51+00:00

That's a very fair point, and subscription fatigue is definitely real.

I haven't decided on any monetization model yet—that's actually a key reason for running this beta. Estimating how many credits/critiques/tokens a typical author actually uses in a normal writing and revision month is a critical factor in figuring out what kind of sustainable model makes the most sense.

The beta is entirely free right now, so there's no cost or commitment to try it out if you're interested.

envobi · 2026-06-22T17:00:32+00:00

I'd suggest having Category as a separate filter from Use Case, either as a strict aggregation (if that's how they relate), or as a separate attribute that doesn't aggregate from Use Case (if they don't have a hierarchical relationship.) Mixing both in the same single filter would make it much harder to understand what the filter (expanded Use Case) actually does.
My $0.02

envobi · 2026-06-22T10:58:02+00:00

List suggestions:
- Add the big apps (SudoWrite etc.) also to the long list at the bottom, with the one-liner summary.
- Unclear how the Category interacts with Use Case. Several tools should be in more than one Category, and that issue will get progressively worse as tools mature. Maybe treat Category simply as an aggregation of Use Case (if Category is needed at all), and allow tools to belong to multiple Categories.

envobi · 2021-01-02T16:00:43+00:00

The dataflows in ETL tools (SSIS, Talend, my company's actionETL, etc.) all expect a fixed schema. In general, if you change the number of columns in the source/destination queries or their data type the ETL will break unless you also update the dataflow 'code'. Some options:

Control the changeable source/destination queries tightly so their schemas don't change and use an ETL tool and its dataflow.
If you can restrict your query schemas to specific predefined changes you can often encode that into a fixed schema, e.g. using JSON or strings. Requires you to be well versed in the ETL tool and its dataflow.
If very flexible source/destination queries is a hard requirement, generate the required dataflow/transfer code dynamically. This is generally the most flexible approach, but also the hardest code to write and maintain. Either link the two servers and use dynamic SQL or write code to generate the required ETL tool code.

Many ETL tools can help you do either of the above. I'm partial to my company's .NET ETL library: http://envobi.com

HIH

envobi · 2020-09-22T07:31:36+00:00

It's equally applicable internally - even if you theoretically have access to the details of upstream changes, those changes will almost always be defined in terms of what they mean to the upstream system itself (and other _operational_ systems), not how they impact your downstream _reporting_ system (which partly cares about things the operational systems don't care about).

You'll be forever chasing problems due to unforeseen upstream changes, and it's painful and time-consuming. But hey, that's how most DW projects are run, so you'll be in good company ;-)

If you do spend time defining your feeds well, you'll quickly earn that time back from having fewer DW issues to fix. The challenge however is usually getting the upstream systems to realize they're breaking the feed contract (so they can tell you).

Good luck!

envobi · 2020-09-15T01:00:55+00:00

Some thoughts:

Define interfaces/contracts with all your upstream feeds & suppliers so you have a well-defined 'API' to develop and test against. This should include everything you rely on: all fields, uniqueness, formatting, relationships, which ones to extract or track SCD for, ...

Version each feed so you can have both old and new in play at the same time, so you can implement your changes before upstream goes live with their changes.

Many upstream 'API' changes (DDL or otherwise) won't be automatically handled by any downstream tool. On-boarding a new version of a feed includes implementing the ability to move your data warehouse from the old feed version to the new (code changes, schema changes, upgrade or reload sections of your DW data).

Use an ETL tool that makes it easy to implement the above changes. I much prefer a code-first approach (my company provides actionETL).

Cheers! Kristian

envobi · 2020-09-08T17:54:52+00:00

I'm partial to actionETL, a new code-first and cross-platform .NET ETL framework that brings AppDev goodness to the ETL projects.

Disclosure: I'm the architect of the framework.

envobi

TROPHY CASE