An image may resemble a previous campaign while failing to express the new idea. A product photograph may be visually accomplished yet obscure the detail a customer needs to see. A generated scene may look convincing while subtly changing the product’s construction.

Better rendering does not, by itself, resolve these failures. Indeed, it can make them harder to recognize: the image looks finished before anyone has established whether it fulfills the brief.

The production question is therefore more exacting than whether a model can reproduce a look. Rather, it asks which qualities of that look matter to this project, what must be preserved, what may be reinterpreted, and who has the authority to decide. AP-ASK’s work is to make those distinctions explicit enough to guide production and selection.

Much of a brand’s direction already exists, though rarely in one place. It lives across style guides, photography guides, libraries of existing assets, campaign decks, moodboards, and product specifications. It also draws on the accumulated, often unarticulated knowledge of the creatives who have worked with the brand for years.

An experienced art director can read those materials through a history of decisions: which reference carries the light, which campaign was an exception, and how far “make it feel fresh” can go without losing the brand’s character. A machine, however, does not acquire that working understanding simply by receiving the same folder as context. AP-ASK’s task is to articulate the knowledge that lets the team interpret a brief, so that the same standards can guide machine-assisted production.

AP-ASK’s value proposition begins with the intake of that brand material, in both structured and unstructured forms, and its synthesis into a proposed visual brand system. The materials come as they are; making sense of them is the work, not preparation the brand must complete beforehand. The synthesis distinguishes enduring principles from campaign-specific choices, product facts from inspiration, and stated requirements from inferred patterns.

Yet a coherent synthesis is not automatically an authoritative one. The creative lead must first review the synthesis, correcting, refining, or rejecting its interpretations before validating what can govern subsequent work.

For an emerging brand, this process may articulate direction held largely in the founder’s eye. For an established team, it makes explicit the knowledge that already sustains its visual practice, often carried in the heads of art directors and long-standing collaborators rather than articulated in any guide. In either case, AP-ASK makes the governing direction explicit and provides a structure for the team to exercise creative judgment throughout production.

A brand does not have one image-production workflow — but rather, several. SKU-driven product imagery must describe a particular item accurately. Collection and merchandising work must make a group of products coherent. Marketing imagery serves a message or offer, while campaign and editorial work develops a broader creative idea.

These are different workflows, not simply different looks. They share a brand system, but differ in their inputs, required outputs, room for interpretation, and review decisions. A product-detail image and an editorial composition can therefore belong to the same brand without answering the same brief or following the same production process.

AP-ASK connects that shared direction to the requirements of each workflow and, within each workflow, to each project. It distinguishes brand-wide principles from campaign choices and individual shot requirements: what carries through, what the project adds, what may legitimately change, and who can authorize an exception.

For each project, AP-ASK connects the governing brief and its supporting material in what ASK calls a portable asset-definition package. This is a way of structuring the work, not a requirement to prepare a separate document for every image. The definition specifies what is to be made: the purpose of the image, the product facts that must remain accurate, references and their roles, required views or formats, permitted variation, and approval responsibility.

In a high-volume e-commerce studio, that direction can be built into the operating environment itself. An Airtable base, for example, can connect standing brand and category rules to product information, references, shot requirements, and review paths. The team can then work with the specifics of each item and any exceptions, rather than re-entering established direction or maintaining a second brief alongside the base.

A campaign or editorial project may instead benefit from a discrete brief. The package can support either form: what matters is that the governing direction is established and available when the work runs, not that someone writes a new document each time. Where the supplied material cannot settle a question, the uncertainty remains visible rather than quietly acquiring the force of a rule.

This is the brief made operable. It gives the people and systems doing the work a common basis for production and review, without forcing different workflows into one undifferentiated process.

Visual references carry relationships of light, proportion, material, atmosphere, and restraint that prose cannot fully encode. Yet that richness does not tell a production system which part of an image should govern the next one.

Someone supplies a photograph of a chair in a sunlit room and says, “Use this as a reference.”

A reference for what? The chair? The lighting? The room? The mood? The crop?

The same photograph might establish the product’s silhouette and construction, guide only the light, or suggest an atmosphere without governing the object at all. It might even show something the brand wants to avoid. Nothing in the pixels settles which of those roles it has.

