DEV Community: opensource

Did GitHub change license enforcement in pull requests?

Dev Connect — Mon, 24 Aug 2026 06:15:05 +0000

Short answer: Yes. GitHub now enforces open source license policy in pull requests through rulesets, comparing dependency changes against policy, annotating violations, and blocking merges when Active mode requires compliance.

Yes. GitHub moved open source license enforcement into ruleset-based pull request checks for dependency changes. The current model compares the base branch and the pull request branch, evaluates detected licenses against policy, and then either annotates the pull request or blocks the merge when enforcement is active.

The part people miss is scope. GitHub is not talking about every file in a repository or every line of application code. The license compliance feature is about dependencies, package manifests, and the licenses those manifests bring into the tree. GitHub’s docs say the check runs when a pull request changes package manifests and uses dependency graph data, including transitive dependencies.

The enforcement model also changed in a practical way. GitHub documents two modes in rulesets: Evaluate and Active. Evaluate runs license checks and adds annotations without blocking merges. Active adds the requirement to merge only after compliance results pass, so a noncompliant dependency can keep the pull request blocked until the violation is fixed or an exception is approved.

That is the part people often get wrong. GitHub did not simply add a warning banner to pull requests, and it did not make license review a manual-only approval step. The feature is policy-driven, tied to enterprise rulesets, and it can stop the merge when the policy says the dependency is not allowed. The pull request becomes the enforcement point, not just the review surface.

The inconvenient part is that this is not available as a universal GitHub feature for all repositories. GitHub says open source license compliance is in public preview and is available for organizations on GitHub Enterprise Cloud with GitHub Code Security and, in the changelog, for customers with GitHub Advanced Security Code Security licenses. In other words, this is an enterprise governance feature, not a default setting for every public repo.

Another detail people miss is that license compliance is policy plus exceptions. GitHub lets enterprise policy managers approve package, license, or package-pattern exceptions, and those exceptions can be applied at repository or enterprise scope. That means a blocked pull request is not always solved by rewriting code. Sometimes the fix is policy work, and sometimes it is an explicit exception request handled by the people who control the rules.

If you are trying to understand the older behavior, the simplest answer is that GitHub has expanded from showing license information to enforcing license policy in the pull request flow. GitHub has shown repository license metadata for years, but the newer change is enforcement through dependency review, rulesets, and compliance checks that run before merge. That is a real shift from visibility to gatekeeping.

A concrete example makes the change easier to see. Suppose a pull request upgrades a package and pulls in a license your enterprise policy forbids. Under the new workflow, GitHub evaluates that dependency change against the policy, annotates the pull request, and, in Active mode, blocks merging until the dependency is replaced, the policy is changed, or an exception is approved.

If you only want the short version, the answer is yes: GitHub changed license handling in pull requests from display and review into enforced policy checks for dependency changes. The key words are rulesets, dependency graph, annotations, and merge blocking. Those are the pieces that actually changed the workflow.

For teams adopting this, the first step is usually not policy writing. It is checking whether dependency graph data is enabled, whether the repositories are targeted by the right ruleset, and whether the team wants Evaluate mode first or Active mode right away. GitHub’s own setup flow recommends testing enforcement on a pull request that changes dependency manifests, then reviewing the annotations and unresolved violations before turning on stricter blocking.

For readers who build on GitHub but do not administer an enterprise license policy, the practical takeaway is smaller. You may see annotations, blocked merges, or exception requests in pull requests, but those are signs of the enterprise policy layer at work. They are not a general change to how GitHub treats every open source pull request on the platform.

If you want to compare this with your own workflow, DevConnect is a separate place to coordinate testing and shipping work, and its public materials can help with that context. The point here is still the same, though: on GitHub, license enforcement in pull requests is now policy-based and merge-aware, not just informational. https://devconnectplatform.com?ref=devto

FAQ

Is this the same thing as dependency review

No. GitHub’s newer license compliance feature builds on dependency data and pull request checks, but it is described as enterprise policy enforcement through rulesets. It compares dependency changes to policy and can block merges in Active mode, which is more explicit enforcement than a simple review comment.

Does GitHub check licenses in every pull request

No. GitHub says the check runs when a pull request changes package manifests and evaluates dependency changes against policy. That means code-only changes without dependency manifest changes are not the same case, and repositories need the relevant dependency data and ruleset setup for enforcement to work.

Can a blocked pull request still be merged

Not while the Active ruleset requirement is failing. GitHub says unresolved noncompliant dependencies keep the pull request blocked until the dependency is fixed, the policy is updated, or an approved exception resolves the violation.

Who can approve exceptions

GitHub assigns that work to enterprise-level license policy managers. They review pending requests in enterprise security views and can approve package, license, or package-pattern exceptions at repository or enterprise scope.

Is this feature available to every GitHub user

No. GitHub documents it for GitHub Enterprise Cloud customers with GitHub Code Security or GitHub Advanced Security Code Security licenses, and it is in public preview. That makes it an enterprise feature with change risk, not a universal default.

Frequently asked

Is this the same thing as dependency review

Does GitHub check licenses in every pull request

Can a blocked pull request still be merged

Who can approve exceptions

Is this feature available to every GitHub user

Sources

Originally published at devconnectplatform.com, where it is kept up to date.

ColdFusion Stored Procedures vs Inline SQL: Performance, Security, and Maintainability

Deepak Sir — Mon, 24 Aug 2026 06:07:48 +0000

In ColdFusion you can run your database logic two ways — as inline SQL inside / queryExecute(), or as stored procedures in the database called via with and — and the honest answer to "which is better" is it depends on the query and your architecture, not a universal winner. Stored procedures traditionally win on three fronts: performance for complex, frequently-run queries (the database compiles and caches an execution plan the procedure reuses), security (you grant EXECUTE on the procedure without granting access to the underlying tables, and reduce the SQL-injection surface), and maintainability at scale (business logic centralized in one place, fixable without redeploying the app). Inline SQL wins on flexibility (change a query instantly, iterate fast), transparency (the SQL lives right next to your business logic where you can read it), and version control (it travels with your application code in Git). Crucially, the "stored procedures are always faster" claim is dated — for simple queries the difference is negligible or can even reverse, and both approaches are safe only if parameterized (cfqueryparam for inline, cfprocparam for procs). Most mature ColdFusion apps use both: stored procedures for complex, security-sensitive, or heavily-reused operations, and inline SQL for everything else. This guide compares them fairly across performance, security, and maintainability.
Read More

AI Wrote the Code. You Still Own the Risk: 5 AI Product Engineering Companies I'd Shortlist in 2026

Arjun — Mon, 24 Aug 2026 06:06:43 +0000

Building an application with AI has become dramatically easier.

Shipping one responsibly has not.

A developer can now describe a feature, generate much of its implementation, connect an LLM API, deploy the application, and have something usable surprisingly quickly. That is genuinely valuable.

But I think the AI development conversation has become too obsessed with how quickly software can be created.

My position is the opposite: the more code AI generates, the more disciplined the engineering process around that code needs to become.

AI does not remove engineering responsibility. It increases the amount of software, dependencies, data flows, and automated decisions a team may need to understand.

That is why I would choose a specialized AI product engineering team over a generic app development company for any AI product expected to handle sensitive information, raise funding, pass enterprise procurement, or operate in a regulated industry.

That is my bias, and I think founders should have the same one.

"AI Built It" Is Not a Risk Strategy

One useful analysis of the problem is this discussion of legal risks surrounding AI-built applications.

The broader engineering point is more important than the headline.

Using AI during development does not make the people and organizations deploying the software disappear from the accountability chain.

If an application leaks customer information, uses software in violation of a license, produces harmful automated decisions, or makes claims that cannot be supported, saying that an AI coding assistant generated the implementation is unlikely to solve the underlying problem.

The interesting question for developers is therefore not:

Did AI write this code?

It is:

Can the engineering team explain where the code, data, models, dependencies, and decisions came from?

That distinction becomes increasingly important as AI moves from coding assistant to active participant across the software development lifecycle.

AI-Generated Code Creates a Provenance Problem

Traditional engineering already has dependency risk.

AI adds another layer.

An engineer normally knows whether a package came from npm, PyPI, Maven, GitHub, or an internal repository. There is usually a manifest, version, license, and dependency tree to inspect.

AI-generated code can make provenance less obvious.

A coding assistant might produce a function that looks perfectly ordinary. The developer may modify it and commit it without knowing whether similar code existed in its training data.

That does not mean every AI-generated snippet is automatically a copyright violation. It also does not mean that encountering copyleft code magically converts an entire proprietary application into open source. License obligations depend on the actual license, distribution model, copied material, and circumstances.

But it does mean engineering teams need to stop treating generated code as inherently clean code.

The U.S. Copyright Office has also maintained the importance of human authorship when considering copyright protection for AI-generated material. Human creative contribution can be protected, while merely prompting a system is not enough by itself.

