MarqSpec Anchored Approach (WIP)

Requirements, architecture and decisions live beside the code, and every change that alters behaviour, configuration or the build carries its documentation in the same reviewed change; review sends back a change that doesn't. Every link is checked on every pull request, and the checks fail on a requirement that is cited but defined nowhere, so each one keeps a single definition you can trace to the code that meets it. A new engineer, or a new AI tool, starts from the documents, not from guesswork.

Every commit, pull request, review and status report an AI tool writes ends with a line naming the tool and the model it ran on, from the first commit. When your auditors, your customers or your board ask "did AI write this, and which one?", the answer is in the history.

Declared by the tool as it works, not detected afterwards: it records the model the tool was set to use

An AI assistant finds its way to the right part of the documentation in about 6–10 thousand tokens, and a typical coding task, with its filled-in requirements, reads nearer 18 thousand. Reading the whole documentation set instead costs about 100 thousand tokens on a freshly started project and about 470 thousand on a mature one. Less context spent finding things leaves more for the work.

Projects are created with each platform's own tools on current, supported releases, and start with passing builds, tests, linting and dependency audits, and container images where you want them. Every release carries one version number across all its components, production runs the exact build that staging tested, and a failed deployment rolls back automatically. An example project for .NET, Python, Node.js and React runs green in CI.

Back end

• .NET 10 ASP.NET Core · Blazor · gRPC · workers
• Python 3.13 FastAPI
• Node.js 24 Express

Front end

• React
• Vue
• TypeScript
• Vite

Testing

• xUnit
• NUnit
• MSTest
• pytest
• Vitest

Packages

• NuGet
• uv
• Poetry
• pnpm
• npm
• Yarn
• Bun

Delivery

• Docker
• GitHub Actions

One back-end language per repository; your team's package manager and test framework are chosen at the start

Where you want it, every service exposes its metrics from the first run, with Prometheus and Grafana, a service dashboard, and alerts that are tested in CI and each link to a runbook. A security findings table records every known vulnerability and exposure in the stack, with its severity, status and evidence.

We can start from your existing repository. The approach is added around what is there: your documents are kept and linked into place rather than rewritten, your README and CI workflows are never overwritten, and any rename or merge happens only with your agreement, one reversible commit at a time.

At each milestone you receive the software, a licence and documentation written for your team, in a fresh repository, and the delivery is refused while any file still refers to our internal process. Later milestones merge into your repository without overwriting your team's work: where both sides changed the same lines, nothing is written until the conflict is resolved, and a drift report shows exactly what changed on your side. The work can run in your GitHub organisation from the first day, or in ours with a delivery at each milestone.

We report the figures that matter to you: how much of every change carried its documentation, how review findings were resolved, lead time per milestone, and what each handover delivered.

No client figures yet; they are added once an engagement has measured them