AP-ASK makes the role explicit, including what the reference does not govern. A lighting reference may guide the treatment of a scene without authorizing changes to the product. A campaign image may suggest atmosphere without turning last season’s styling into a permanent brand rule. Otherwise, a compelling mood can quietly displace product fidelity.

The purpose of structure is not to prescribe every visual decision. Some projects call for close fidelity; others invite a new composition, setting, or treatment. However, the latitude must be deliberate. An opening granted by the brief is not the same as an omission the generator happens to fill.

Selection (making “selects” and choosing the image for final approval) must then answer to that same brief. The question is not only whether a candidate is compelling, but whether it fulfills the intended expression, preserves product truth, and respects the requirements of its use. Creative judgment remains essential; the architecture makes explicit what that judgment is being exercised against.

Choosing a candidate, however, is not automatically approving its use. AP-ASK keeps the brief, the candidate images, the selection decision, and the accepted asset distinguishable. Acceptance binds the asset to its authorized use and responsibility; the record preserves the brief, the basis of the choice, and who stands behind it.

AP-ASK is intentionally tool- and substrate-agnostic. The model that makes an image and the environment that organizes production are separate choices. The information architecture defines what that environment must carry and how the work is organized, rather than allowing one application’s structure to dictate the brand’s production logic.

AP-ASK uses that information architecture, together with the articulated brand system, workflow requirements, and creative and business constraints, as the blueprint for building the production system. AI coding and configuration agents then build and test the implementation against those requirements.

In Airtable, that means building the base’s schema, tables, field types, and data relationships, together with the working views, review paths, and automations the workflow requires. AP-ASK has already used agentic execution to build multiple prototype bases from architectural specifications.

For a team working on its own infrastructure, the same approach could instead guide, for example, a custom Python application backed by SQL. The execution tools may differ, but the requirements articulated through AP-ASK remain the basis for building and testing the system.

The repository develops the blueprints those builders need: which information belongs where, how instructions inherit or override one another, where creative latitude is granted, and how work moves through production and approval. Writing the code does not decide what the system ought to do; the architecture and the brand’s resolved requirements supply that direction.

Airtable is therefore a convenient implementation substrate, not AP-ASK’s product boundary. Airtable is a powerful environment in its own right, combining data from multiple sources, relational structure, and collaborative workflows with image generation directly inside the platform. Production information, visual references, generated candidates, and review decisions can consequently remain connected in one integrated workflow. That being said, the larger aim is to make the architecture buildable on any substrate capable of supporting the work, while keeping the brand’s standards independent of the application chosen to implement them.

Within the resulting system, the package carries a project through production, whether embodied in connected records or presented as a discrete brief and record. The brief governs the run; the execution history relates candidates to that brief; and the acceptance record preserves the approved asset’s identity and decision basis. The architecture guides how the system is built; the package carries the work that system must perform.

Portability thus concerns more than moving data. It means retaining the direction for future work as well as the record of completed work. A new model or application should be evaluated against the brand’s requirements, rather than quietly becoming the source of new ones.

AP-ASK is a developing reference architecture, not a finished production platform. Its worked examples span the four still-image workflows described above, at different depths.

The Airtable builds have combined agentic execution with manual configuration where platform-specific gaps required it. Within the prototype bases, bounded runs have carried project-specific image work through generation, human selection, and acceptance of the resulting assets.

One completed package has also been represented and recovered outside Airtable, in a file-based store and PostgreSQL. These are concrete implementation and portability proofs at bounded scope. The larger goal is to apply the same architecture-led approach to complete, brand-specific production systems across suitable environments.

AP-ASK is developed by Andrew S Klug // ASK, drawing on more than a decade producing photography and video for global brands and subsequent creative-operations and systems work, including Banana Republic and Williams-Sonoma.

AP-ASK is the short public name of the asset-pipeline-ASK project.

The architecture, worked examples, and reasoning are being developed openly. The repository’s open-source materials are available under the Apache License 2.0, allowing anyone to use, adapt, and build on the work, including for commercial purposes, subject to the license’s terms.