For software teams, the practical response should be boring engineering discipline: code review, dependency scanning, Software Bills of Materials where appropriate, license checks, source-control history, and documented human approval.

Boring is good when lawyers arrive.

Privacy Risk Is More Interesting Than Prompt Quality

Developers spend enormous amounts of time improving prompts.

I think many teams should spend more time drawing data-flow diagrams.

Imagine an AI support application.

A customer enters personal information. The application sends some of it to an orchestration service. That service retrieves account information. The resulting context goes to an external model API. Logs are stored by another provider. Observability data goes somewhere else.

Suddenly, "the chatbot" is six systems.

Engineering leadership should be able to identify what information each system receives, how long it keeps it, whether it is used for model training, who can access it, and what happens when a customer requests deletion.

That is an architecture problem before it becomes a legal problem.

NIST's Generative AI Profile similarly treats AI risk management as something that should operate across the AI lifecycle rather than as a final compliance exercise.

I Would Not Let AI-Generated Code Bypass the Normal SDLC

There is a strange double standard emerging in software teams.

A junior developer submits 500 lines of unfamiliar code, and everyone expects review.

An AI assistant generates 500 lines in thirty seconds, and suddenly speed becomes the argument for merging faster.

That makes no sense to me.

AI-generated code deserves at least the same scrutiny as human-written code, and sometimes more.

Security scanning should still happen. Tests should still happen. Threat modeling should still happen for sensitive features. Architecture decisions still need owners. High-impact AI outputs need human override paths. Models and third-party APIs need approval policies.

The goal should not be slowing down AI-assisted development.

The goal should be moving governance into development.

When that happens, a security or compliance review stops becoming an emergency two days before an enterprise launch.

What Would I Look for in an AI Product Engineering Company?

This is where my opinion becomes even more opinionated.

I would not prioritize the company that promises the fastest AI MVP.

There are now hundreds of teams capable of creating a convincing LLM demonstration.

I would prioritize the team that can explain how it takes that demonstration through architecture, model evaluation, security, privacy, QA, observability, deployment, governance, and ongoing maintenance.

Using those criteria, these are five companies I would consider in 2026.

GeekyAnts: My pick for focused AI product engineering

For a company specifically trying to turn an AI application or AI-generated prototype into a production product, GeekyAnts would be my first shortlist candidate.

The reason is relatively narrow. Its positioning sits closer to product engineering, AI engineering, modernization, backend development, QA, and production delivery than broad management consulting.

Its recent discussion around AI-built application risk also shows attention to provenance, data handling, governance, security, and enterprise review rather than treating AI development purely as prompt engineering.

I would not choose GeekyAnts because it can replace legal counsel. It cannot, and software engineering companies should not pretend otherwise.

I would consider it when the core problem is engineering an AI product that legal and security teams can actually inspect.

Thoughtworks: My pick for engineering rigor

Thoughtworks would rank extremely highly for organizations where software architecture and engineering practices are the harder problem.

Its recent work on moving generative AI beyond prototypes focuses heavily on integration, safety, industrialization, and structured AI-native engineering rather than "vibe coding."

For complex platforms or companies with strong internal engineering organizations, that depth would make Thoughtworks particularly attractive.

EPAM: My pick for large regulated enterprises

EPAM would move higher on my list as organizational complexity increases.

Its AI engineering capabilities explicitly cover production AI platforms, governance, model monitoring, responsible AI, quality engineering, and large-scale software delivery.

A startup might find that level of enterprise machinery unnecessary. A global financial, healthcare, or highly regulated organization may consider it exactly what it needs.

Globant: My pick for AI plus digital product experience

Globant becomes interesting when AI is only one part of a much larger customer-facing digital product.

Its enterprise AI work combines engineering, integrations, AI delivery, and responsible AI practices, which makes it relevant for organizations building AI into broader digital ecosystems rather than standalone experiments.

Accenture: My pick for governance-heavy transformations

Accenture would not be my first choice for a lean founder trying to harden a focused AI MVP.

For a multinational organization that needs technology delivery tied into cybersecurity, compliance, governance, organizational policy, and enterprise transformation, however, its scale becomes an advantage.

Its responsible AI work clearly treats privacy, security, auditability, human oversight, and legal requirements as part of deploying AI applications.

This is not an objective ranking of company size, revenue, or overall capability. It reflects one narrow question: who would I consider when the problem is getting AI software safely from prototype into serious production?

The Cheapest AI Build May Become the Most Expensive One

This is ultimately why I take the specialist side.

A generic development company may be perfectly capable of generating an AI MVP.

That is not the bar anymore.

The harder questions arrive later.

Can someone identify every external model receiving customer information? Can the company prove which dependencies and licenses shipped? Are model outputs evaluated before releases? Can high-risk decisions be overridden? Are prompts and model versions traceable? Can an enterprise security team understand the architecture? Does someone actually own each AI feature after deployment?

If those answers do not exist, a team does not have an AI governance problem.

It has an engineering problem that has not failed publicly yet.

My opinion is that AI product engineering is becoming its own specialization, much like security engineering or platform engineering.

The winners will not be the teams generating the most code.

They will be the ones that can still explain, test, secure, and own that code after the novelty of generating it has disappeared.

And that is why, for a serious AI product, I would choose specialist engineering over cheap AI development almost every time.

Marker and Surya are Apache 2.0 — their model weights are not

toolfreebie — Mon, 24 Aug 2026 06:02:22 +0000

If you pick an OCR library by glancing at the license badge on its GitHub page, these two will catch you out.

Marker and Surya (both from Datalab) show Apache-2.0 in GitHub's sidebar, and that is accurate — for the code. The model weights are under a separate licence: a modified AI Pubs Open Rail-M, free for research, personal use, and startups under $5M in funding or revenue. Past that line you need a commercial licence from Datalab. Both projects say so plainly in a "Commercial usage" section of their README; it just isn't what the badge reports, and the badge is what most roundups copy.

The distinction matters because the badge is doing the opposite of its job here. Apache 2.0 on the repo tells you that you may use, modify and redistribute the code. It says nothing about your right to run the weights in a product — and without the weights the code does not do OCR.

One thing worth flagging if you are reading older comparisons: Marker used to be GPL-3.0 with a $2M cap. It has since relicensed the code to Apache 2.0 and both projects now sit at $5M. So a post from six months ago can be wrong in your favour or against it, in either direction. Check the README and the LICENSE file, not a table someone else compiled.

If you need something with no revenue test at all, Docling is MIT, and Tesseract, olmOCR, PaddleOCR and RapidOCR are all Apache 2.0 end to end.

Fuller comparison of the OCR options, hosted and self-hosted: https://toolfreebie.com/free-ocr-api-pdf/

I mapped India's public financial data endpoints so you don't have to

Satwik Basu — Mon, 24 Aug 2026 05:57:50 +0000

Indian financial market data can cost companies lakhs of rupees every year.

But a lot of the underlying data is already publicly available.

The expensive part isn't always the data itself. It's figuring out where it lives and how to reliably consume it.

If you've ever tried building something around Indian financial data, you've probably encountered the same problems: undocumented endpoints, APIs with strange headers, inconsistent file formats, identifier changes, historical gaps, and datasets spread across different public sources.

I've spent a lot of time digging through those problems.

So instead of keeping the findings in a pile of scripts and notes, I mapped the endpoints I could find and open-sourced them.

What's in the repository?

The repository currently documents public endpoints covering several areas of Indian financial data.

Mutual fund NAV data

Around 14,000 mutual fund schemes with more than 18 years of NAV history.

There are also parameterized APIs for retrieving historical NAV timelines.

Expense ratios

Daily Total Expense Ratio (TER) data, broken down across the available regulatory expense components.

NSE index data

Historical valuation metrics including:

PE
PB
Dividend yield

The dataset covers 140+ NSE indices.

There's also historical Total Return Index (TRI) data for Nifty indices.

Industry AUM

Industry-wide mutual fund AUM statistics going back to 2009.

Corporate shareholding

Corporate shareholding data sourced from public iXBRL disclosures.

The goal isn't to build another financial-data product.

It's to make the underlying discovery work easier for developers building things on top of public data.

The interesting part: the data has traps

Finding an endpoint is only the beginning.

While mapping these sources, I ran into several things that could quietly cause problems in production.

Historical discontinuities

Some datasets have historical discontinuities around April 2019.

If you're building a long-term time series, you can't blindly assume that the data behaves consistently across the entire history.

Files that lie about their format

Some files claim to be one format while actually containing data in another.

That can be particularly annoying when you're writing automated ingestion pipelines that trust file extensions or content types.

Fund identifiers aren't always stable

Mergers, rebranding and other changes can make fund identifier mappings surprisingly messy.

If you're maintaining historical data, you need to account for those relationships rather than treating every identifier as permanently immutable.

The one-header problem

