Basis

Podcast 2 — In conversation

Speaker A: I notice a lot of legal and business writing uses 'on a ... basis' constructions — 'on a commercial basis', 'on a case-by-case basis' — and some style guides say it's verbose. When is it the right choice and when should you just use an adverb?

Speaker B: Good question, and it's a genuine stylistic tension. In informal or literary writing, the adverb is almost always cleaner: 'we meet regularly' is tighter than 'we meet on a regular basis'. But in formal legal, contractual, and business writing, the 'on a ... basis' construction does something the adverb can't do quite as well: it makes the operating condition explicit and nameable. A contract that says 'services are provided on a rolling monthly basis' is more precise than 'services are provided monthly', because the phrase 'rolling monthly basis' conveys not just frequency but the nature of the renewal arrangement. So the test is: does the noun after 'basis' add precision, or is it just dressing up an adverb? If adding precision, keep it; if just padding, cut it.

Speaker A: What about 'on the basis of' — is that different from 'on a ... basis'?

Speaker B: Yes, meaningfully different. 'On the basis of' means because of or in light of — it introduces the grounds or justification for something: 'she was promoted on the basis of her results', 'the claim was rejected on the basis of insufficient evidence'. That's reasoning or justification. 'On a ... basis' describes the operating mode or frequency — 'on a part-time basis', 'on a voluntary basis'. They look similar but they're doing different grammatical and logical work. 'On the basis of' is often replaceable with 'because of' or 'in light of' in less formal writing, but it has a slightly more measured, reasoned quality that suits academic and legal prose well.

Speaker A: Is there a common error with basis that I should watch out for?

Speaker B: The most common error is confusing the plural bases — basis becomes bases — with the plural of base, which is also bases, but pronounced differently. 'The bases of the decision' — meaning foundations — is valid but unusual; most people avoid it precisely because of the ambiguity. A more practical error is using basis where foundation or rationale would be sharper — 'this forms the basis of our policy' is fine but 'this is the rationale for our policy' is often more precise. And watch for the verbose trap: 'on an ongoing basis' almost always just means 'continuously' or 'regularly'. Writers who default to on-a-basis constructions everywhere can produce prose that reads like a contract even when it shouldn't.

Podcast 3 — Prompt engineering

Speaker B: 'Basis' in development prompts is the vocabulary of foundational architecture decisions, operating modes, and constraint justification. When you tell an AI the basis on which a system operates — the technical foundation, the access model, the pricing structure — you eliminate a whole class of ambiguous defaults. It's one of the most powerful precision words in a developer's prompting vocabulary. Let's work through the key scenarios.

Speaker B: First — a SaaS pricing system with basis-defined billing models:

Speaker B: PROMPT: Build a SaaS billing system where each subscription plan operates on a different pricing basis. The starter plan bills on a per-seat basis — cost multiplied by active user count monthly. The professional plan bills on a usage basis — cost per API call above a free tier. The enterprise plan bills on a flat-fee basis — a fixed monthly amount regardless of usage. The billing_records table stores plan_id, billing_basis — enum: per_seat, usage, or flat_fee — quantity, and amount_pence. Stack: Node.js and PostgreSQL.

Speaker A: Storing billing_basis as an enum in the billing_records table — rather than inferring it from the plan — means billing logic can be audited and queried by basis type independently of the plan. If you need to analyse revenue by billing model, the basis column makes that query trivial.

Speaker B: Good. Now a staffing system with employment-basis tracking:

Speaker B: PROMPT: Design a PostgreSQL schema for an HR staffing system. The employees table includes employment_basis — enum: full_time, part_time, zero_hours, contractor, or fixed_term — and a contract_end_date that is nullable for permanent staff. Add a view showing all employees on a temporary basis — zero_hours and fixed_term — whose contract_end_date falls within the next sixty days. Add an index on employment_basis and contract_end_date. Stack: PostgreSQL.

Speaker A: A view surfacing staff on a temporary basis with approaching contract end dates — that's the HR manager's upcoming renewals report. Without that view, identifying time-sensitive temporary contracts requires a manual query every time.

Speaker B: Here's a data access permission system with basis-defined access rules:

Speaker B: PROMPT: Build an API permission system where access to each endpoint is granted on a specific basis. The permissions table stores endpoint, role, and access_basis — enum: role_based, ownership_based, subscription_based, or time_limited. A middleware function checks the access_basis for the requested endpoint and applies the appropriate verification logic: ownership_based checks that the requesting user owns the resource, subscription_based checks the user's current plan tier, time_limited checks an expiry timestamp. Stack: Node.js and Express.

Speaker A: Storing access_basis per endpoint in a permissions table — rather than hard-coding permission logic in each route handler — means access rules are configurable and auditable without touching the application code. The basis enum drives the middleware branching cleanly.

Speaker B: Now a dashboard UI built on a data-refresh basis:

Speaker B: PROMPT: Design a metrics dashboard UI where each widget refreshes on a configurable basis. The widget_config table stores widget_id, metric_type, and refresh_basis — enum: realtime, hourly, daily, or on_demand. Realtime widgets use a WebSocket subscription; hourly and daily widgets use a polling interval set to match their basis; on_demand widgets show a manual refresh button. Each widget displays its last_refreshed timestamp. Stack: React, Tailwind CSS, and WebSocket.

Speaker A: Configuring the refresh mechanism from the refresh_basis field — so that the same widget component handles WebSocket, polling, and manual refresh just by reading its basis — that's a clean data-driven approach that avoids duplicating widget logic for each refresh mode.

Speaker B: One final prompt — a full application:

Speaker B: PROMPT: Build a full-stack consultancy project management platform. Projects operate on one of three billing bases: time-and-materials — billed on an hourly basis — fixed-fee — billed on a project-completion basis — or retainer — billed on a monthly basis. The platform tracks timesheets for time-and-materials projects, milestone completions for fixed-fee projects, and monthly periods for retainers. Invoices are generated automatically according to the project's billing basis. A finance dashboard shows revenue grouped by billing basis. Stack: Next.js, Node.js, PostgreSQL, and Stripe.

Speaker A: Grouping revenue by billing basis in the finance dashboard — rather than just by project or client — gives the consultancy leadership a strategic view of which billing model is generating the most revenue and which has the most variance. That's the kind of business intelligence that drives commercial decisions about which contract structures to prioritise.

Speaker B: The lesson: 'basis' in prompts is your precision tool for naming operating conditions and foundational rules. When you specify that a system operates on a per-seat basis, a usage basis, an ownership basis, or a time-limited basis, you eliminate the AI's need to choose a default model. The word forces the AI to treat the operating condition as a first-class, nameable property of the system — stored in the schema, checked in the middleware, displayed in the UI — rather than as an implicit assumption buried in business logic.