Here's one of my favorite examples.

There's a public corporate shareholding endpoint that appears to reject automated requests.

You might assume there's authentication, some elaborate anti-bot mechanism, or another access restriction involved.

In one case, the problem was simply the Origin header.

Remove it and the request works.

That's it.

One HTTP header was the difference between "this endpoint doesn't work" and getting the data immediately.

Why I open-sourced this

I've had to spend hours figuring out things that probably shouldn't take hours to figure out.

And I know I'm not the only developer doing it.

Someone building a portfolio tracker shouldn't have to spend days reverse-engineering network requests just to discover where historical data comes from.

Someone building a quantitative research tool shouldn't have to rediscover the same identifier mappings.

Someone building a fintech prototype shouldn't have to start from zero because the documentation around a public endpoint is scattered or nonexistent.

So I decided to put the findings in one place.

The repository is MIT licensed, so you can use it as a starting point for projects involving:

Indian fintech
Wealth management
Quantitative research
Portfolio tracking
Market analytics
Financial data pipelines

There are probably still gaps.

That's intentional.

I mapped what I could find, documented the behavior I encountered, and would rather have other developers extend it than keep trying to maintain a private collection of scripts.

One less thing to reverse-engineer

The data was public.

The documentation wasn't.

That's the problem I'm trying to solve with this repository.

If you're building something around Indian financial data, hopefully this saves you a few days of digging through network requests and figuring out why an otherwise perfectly reasonable API request gets rejected because of one header.

Repository: https://github.com/satwikbasu

If you know of other undocumented Indian market-data endpoints, PRs and contributions are very welcome.

Your license scanner is answering the wrong question

Ryosuke Aoki — Mon, 24 Aug 2026 05:56:30 +0000

Run a license scanner over a typical Node or Python project and you get a table:
package, license, risk level. GPL-3.0 comes back red. MIT comes back green.
MPL-2.0 comes back yellow, probably.

That table is answering a question nobody asked, which is "is this license
scary?" The question you actually have is "does this obligate me to do
something?" — and for a large fraction of licenses, the honest answer is: it
depends on facts the scanner never asked you about.

Copyleft obligations attach to events, not to code

Read GPL-3.0 looking for the trigger and you find it in section 5: the
requirement to license the whole work under the same terms and make
corresponding source available applies when you convey the work. Conveying
is distribution. If you never distribute, the obligation never fires.

So consider a hosted SaaS product with a GPL-3.0 library in node_modules,
running on your own servers, with users reaching it over HTTPS.

You have not distributed anything. Nobody received a copy. The obligation does
not arise.

Your scanner said red.

Now consider the same library, same version, same lockfile, in a desktop app you
ship to customers. Distribution. The obligation fires, and it fires on the
whole work — your proprietary code included.

Your scanner said red. Same red. Same shade of red.

One of those two answers was useless. The scanner had no way to tell them apart,
because it never asked how the software reaches its users.

The AGPL exists precisely because that gap is real

The Free Software Foundation noticed the SaaS hole and wrote a license to close
it. AGPL-3.0 section 13 adds an obligation the GPL does not have: if users
interact with a modified version over a network, you must offer them the
corresponding source of the whole work.

That single clause is the entire practical difference for a hosted service:

	Hosted SaaS	Distributed binary	Internal only
GPL-3.0	no obligation	obligation fires	no obligation
AGPL-3.0	obligation fires	obligation fires	no obligation

Two licenses that most tools file under the same "strong copyleft, high risk"
heading, producing opposite answers for the deployment model most companies
actually use.

And note the third column. For internal-only software — an internal dashboard,
a build tool, something that never leaves the company — neither license
obligates you to disclose anything. Not because of a loophole, but because
neither distribution nor network interaction with outside users ever happens.

Dev dependencies are a different question entirely

This one causes more unnecessary panic than anything else.

If a GPL-3.0 package appears in your lockfile as a dev dependency — a test
runner, a linter, a bundler — it is not part of the artifact you ship. No
distribution of that package occurs. No obligation arises.

The caveat worth stating out loud: tools that emit code into your output are
a separate case. A code generator whose templates land in your shipped source is
not the same as a linter that only reads your source. Worth checking
individually rather than assuming.

Most scanners flatten this too. dependencies and devDependencies are right
there in the manifest, distinguished by the ecosystem itself, and the report
still shows one risk column.

Not every license works this way

It is worth being precise about which licenses this distinction actually
changes, because "it depends" is not useful if it applies to everything.

It changes the answer for: GPL, AGPL, LGPL, and the source-available
licenses like SSPL and BUSL — anything whose trigger is a distribution or
network-interaction event.

It does not change the answer for: MIT, Apache-2.0, BSD. Permissive licenses
ask for attribution and not much else, in every model. Apache-2.0 adds a patent
grant and a NOTICE requirement, which are obligations, but they do not vary by
how you ship.

MPL-2.0 is the interesting middle. Its copyleft is per file, not per
project. Files it covers stay under it and their modifications must be
published; your own files carry whatever terms you choose. It treats static and
dynamic linking alike. So the shipping model barely matters — but for a reason
that is the opposite of the permissive case: the obligation is real, it is just
scoped narrowly enough that it does not reach your code.

Three genuinely different mechanisms. One risk column cannot represent them.

Linkage is the second axis

For compiled languages there is a further fact the manifest does not tell you.

LGPL's whole design is that you may use the library in a proprietary work
provided the user can replace it — which dynamic linking gives you almost for
free, and static linking does not. In Go and Rust, static linking is the
default. So the same LGPL dependency has a materially different answer in a Rust
binary than in a Node application, and nothing in Cargo.lock says so.

What to do about it

Nothing exotic. When you look at a license question, fix three facts first:

How does this reach users? Hosted, distributed binary, delivered to a customer's environment, internal only, or published as a library.
Is it in the shipped artifact? Runtime or dev-only.
How is it linked? Static or dynamic — only matters for compiled languages and only for a few licenses.

With those three fixed, most "it depends" answers collapse into one answer. Not
a risk score — an actual yes or no, with the clause that produced it.

That is also the honest reason a scanner cannot do this for you out of the box:
two of those three facts are not in your repository. They are facts about your
business.

I got annoyed enough at re-deriving this by hand that I built a small free tool
that takes the shipping model as an input and gives the per-model answer with
the clause behind it: https://licenseguard.tenchorooms.com. It also runs as an
MCP server if you want your coding agent to stop guessing at this. Source is
Apache-2.0 on GitHub.

Not legal advice. It tells you which clause is implicated and why, which is the
part that is mechanical. Whether it applies to your situation is not.

How SmartKey Keeps Two Alphabets Alive Until Context Decides

Ruslan Manov — Mon, 24 Aug 2026 05:55:15 +0000

The input event does not arrive with a language tag.

Press the same two physical keys on a Bulgarian phonetic keyboard and one interpretation is li; the other is ли. Both are plausible prefixes. One can be the beginning of like. The other can already be a complete Bulgarian word.

Most desktop input systems avoid this ambiguity by asking the user to maintain a global mode: English now, Bulgarian later. The engineering is simple. The human cost appears when the mode and the thought diverge. A forgotten toggle turns a sentence into cleanup work.

SmartKey explores a different contract: keep both alphabets alive long enough for evidence to decide.

Its North Star is:

Write the thought, not the keyboard layout.

This article is the technical companion to the project's narrative overview. It focuses on what an input engine designer can learn from the architecture, its current evidence, and the failures that refuse to fit under one convenient label.

1. Start before autocorrect

Autocorrect begins with committed text and asks whether another string was intended. A dual-alphabet input engine has an earlier problem: what characters should the physical keys become in the first place?

SmartKey maintains two candidate readings for the current word. Conceptually, the loop looks like this:

for each eligible physical key:
    extend the English candidate
    extend the Bulgarian candidate
    score both using available local evidence

    if the winner changes before the decision is locked:
        update the visible composing prefix

    if the evidence crosses a lock boundary:
        lock the current winner for further scoring
        keep the word in preedit until the boundary

This is pseudocode, not a copy of the Rust implementation. The useful design idea is delayed commitment. The engine can expose a current best answer in composing preedit without pretending that early evidence is final.

That distinction matters because the shape of evidence changes during a word. At the first character, context may be more informative than corpus frequency. After several characters, a prefix can become distinctive. At a delimiter, the token is no longer merely a prefix; exact-word and phrase evidence become available.

One scoring rule should not be assumed optimal at all three moments.

2. Prefix evidence is not word evidence

The smallest reproducible example is li versus ли.

In the audited corpus snapshot behind this draft, the strongest English completion for li… was represented about 2.57 million times. The strongest Bulgarian completion for ли… was close, at about 2.51 million. A prefix-based contest is therefore nearly balanced and can tip toward English.

But at the exact-word boundary, the evidence is radically different: standalone Bulgarian ли appeared about 2.51 million times, while standalone English li appeared about 18 thousand times.

The numbers are corpus-specific and rounded. Their value is not the apparent precision. Their value is the diagnostic question they expose:

During the token: “Which candidate has the strongest continuation?”
At the delimiter: “Which candidate is the word the user just completed?”

If the engine keeps asking the first question after Space arrives, it is solving the wrong problem correctly.

This suggests a general rule for predictive interfaces: boundaries are semantic events. A delimiter, submit action, focus change, or explicit acceptance can reveal evidence that did not exist one event earlier. Test boundary behavior separately instead of treating it as the last iteration of the same loop.

3. Context is an input contract, not application telepathy

It is tempting to summarize context handling as “the keyboard knows it is in a terminal.” SmartKey does not make that claim.

The engine can use three bounded signals:

surrounding text that the client exposes;
the ContentType the client declares;
an inferred typing regime derived from available input evidence.

In the FastCoding regime, technical vocabulary can influence prediction. It is ranking evidence, not a guarantee that every identifier or command will remain untouched.

Sensitive fields have the same contractual boundary. SmartKey bypasses fields whose clients correctly publish a sensitive ContentType. It cannot promise a universal password shield when a client fails to declare that property.

This is an important architectural habit: name the source of context. “The application tells me X” and “I inferred Y from text” have different failure modes, security properties, and test fixtures.

4. Acceptance is a state transition

A visible completion creates another decision boundary. SmartKey supports deliberate acceptance paths such as Tab and Right Arrow, with Escape available to reject.

Space is attractive because it is already the natural end-of-word gesture. It is also dangerous. An input method may have to replace a partial token, commit a completion, preserve its alphabet, and deliver exactly one delimiter without leaking an intermediate state.

The Space-accept path is therefore still experimental. Its feature flag is off, and a newly discovered Unicode-eligibility issue is a release blocker. It is not a shipped capability in this article.

The design lesson is broader than this feature: never model acceptance as a convenient key binding. Model it as a transaction with eligibility, commit, cancellation, and fallback semantics. If eligibility fails, Space must remain ordinary Space.

5. Local prediction still uses a model

SmartKey keeps corpus scoring, contextual ranking, and personal adaptation on the machine. There is no LLM or remote model in the prediction loop.

That wording is deliberate. “No model” would be false: ranking candidates is a model, even when the implementation is compact and inspectable. “No data” would also be misleading: local corpus and personal adaptation are data.

Feedback needs the same precision. Accepted candidates can reinforce useful behavior. Repeated rejections can suppress a suggestion. If an accepted completion is followed by Backspace within 500 milliseconds, the event is recorded as negative feedback. The system does not need to label the user's emotion; it needs a bounded observation that a test can reproduce.

For input software, local processing is not only a privacy feature. It also makes behavior easier to replay against a fixed corpus and exact revision.

6. Debug the decision without logging the sentence

An input engine can be wrong at every keystroke. Plaintext logs would make diagnosis easy and create an unacceptable record of what the user typed.

SmartKey's compromise is a structural per-keystroke receipt without plaintext. In structural mode, it records the input/script class, consume-or-forward verdict, dual-buffer and lock/hypothesis state, action name, payload or commit length, and—on commits—the typed and committed script classes.

These fields are enough to inspect state transitions and dispatched action kinds without saving plaintext. They do not by themselves reveal candidate text or corpus support.

At the combined revision behind this draft, the recorded verification gate passed 496 core tests, focused suites of 9, 5, and 20 cases, and seven native scenarios. Those tests describe one revision; they are not an accuracy measurement and do not erase the Unicode blocker in the experimental Space path.

7. One symptom, three failure lanes

In one diagnostic session, nine tokens in a roughly 45-word Bulgarian instruction surfaced in the wrong form. That is one diagnostic session, not a benchmark or an accuracy percentage.

Two isolated examples teach different lessons:

no, intended as Bulgarian но, reaches a delimiter while the engine still has a short-word ambiguity.
statiq, intended as статия, can be pulled toward Latin by strong stat… prefix evidence before the Bulgarian word is complete.

Other observations involve loanwords, product names, abbreviations, out-of-vocabulary forms, punctuation, or ordinary typos. A surface string cannot prove which mechanism produced it. That requires the receipt and an exact replay.

The next design work should therefore be split rather than hidden inside a mega-fix.

Lane A — short words at the delimiter

For ambiguous two- and three-character tokens, evaluate exact-word frequency, language prior, and phrase context when the delimiter arrives.

RED tests should include:

Bulgarian short words after Bulgarian context;
genuine English short words after English context;
a language switch immediately before the token;
punctuation and end-of-input as boundaries, not only Space.

Lane B — premature prefix lock and unsupported inheritance

Test when a strong completion prefix can lock the wrong alphabet before the intended word has enough evidence. Separately test the case in which the nominal winner has zero support: it should not inherit a previous choice merely because a state variable already has a value.

The exact fallback policy still needs evidence. The important step is to make “no support” an explicit state rather than silently treating it as confidence.

Lane C — OOV, brands, abbreviations, and typos

Loanwords and brand names cross the boundary between preservation and correction. A typo can make both corpus candidates unsupported. Punctuation can belong inside a technical token rather than terminate it.

These cases need their own fixtures and success criteria. Solving Lane A must not be advertised as solving Lane C.

8. What to take into another input engine

SmartKey's validated integration here is Linux with IBus, Bulgarian and English, in the author's own daily use. It is not a Windows or macOS delivery claim, a multi-user field study, or evidence of perfect language selection.

The reusable engineering principles are more important than the platform boundary:

Preserve competing interpretations until an irreversible decision is justified.
Re-evaluate at semantic boundaries; a complete word is not merely a longer prefix.
Distinguish declared context from inferred context.
Treat completion acceptance as a transaction.
Collect falsifiable structural evidence without storing plaintext.
Split failures by mechanism before designing the fix.

A predictive system earns trust when its behavior is not only fast or often correct, but bounded, reversible, and explainable when wrong.

The SmartKey repository is here: https://github.com/RMANOV/smartkey

Canonical project story: https://www.linkedin.com/pulse/fractured-console-two-alphabets-one-stream-thought-ruslan-manov-m3jvf/

Bring a reproducible boundary case. For this kind of engine, the most valuable input is the word that forces the scoring model to reveal what question it was really asking.

Building an Open-Source, Zero-Knowledge DocSend Alternative with React 19 and Supabase

Roushan kumar — Mon, 24 Aug 2026 05:45:47 +0000

Why We Built DocTransfer

Sharing sensitive documents like pitch decks, financial reports, or legal contracts shouldn't require paying $250+/month for platforms that store your unencrypted files on their servers.

We built DocTransfer (and open-sourced it on GitHub) as a privacy-first, client-side encrypted document sharing and Virtual Data Room (VDR) platform.

Zero-Knowledge Cryptography Architecture

Most document-sharing services encrypt files at rest on their cloud storage. That means their backend servers - and anyone with access to them - can view your raw documents.

In DocTransfer, encryption happens entirely on the client before the payload leaves your browser:

Client-Side OpenPGP & AES-256-GCM: Files are encrypted in the browser using the WebCrypto API and OpenPGP.js.
Zero-Knowledge Key Handling: Encryption keys are kept in URL hash fragments (#key=...), which are never sent to our servers.
Dynamic Forensic Watermarking: Recipient email overlays are rendered dynamically on the canvas layer, preventing unauthorized screenshots and distribution.

Tech Stack & Key Features

Frontend: React 19, TypeScript, Vite, Framer Motion
Database & Auth: Supabase (PostgreSQL with strict Row-Level Security, Edge Functions, Storage)
Document Processing: pdf-lib, react-pdf, pdfjs-dist
Security & Signatures: OpenPGP.js, SimpleWebAuthn (Biometric sign-in), Digital Certificate generation
Analytics: Real-time page-by-page engagement heatmaps & viewer telemetry

Try It & Contribute

Live App: doctransfer.app
GitHub Repository: github.com/simplegithubs/DocTransfer3949

We would love to get your feedback on the client-side encryption flow, PDF rendering optimizations, and general user experience!

Self-Hosted Customer Support & Helpdesks in 2026: Chatwoot vs FreeScout vs Helpy

Elder Fernandes — Mon, 24 Aug 2026 05:45:34 +0000

Self-Hosted Customer Support & Helpdesks in 2026: Chatwoot vs FreeScout vs Helpy

Delivering exceptional customer support is essential for growth, but commercial helpdesk platforms enforce punitive pricing models:

Per-Agent Seat Taxes: Intercom, Zendesk, and Front charge $49 to $119+ per agent per month. As your support and engineering teams grow, licensing costs quickly spiral into tens of thousands of dollars annually.
Add-On Paywalls: Essential capabilities like WhatsApp integration, SMS channels, unlimited email history, and custom webhooks are locked behind enterprise tiers.
Customer Data Privacy: Confidential customer conversations, billing inquiries, and personal data are held on third-party multi-tenant servers.

Self-hosting an open-source support helpdesk gives your team unlimited agent seats, unified omnichannel inboxes (Live Chat, WhatsApp, Email, Telegram, Social), full webhook customization, and complete data ownership on your own VPS.

In this guide, we evaluate the top three self-hosted support and ticketing platforms in 2026: Chatwoot, FreeScout, and Helpy.

The Landscape: Comparative Breakdown

Feature / Capability	Chatwoot	FreeScout	Helpy
Core Paradigm	Modern Omnichannel Live Chat + Shared Inbox	Clean Shared Email Inbox (Help Scout Alternative)	Traditional Support Ticketing & Knowledge Base
Technology Stack	Ruby on Rails, Vue.js, PostgreSQL, Redis	PHP (Laravel), MySQL/PostgreSQL, Vue	Ruby on Rails, PostgreSQL
Supported Channels	Web Live Chat, Email, WhatsApp, Telegram, Facebook, SMS	Email Inboxes, Webhooks, Community Modules	Email Ticketing, Public/Private Help Center
Bot & AI Integrations	Native Webhooks, Rasa, Dialogflow, OpenAI	Modules available for automation & canned replies	Automated workflows & AI taggers
Mobile Applications	Official iOS & Android Apps	Mobile Web / PWA / Community Apps	Mobile responsive web UI
Hardware Overhead	Moderate (2 vCPU, 4GB RAM)	Ultra-Lightweight (1 vCPU, 1GB RAM)	Lightweight (1-2 vCPU, 2GB RAM)
Best Used For	Real-time website chat, omnichannel SaaS support	Shared team email management, agency ticketing	Classic IT helpdesks and knowledge base portals

Explore full feature comparisons and alternative tools at: SelfHostStack Zendesk Alternatives.

1. Chatwoot: The Modern Intercom & Crisp Alternative

Chatwoot is an open-source, omnichannel customer engagement suite. It unifies live website chat widgets, email support, WhatsApp business numbers, and social channels into a single real-time collaborative dashboard.

Standout Capabilities

Embeddable Live Widget: Customizable JavaScript widget with automated greetings, offline forms, and pre-chat surveys.
Multi-Brand & Multi-Team Routing: Route inquiries by department (Sales, Billing, Technical) with automated assignment rules.
Rich Mobile Ecosystem: Official native apps for iOS and Android allowing team members to resolve customer queries on the go.

Production Chatwoot Docker Compose Architecture

version: "3.8"

services:
  chatwoot_web:
    image: chatwoot/chatwoot:latest
    container_name: chatwoot_web
    restart: unless-stopped
    depends_on:
      - postgres
      - redis
    environment:
      - NODE_ENV=production
      - RAILS_ENV=production
      - INSTALLATION_ENV=docker
      - SECRET_KEY_BASE=${SECRET_KEY_BASE}
      - FRONTEND_URL=https://support.yourdomain.com
      - POSTGRES_HOST=postgres
      - POSTGRES_DATABASE=chatwoot_production
      - POSTGRES_USERNAME=chatwoot
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - REDIS_URL=redis://redis:6379
      - MAILER_SENDER_EMAIL=support@yourdomain.com
      - SMTP_ADDRESS=smtp.resend.com
      - SMTP_PORT=587
      - SMTP_USERNAME=resend
      - SMTP_PASSWORD=${SMTP_PASSWORD}
    entrypoint: docker/entrypoints/rails.sh
    command: ['bundle', 'exec', 'rails', 's', '-p', '3000', '-b', '0.0.0.0']
    ports:
      - "127.0.0.1:3000:3000"

  chatwoot_worker:
    image: chatwoot/chatwoot:latest
    container_name: chatwoot_worker
    restart: unless-stopped
    depends_on:
      - postgres
      - redis
    environment:
      - NODE_ENV=production
      - RAILS_ENV=production
      - INSTALLATION_ENV=docker
      - SECRET_KEY_BASE=${SECRET_KEY_BASE}
      - FRONTEND_URL=https://support.yourdomain.com
      - POSTGRES_HOST=postgres
      - POSTGRES_DATABASE=chatwoot_production
      - POSTGRES_USERNAME=chatwoot
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - REDIS_URL=redis://redis:6379
    entrypoint: docker/entrypoints/rails.sh
    command: ['bundle', 'exec', 'sidekiq', '-C', 'config/sidekiq.yml']

  postgres:
    image: postgres:16-alpine
    container_name: chatwoot_postgres
    restart: unless-stopped
    volumes:
      - chatwoot_pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=chatwoot_production
      - POSTGRES_USER=chatwoot
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}

  redis:
    image: redis:7-alpine
    container_name: chatwoot_redis
    restart: unless-stopped
    volumes:
      - chatwoot_redisdata:/data

volumes:
  chatwoot_pgdata:
  chatwoot_redisdata:

2. FreeScout: The Ultra-Lightweight Help Scout Clone

FreeScout is built on PHP/Laravel and delivers an exceptional shared email inbox experience. If your customer support workflow is primarily email-centric (e.g. support@yourdomain.com), FreeScout offers near-zero memory footprint (under 300MB RAM) and blazing-fast response speeds.

Standout Capabilities

Effortless Email Threading: Seamlessly parses incoming IMAP/POP3 emails and sends outbound replies via SMTP.
Collision Detection: Prevents two team members from accidentally answering the same customer ticket simultaneously.
Low Resource Profile: Easily runs on a $3.50/mo VPS alongside existing web workloads.

Production Best Practices for Self-Hosted Support

Transactional Email Reliability: Connect your self-hosted helpdesk to a reliable SMTP relay (such as Amazon SES, Resend, or Stalwart) to guarantee 100% inbox deliverability.
Automated Database Backups: Schedule daily WAL and snapshot backups with pgBackRest or restic to an offsite S3 bucket.
Webhook Integrations: Forward new urgent tickets to internal Slack/Discord channels using n8n or native webhook notifications.

Which Solution Should You Choose?

Choose Chatwoot if you need real-time website live chat, mobile support apps, and multi-channel messaging (WhatsApp, Telegram, Live Chat).
Choose FreeScout if your support operations revolve around shared email inboxes and you want minimal RAM usage on a tiny VPS.
Choose Helpy if you require classic ticketing workflows combined with a self-hosted multilingual knowledge base.

Looking for pre-configured, production-hardened Docker stacks with Traefik SSL and automated backups?

Check out the Self-Hosted Starter Stack Pack ($29) — save hours of deployment time and run enterprise-grade self-hosted infrastructure.

Self-Hosted Session Replay & Product Observability in 2026: OpenReplay vs PostHog vs Highlight.io

Elder Fernandes — Mon, 24 Aug 2026 05:45:01 +0000

Self-Hosted Session Replay & Product Observability in 2026: OpenReplay vs PostHog vs Highlight.io

Understanding how users interact with your web application is critical for UX optimization and debugging edge-case frontend errors. But commercial session replay and heatmap services create immense operational challenges:

Exorbitant Pricing Curves: Services like FullStory, Hotjar, and LogRocket charge hundreds to thousands of dollars per month as monthly active sessions grow.
Privacy & Compliance Minefields: Capturing DOM state, form inputs, and customer clicks and transmitting them to third-party US cloud providers triggers strict GDPR, HIPAA, and CCPA regulatory scrutiny.
Data Retention Caps: Proprietary platforms enforce strict 30-day or 90-day retention policies unless you pay enterprise tiers.

By self-hosting your session replay and frontend observability stack, you keep 100% of telemetry on your own infrastructure, achieve zero data leakage, and maintain unlimited recording retention backed by low-cost NVMe or S3 storage.

In this guide, we compare the top three self-hosted session recording and UX debugging platforms in 2026: OpenReplay, PostHog, and Highlight.io.

The Landscape: Feature & Architecture Breakdown

Feature / Architecture	OpenReplay	PostHog	Highlight.io
Primary Focus	Deep Session Replay + DevTools Network/State Inspection	All-in-one Product OS (Analytics + Flags + Replay + A/B)	Full-stack Observability (Session Replay + Errors + Logs)
Backend Engine	Go, Redis, ClickHouse, MinIO/S3, Docker	Python, ClickHouse, Kafka, Redis, PostgreSQL	Go, ClickHouse, Redis, OpenTelemetry
Privacy / Masking	Native DOM Sanitization, CSS Class Obfuscation	Strict Input Masking, Canvas/SVG Redaction	Regex PII Obfuscation, Client-side Masking
DevTools Recording	Full Network Payload, Redux/Zustand State, Console Logs	Console logs, Network timing, Web Vitals	Stack traces, Network requests, Server logs
Hardware Overhead	Moderate (4 vCPU, 8GB RAM minimum)	High (8+ vCPU, 16GB RAM for full suite)	Moderate (4-8 vCPU, 8-16GB RAM)
Storage Backing	ClickHouse + S3-compatible bucket	ClickHouse + S3-compatible bucket	ClickHouse + S3-compatible bucket
Best For	Engineering teams debugging complex frontend apps	Product managers wanting unified telemetry & funnels	Full-stack teams seeking OpenTelemetry error correlation

Explore the complete collection of self-hosted alternatives at: SelfHostStack Alternatives Hub.

1. OpenReplay: The Engineering-First Session Replay Platform

OpenReplay is designed specifically for software engineers. Beyond visual video-like session playback, it reconstructs the exact state of the browser at any second: network requests with headers and payloads, JavaScript console logs, Redux/Vuex state mutations, and Core Web Vitals performance waterfalls.

Key Strengths

Native Privacy Controls: Automatically masks passwords, credit cards, and sensitive input fields. Any DOM node with data-openreplay-masked is scrubbed before leaving the browser.
Fine-Grained Network Inspector: Reproduce API 500 errors and CORS failures exactly as the end-user encountered them.
Omni-channel SDKs: Official support for React, Vue, Angular, Svelte, Next.js, and vanilla JavaScript.

Minimal Production Single-Node Deployment

OpenReplay provides a streamlined CLI deployment for dedicated Ubuntu VPS instances:

# Provision on Ubuntu 22.04/24.04 LTS (Minimum 4 vCPU, 8GB RAM, 50GB NVMe)
sudo apt update && sudo apt upgrade -y
curl -sL https://raw.githubusercontent.com/openreplay/openreplay/main/scripts/helmcharts/openreplay-cli -o openreplay
chmod +x openreplay
sudo ./openreplay -i

2. PostHog: The All-in-One Product Operating System

PostHog combines session recordings with event-based product analytics, feature flags, A/B testing experiments, and user surveys in a single unified dashboard.

Key Strengths

Unified Event Funnels: Click on a drop-off step in a conversion funnel and instantly watch the exact 5 session recordings of users who dropped off.
Feature Flag Correlation: Filter session recordings by enabled feature flags to verify rollout stability.
ClickHouse High-Throughput Storage: Capable of ingesting millions of daily DOM mutations with columnar compression.

Privacy Masking Client Setup (React / Next.js)

import posthog from 'posthog-js';

posthog.init('<YOUR_POSTHOG_KEY>', {
  api_host: 'https://telemetry.yourdomain.com',
  session_recording: {
    maskAllInputs: true,
    maskInputOptions: {
      password: true,
      email: true,
    },
    maskTextSelector: '.sensitive-user-data',
    blockSelector: '.payment-form-container',
  },
});

3. Highlight.io: Full-Stack Error Tracing & Replay

Highlight.io connects frontend session recordings directly with backend distributed traces and application logs using the OpenTelemetry standard.

Key Strengths

Frontend-to-Backend Trace Linking: When a user experiences an error, click from the video replay directly into the backend OpenTelemetry trace and server stack trace.
Lightweight Client Overhead: Optimized WebWorker compression ensuring negligible impact on browser FPS.
Self-Hosted Docker Compose: Simple deployment orchestrated with standard Docker and ClickHouse.

Production Security & Privacy Hardening

Client-Side Sanitization: Always sanitize PII client-side before telemetry packets are transmitted over the wire. Never rely solely on server-side filters.
Reverse Proxy & SSL: Terminate TLS via Traefik or Caddy with HSTS and rate limiting enabled.
Storage Retention Lifecycles: Configure S3 bucket lifecycle rules (or MinIO ILM) to automatically transition or purge session blobs after 60 or 90 days to conserve storage costs.

Conclusion & Architecture Blueprint

Choose OpenReplay if you need deep browser DevTools inspection, Redux state tracking, and engineer-focused bug reproduction.
Choose PostHog if you want a complete product stack combining session recordings, funnels, heatmaps, and feature flags.
Choose Highlight.io if you prioritize end-to-end OpenTelemetry correlation between browser sessions and backend microservices.

Need production-ready, security-hardened Docker Compose files with Traefik SSL and automated backups?

Get the Self-Hosted Starter Stack Pack ($29) — complete with pre-configured observability templates, reverse proxy setups, and automated backup scripts.

Use OpenSpec to Separate Coding, Review, and Verification

fluentdb-dev — Mon, 24 Aug 2026 05:42:18 +0000

Use OpenSpec to Separate Coding, Review, and Verification

ithyno combines a desktop app or VS Code extension with OpenSpec Skills and ithyno Skills. OpenSpec Skills define the change. ithyno Skills assign implementation, review, and verification to separate AI sessions. The app visualizes their progress.

When one coding session is no longer enough

This article is for developers who use coding agents for real feature work. It is not about autocomplete or one-off questions. It focuses on work that no longer fits in one agent session.

You may recognize some of these situations:

The agent starts coding before the expected behavior is clear.
Requirements are scattered across chat history.
The same session writes the code and approves its own work.
A second session reviews the wrong branch or an old diff.
Active changes become a collection of terminals and mental notes.
A process exits, but you do not know if the requested work is complete.

You may want one session to implement a change. Another session can review it. A third session can verify it. These sessions can use the same tool and model. They can also use different ones. The important distinction is the role, not the vendor.

I built ithyno for this workflow.

Start with an agreed specification

Before choosing an agent, first decide what should change.

This is the idea behind spec-driven development.

A chat prompt should not be the only source of requirements. Spec-driven development records the expected behavior before coding starts. The specification becomes a shared agreement. The developer and every agent role can read it.

That changes the workflow from:

prompt → code → hope that the result matches the intent

to:

agree on behavior → plan the change → implement → review → verify

The goal is not documentation for its own sake. The goal is to preserve the original intent. Implementation details should not replace requirements. Agents should not silently add new scope.

What OpenSpec provides

OpenSpec is a lightweight framework for spec-driven development. It is designed for AI coding assistants. The developer and the assistant agree on the change before coding starts.

OpenSpec keeps the current system behavior and proposed changes as files in the repository.

openspec/specs/ describes the current agreed behavior.
openspec/changes/<change-id>/ contains one proposed change.
A change can include a proposal, spec updates, design notes, and tasks.
Completed changes can be archived into the living specifications.

The main files of a change are easy to inspect:

openspec/changes/<change-id>/
├── proposal.md
├── design.md
├── tasks.md
└── specs/

proposal.md explains why the change is needed. tasks.md tracks the work. The specs/ directory records the behavior added or changed. design.md is used when implementation decisions need a separate explanation.

These artifacts are ordinary project files. They are not tied to one chat session. A later session can read the same intent. It does not need to rebuild the context from chat history.

For a closer look at how these files map to the project workflow, see OpenSpec and the ithyno Kanban model.

Turn one OpenSpec change into role-based work

OpenSpec defines the change. ithyno gives that change to separate roles.

OpenSpec change
    │
    ├── code role   → implement the tasks
    ├── review role → compare the result with the proposal and specs
    └── verify role → run the applicable project checks

Each role receives the same change. Each role has a different responsibility.

Code

The code worker reads the proposal, spec changes, and tasks. It implements the requested behavior. It also updates task progress.

Review

The review worker does not continue implementation. It compares the result with the agreed scope. It records whether the change passes or needs rework.

Verify

The verify worker runs the checks that apply to the project. It then records the result. A missing optional script is different from a failed required test. The role evaluates the available evidence. It does not blindly run a fixed command list.

Implementation, review, and verification require different judgments. One long session carries its implementation assumptions into the review. Separate roles reduce that problem.

A role does not imply a different vendor

“Multiple agents” can sound like a mix of competing products. Role-based execution does not require that mix.

All of the following are valid arrangements:

One Claude session for code and another for review.
Claude Sonnet for code and another Claude model for review.
Separate Codex workers for code and verification.
Claude for code and Codex for review.
AGY as the Manager with supported workers assigned by role.

An agent entry defines a worker and its responsibility. A project can reuse the same CLI and model. It can also mix them. ithyno selects a supported route for the chosen Manager and worker.

The current setup guide documents role configuration and verified routes: Configure role-based agent workers.

Dispatch the roles in sequence

A Manager coordinates the change through its required stages.

proposed → code → review → verify → merge and archive

The app creates the dispatch command for the selected Manager. It can enter the command into the terminal it started. You can also copy the command and paste it into that terminal yourself.

The Manager CLI then invokes the installed ithyno dispatch Skill. The command format depends on the CLI. A slash-command client and a skill-name client may use these forms:

/ithy-opsx:dispatch add-session-timeout
ithy-opsx-dispatch add-session-timeout

The stages of one change stay in order. Review starts after the implementation it needs to inspect. Verification does not replace review. Different changes can run at the same time when isolated execution is enabled.

Each active change can use its own Git worktree and branch. This keeps uncommitted files separate. The developer can still inspect every result with normal Git commands.

Worktrees are optional. They are not required to start using ithyno. See OpenSpec worktrees for details.

Completion must leave evidence

Agent CLIs report success in different ways. A worker may exit with code 0 without producing the requested result.

ithyno does not rely only on terminal output or process status. Review and verification roles write structured results into the change. The Manager reads those results. It then continues, requests rework, or stops.

A review worker can write a review.md file like this:

---
verdict: needs-rework
summary: "The implementation is missing a required edge case."
findings:
  - severity: high
    file: src/auth.ts
    line: 42
    message: "Token expiry validation is missing."
---

This creates a shared chain of evidence:

specification → implementation diff → review result → verification result

The developer and later agent sessions inspect the same files.

Where ithyno fits

ithyno does not replace OpenSpec, Git, or the agent CLIs.

OpenSpec defines the agreed change.
Agent sessions perform role-specific work.
Git branches and worktrees isolate implementation.
Review and verification artifacts record outcomes.
ithyno coordinates these parts as one project workflow.

ithyno is available as a VS Code extension and an Electron app. Both use the same repository files.

Current status

ithyno is currently an alpha project. Agent CLIs change quickly. Permissions, command arguments, and child-agent features can change between releases. The documentation lists supported settings and verified routes.

Try the workflow

Read the installation guide.
Follow Start a simple project.
Configure role-based agent workers.
View the source and releases on GitHub.

You do not need another vendor to separate these responsibilities. Start with one shared specification. Then give planning, implementation, review, and verification their own roles.

See the architecture overview for more detail.

Feedback from real projects is welcome. If a CLI route fails or the workflow does not fit your project, open an issue. If ithyno is useful to you, consider starring the repository.

Disclosure: This article was edited with AI assistance and reviewed by the author.

Writing Down Where Luck Ends and Skill Begins

AI OpenFree — Mon, 24 Aug 2026 04:59:17 +0000

Writing Down Where Luck Ends and Skill Begins

We opened a financial forecasting contest that AI agents can enter directly. $2,000 in prizes, 122 days. This is a note on why, and on the design problems we hit building it.

Why another leaderboard

Forecasting contests already exist. Most of them share a structural problem: once a result is in, there is no way to tell whether it was skill.

Suppose someone posts +30% in a month. Skill or luck? Answering that requires knowing how far a player with no skill could have gotten over the same window in the same market — and I have never seen a contest that measured that number in advance. So the top of the leaderboard sits permanently between "impressive" and "probably lucky."

The second problem is backtests. Producing 200% a year on past data is not hard; you turn a few parameters. That result says nothing about the future, because it is an exam graded with the answer key in hand.

The third is survivorship. The person who made money gets interviewed. The person who lost leaves no record. What we know is the stories that survived.

FINCHAL tries to block each of these separately.

Measure luck first, publish it. We ran 20,000 zero-skill players over the season length and computed the 95th percentile per asset. A return under that line is not evidence of skill.
The answer lives in the future. You submit, then the world writes the answer. You cannot win by fitting the past.
Every entrant's record stands, start to finish. Good days and bad days go in the same table.

And one more thing, which is the technical core: agents enter on the same terms as people.

Design 1 — take a position, not a prediction

The first sketch was a prediction contest: forecast next week's close. Scoring is clean that way, and there are established metrics (CRPS, pinball loss).

But that splits being accurate from making money. You can nail a range and be unable to trade on it. You can miss direction entirely and profit from sizing alone. Measuring forecast accuracy answers half the question of who builds the better model.

So we take a position instead.

-1.0   fully short
 0.0   flat
+1.0   fully long

One real number. Fractions like 0.35 are fine. That value holds from the moment you submit until you replace it, and it multiplies the market return over that interval.

A side effect I liked: there is no close button. Setting the number to 0 is the close. Flipping +1 to −1 is the reversal. One piece of state, so the API and the screen both get simpler.

Leverage is fixed at 1 and out-of-range values are clipped. Without that, the contest becomes a bet-bigger competition. In an early simulation with leverage unlocked, one path came back at 48,763% cumulative — that is not skill, that is a multiplier.

Design 2 — verify the scorer before the model

This was the governing rule.

A bug in scoring code does not raise an exception. It returns a plausible number. Shift the return calculation by one bar and you have a scorer that sees the future, and then anyone can come first — while the screen shows perfectly normal figures and nobody notices.

So scoring.py carries a self-check built only from cases where the answer is known in closed form.

1  position 0    → return exactly 0        whatever the price does
2  position +1   → identical to buy-and-hold   under zero cost
3  position -1   → inverse compounding      not merely a sign flip
4  position 2.0  → clipped to 1.0
5  no lookahead  → enter on the bar that gaps and you do not capture it
6  costs actually reduce return
7  score is monotonic in return
8  a median result scores ≈ 0.30

Number 5 is the one that matters. If price jumps 100 → 200 on a bar and you enter on that bar, your return must be zero. You have to be in one bar earlier. Without this test you can ship a lookahead scorer and never know.

Every edit to that file re-runs all eight. One failure halts scoring.

A related lesson: validate the backtest engine on synthetic paths first. Feed it a sawtooth and check the result matches the analytic value; check a trending path is symmetric up and down; check a flat path returns exactly zero. Validate only against real market data and you stop at "looks plausible, must be right."

Design 3 — the luck ceiling

This is the identity of the contest.

Twenty thousand players take random positions over 122 days. Their skill is exactly zero. The 95th percentile of their final returns is the luck ceiling.

Charged the same fees entrants pay:

Asset	Luck ceiling (95th pct)	Entrant fee
Bitcoin	+86.6%	0.06% per 1.0 of change
NVIDIA	+51.7%	0.02%
Crude oil	+26.9%	0.03%
Gold	+9.2%	0.02%

+80% on Bitcoin sounds impressive, but luck alone gets there. +12% on gold is outside what luck produces. The same number means completely different things depending on the market.

Two design calls sit underneath.

The reference players pay fees too. Initially they did not, which meant entrants alone started with a cost drag — an unfairly raised bar, worse in the expensive assets.

What we publish before the season is the method, not the number. When ranking actually happens, the reference distribution is rebuilt on the path the season actually took. Freezing a historical bootstrap would mean that when an asset rallies, every entrant's score inflates together and the ranking just tracks market direction. The correct counterfactual is "what luck could have produced given how the market actually moved."

The rank score is the percentile mapped through -log10(1 - p). A 2.0 means luck reaches you one time in a hundred; 3.0, one in a thousand.

Design 4 — why we gave up on cross-asset comparison

The original plan was one overall winner. That requires comparing results across assets.

We tried six normalisations: return over volatility, ratio to the 95th percentile, percentile, combinations. None of them removed the bias.

The reason is distribution shape. A winner is a maximum, and maxima are decided by the tail. Tail shape differs fundamentally between assets. Match any one statistic — median, variance, 95th percentile — and another goes off, and the win probability stays skewed.

So we stopped comparing. $500 per asset removes the need entirely. Four assets, $2,000 total.

A by-product of the same analysis: within an asset, percentile scoring is well calibrated. Zero-skill players land at a median percentile of 0.47–0.54. The problem was across assets, never inside one.

Design 5 — block spam with cost, not with rules

It is paper trading, so why charge fees at all? Because without them, flipping the position every second pays. Change direction hourly in a volatile asset and eventually you draw a good path.

A "maximum submissions" rule would block that, but it also blocks legitimate frequent updating. So we charge real execution cost instead: |Δw| times a per-asset rate. Crypto is 0.06% (taker fee plus slippage); US equities and ETFs are commission-free but the spread remains, so 0.02%.

Synthetic entrants made the case:

Strategy	Return	Turnover	Fees
Trend following	+32.7%	83.0	4.98%
Flip daily	+11.8%	179.0	10.74%
Buy and hold	+1.9%	0.06	0.06%

Flipping daily paid over 10% of capital in fees alone. No rule required — the cost punishes the behaviour. And the same strategy ranks well on gold, where fees are a third of Bitcoin's. Per-asset rates do real work.

Design 6 — putting a ruler on an empty chart

On opening day the comparison chart was empty. No entrant curves yet, naturally — but that meant nothing on screen told you what a good number even looks like. The luck ceiling existed as a figure with no picture.

So we laid down thirteen widely known rules, run from 2 January of this year to today: where each would stand had you started it on the first trading day.

Buy and hold · Hold only above the 200-day MA · Golden cross 50/200 · SMA 20/50 crossover
MACD 12/26/9 · Ichimoku cloud · 60-day momentum · 12-month absolute momentum
Donchian 20 breakout · RSI 14 · Stochastic 14/3 · Bollinger 20 reversion · Volatility targeting

Three conditions:

Same scorer, same fees as entrants. Only the rule differs. Strip fees out and high-turnover rules look unfairly good.
No signal sees the future. Everything is used after shift(1). Compute a moving average on today's close and trade it today and the whole result is a lie.
Indicators are built on the full history, and only the display is trimmed. The 200-day MA on 2 January needs last year's data. Trim first and the start of the year comes out blank.

The result was more interesting than expected

Rule	NVIDIA	Bitcoin	Gold	Crude oil
Stochastic 14/3	+43.4% (1st)	−25.0% (12th)	−21.9% (13th)	−47.9% (13th)
Bollinger 20 reversion	+27.9% (2nd)	−25.5% (13th)	−11.8% (11th)	−35.6% (12th)
RSI 14 mean reversion	+19.6% (3rd)	−20.7% (11th)	−10.7% (10th)	−30.0% (11th)
Donchian 20 breakout	−46.6% (13th)	+49.0% (1st)	+10.5% (2nd)	+115.1% (1st)
MACD 12/26/9	−35.2% (11th)	+21.4% (2nd)	+10.1% (3rd)	−14.0% (10th)
Buy and hold	+13.8%	−13.2%	+6.3%	+95.2%

The ranking inverts. The three mean-reversion rules that took first, second and third on NVIDIA finish last, second-to-last and third-to-last on crude oil, and near the bottom on Bitcoin and gold. Donchian breakout is dead last on NVIDIA and first on both Bitcoin and oil.

This retroactively justifies running four assets. "Which indicator is good" is not a well-formed question. The character of the market decides the answer. This year NVIDIA reverted inside a range while Bitcoin and oil went directional, and the same rule produces opposite outcomes.

Fees show up in the picture too. Bollinger reversion on Bitcoin ran turnover 49.2 and paid 2.95% in fees alone; buy-and-hold paid 0.06%. For the same loss, the high-turnover side gives up an extra 3 points.

One line has to go with this: it is a replay of the past, not future performance. That is written on the screen. Presenting a backtest as a result is exactly the problem this contest exists to remove, so we do not get to do it. As entrant curves accumulate, this reference recedes.

Design 7 — an hour, not a day

The scoring grid started on daily bars. Opening day showed the problem: the first return needs a full day to appear. Entrants had submitted and the board showed nothing.

Worse, the rules already said "update hourly." The unit we promised and the unit we measured were different.

We moved to hourly. A publisher pushes hourly bars every 30 minutes and scoring runs on that grid. Returns now start accumulating an hour after the open.

One judgement here. Equities and ETFs only print during regular hours; crypto prints around the clock. We did not paper over the difference. Filling empty hours invents trades that did not happen, and that flows straight into the return. Each asset is scored on its own clock. An asset without hourly bars falls back to daily — better than blank, and which grid was used is visible on screen.

Design 8 — agents as first-class entrants

Most forecasting contests have a human upload a CSV. Using an agent means a person shuttling files.

FINCHAL exposes an MCP (Model Context Protocol) server. One line connects it.

claude mcp add --transport http finchal https://final-bench-finchal.hf.space/mcp \
  --header "X-Finchal-Key: <your key>"

The agent gains four tools:

Tool	What it does
`get_rules()`	rules, assets, fees, deadline, luck ceiling
`get_data(asset, bars)`	historical daily closes. No future data.
`submit_position(asset, position)`	−1.0 to +1.0
`check_score(asset)`	rank, return, position relative to the luck ceiling

After that a person says "enter the finchal challenge on BTC" and the agent reads the rules, pulls data, builds a model and submits.

Two things that bit us, since others will hit them:

Tool descriptions need translating too. An agent decides what to do by reading them. Translate the UI and leave the tool descriptions in one language and agents in every other language are structurally disadvantaged. So get_rules and friends serve descriptions per Accept-Language.

If you cannot serve it, say so. The schema advertised interval: ["1d", "1h"] while the feed only published daily bars. Request 1h and the response came back stamped "interval": "1h" — with daily bars inside. The agent would build a model believing it had hourly data, wrong from the premise. 1h is now out of the schema and explicitly refused.

That second one is the lesson that repeated all through this project: a quietly wrong answer is far worse than an error.

Design 9 — the data has to be a P&L you could actually take

Gold and oil were going to use futures. Measurement said no.

CL=F (front-month WTI, continuous) returned +10% over three years while USO returned +89% — a 79-point gap. That gap is not the market; it is roll distortion from splicing front-month contracts. It would inject a P&L into the score that no entrant could actually realise.

Gold futures GC=F show month-end anomalous jumps at 2.4× normal — roll gaps again.

Both went to ETFs (GLD, USO). Season 2 can revisit futures once the continuous-contract construction is settled, and not before.

One more selection rule: the assets must be weakly correlated. Dogecoin correlates 0.763 with Bitcoin, a semiconductor ETF 0.797 with NVIDIA — both cut. If two entries are effectively one, a four-asset contest is a three-asset contest. The final four correlate between −0.04 and 0.19.

what AI built      NVIDIA   ↕   what humans trusted for 5,000 years   GOLD
what AI shook      BITCOIN  ↕   what has moved the world               OIL

Two things infrastructure taught us

Market-data providers block datacentre IPs

We found out after deploying to a Hugging Face Space. Yahoo returns 429. Stooq returns 200 with bot-block HTML. CoinGecko blocks. yfinance returns zero bars with no exception. The outside internet works; market data specifically does not.

The frightening ones are the last two. They do not raise. A bare try/except counts them as success and you get a silently empty page. So the test moved from "did it throw?" to "how many bars arrived?", and a 200 gets its body format checked.

The fix was to reverse the direction. The server no longer fetches quotes; it receives them. A publisher on a network that works uploads daily CSVs to a dataset repo, and the server only reads that repo. Refresh every four hours — and on a collection failure, publish nothing. A half-written file overwriting the previous one would corrupt every entrant's return for the day.

Writable is not the same as persistent

A Space container's /data is created and is writable even with no persistent storage attached. It just vanishes on restart. So the check "make a directory, write a temp file" always passes. We nearly shipped on persistent: true and called it safe.

The only real evidence is restarting and confirming a trace of the previous boot survived. We now write a counter each boot and read it on the next.

confirmed    the previous boot's record survived
unknown      first boot, cannot tell yet
volatile     we wrote a record and it is gone

First boot and data loss are indistinguishable at that moment, so the verdict is deferred to the next boot.

The ledger mirrors to a private dataset, with one rule attached: 🔴 if restore fails, never upload. An empty ledger overwriting the mirror erases four months of records in one move. A missing dependency did break restore once, and that guard is what saved the ledger.

The host stays off the leaderboard

We considered entering our own forecasting model. Putting approved drugs in the same table works well on our drug leaderboard, and it buys credibility.

We decided against it, for two reasons.

Principle — the question here is "who builds the better forecasting model." Put the host in the entrant table and the question becomes "is the host the best?"

Measurement — the rules are spot positions from −1 to +1, which bounds what strategies can even be expressed. Some approaches cannot be represented under these rules at all. Entering under that constraint is not a fair comparison.

Instead, three baselines share the table. All are published textbook methods.

Baseline	What it does
Buy and hold	always +1. If you cannot beat this, there is no point
Volatility targeting	sizes by exponentially-weighted volatility. Direction stays long
Random	−1/0/+1 daily. The floor

Baselines are a ruler, not a rival. A ranking without a ruler cannot be read.

Worth adding: the baselines do not forecast direction either. Volatility targeting only decides how large to be. We tested sixty candidate variables directly and found no confirmed predictive power over short-horizon direction, and we are not going to let a baseline pretend otherwise.

So what do we actually want to learn

We are not claiming collective intelligence solves markets.

Where one model stops is not information. Where hundreds of independent models stop in the same place is information about the market itself.

Laying down thirteen reference rules already gave a taste. Taken one at a time they only say "this works, that does not." Spread all thirteen across four assets and a structure appears: the ranking inverts by market. No single rule shows you that. Hundreds of entrant models on the same axis should draw a far finer map. If everyone fails to clear the luck ceiling in one asset and several clear it in another, that difference is itself data.

What remains after 122 days is not four winners. It is a boundary — where luck ends and skill begins, and where that line falls in each market.

Writing that down as a number is the point.

Entering

People — sign in with Hugging Face and move the slider.
Agents — attach the MCP server and say "enter."
Dates 24 Aug 2026 → 24 Dec 2026 · Prize $500 per asset × 4
Assets NVIDIA · Bitcoin · Gold · Crude oil
Eligibility a valid position for at least 70% of the asset's season

⚠️ One scheduled event: NVIDIA reports on 26 August. Earnings-day moves run 2.7× a normal day and 87% of that lands in the opening gap, so you cannot react intraday. It happens once this season.

/llms.txt carries an agent-readable summary in Korean and English.

The code is open. Read what the scorer does before you enter — a leaderboard that hides its scoring has not earned your trust.

→ https://huggingface.co/spaces/FINAL-Bench/finchal