# Haris Mekic project stories These projects show how I bring my operational experience into AI development. Each one began with something I wanted to understand or improve. Together they are the foundations of the digital office I want to build with a team. Version 2026-10-10-projects-v1 ## Opportunity intelligence workspace Business development and bid preparation. Developed in 2026. Implemented working system. I wanted a workspace that understood the company as well as the opportunity. I developed a connected bid workflow around the questions I would ask in the office. Does this assignment fit us? Can we put the right team together? What evidence do we have, and what still needs work before we can prepare a credible proposal? ### The problem Finding a tender is only the beginning. The team still needs to understand the buyer, read the documents, compare the assignment with its experience and bring the right experts into the work. I wanted those decisions to stay connected so that the next person or specialist agent could continue from the same working record. I shaped the work through conversations with staff about their needs and through my own operations experience. The first version was finding opportunities but did not understand the business deeply enough. I challenged the broad recommendations, missing buyer information and thin expert records. Even the win and loss reporting needed a clear way to record the outcome. I wanted to follow the whole process and understand what happened at each stage. ### Decisions I made #### Start with the organisation, not the search box I brought the organisation's actual assignments, previous bids, methodology and expertise into the development brief for Claude and Codex. I wanted the system to recognise work worth pursuing. The context layer separates that company baseline from recorded outcomes, funder engagement, expert information and source quality. #### Make missing information change the next action I wanted missing documents and staffing information to change the next task. The implementation distinguishes a notice from full or partial bid documents and carries evidence quality into the analysis. Gaps in documents or working context become preparation tasks, alongside approaching deadlines. #### Give specialists one working record I gave business fit, bid coordination and compliance their own questions about the same assignment. The bid role receives the terms of reference, language requirements, evaluation criteria and expert roster. Its structured output covers expert matches, team composition, staffing confidence, mobilisation days, a budget range with its basis, CV actions and coordination notes. Expert IDs in matches and CV actions are checked against the retrieved roster. An operations synthesis brings the available findings together for review and keeps partial results when a branch fails. #### Keep the handoff usable after the conversation ends I developed module blueprints to keep the purpose of each part beside the implementation. Independent repository review then informs the next brief. The handoff records the task, changed files, verification, remaining risks and next actions so Claude and Codex have a working state to continue from. #### Separate reusable machinery from business judgment The source adapters, normalised opportunity record, evidence packet and proposal assembly can be reused. The decision to pursue work still belongs to the people who understand the organisation and its capacity. I see the opportunity to scale in keeping those relationships intact as more work moves through the system. ### How the work moves #### 1. Define what a worthwhile opportunity means My role. I frame the decision around the work the organisation can deliver, its past assignments, funders, expertise and constraints. I challenge recommendations that do not reflect that reality and turn those objections into requirements for the next implementation pass. Input: Business capabilities, previous assignments and the questions the team needs to answer. Output: A business-fit brief and a defined purpose for each module. Tools: Claude, Codex, Module blueprints #### 2. Bring different sources into one record System role. Adapters translate different notice formats into a common record containing buyer, funder, deadline, value, source references and document links. Filtering removes irrelevant arrivals. Deduplication identifies repeated notices, while a richer arrival can improve the existing record instead of becoming another item to review. Source monitoring distinguishes healthy, stale, blocked and zero-yield sources, using those findings to prioritise repair, change collection strategy or consider disabling a poor source. Input: Notices from configured APIs, feeds and other source adapters. Output: Normalised opportunity records retaining their source references. Tools: TypeScript, Source adapters, OCDS #### 3. Build the working context System role. The context builder combines assignment documents with recorded business outcomes, expert availability, partner evidence and source health. It distinguishes documentary information from missing or weak evidence. An unknown expert's availability is not treated as confirmed capacity. Input: The opportunity, source documents, organisation records and expert evidence. Output: A shared evidence packet with document status and confidence indicators. Tools: PostgreSQL, Context builder #### 4. Analyse in parallel, then synthesise AI role. Three specialist calls examine business fit, team and bid coordination, and compliance/data requirements. The bid role returns expert matches, team composition, staffing confidence, mobilisation days, a budget range with its basis, CV actions and coordination notes. A separate operations analysis combines the available findings for review. The saved run distinguishes complete, partial and failed analysis so a missing perspective remains visible. Input: Shared evidence, task-specific instructions and the state of each specialist branch. Output: A combined recommendation and structured specialist findings for the person reviewing the opportunity. Tools: Gemini, Structured generation #### 5. Turn readiness gaps into preparation work System role. Preparation logic identifies missing source analysis, missing document-workspace context and approaching submission dates. It checks for an existing open task before creating another one. Date synchronisation updates system-generated calendar events when the opportunity deadline changes and leaves manually created events separate. Input: Opportunity stage, document and analysis state, and submission dates. Output: Specific preparation tasks and linked deadline events. Tools: Task generation, Calendar synchronisation #### 6. Draft the section that is actually needed AI role. The generator uses the assignment's mandatory requirements, evaluation criteria, risks and relevant specialist findings. Methodology, team, work plan and financial narrative receive different section instructions. Selected prior material and short excerpts of existing sections provide continuity. A schema checks the response structure before it becomes a draft for review. Input: The requested section, evaluation requirements and a bounded selection of supporting context. Output: A structured, assignment-specific draft rather than an unrestricted chat answer. Tools: Gemini, Zod #### 7. Review the recommendation and readiness My role. I test whether the result answers the original business question and whether the interface supports the next decision. Missing documents, weak staffing evidence and incomplete checks need an action, not better wording. In development, I use a separate review pass and update the blueprints so corrections survive into the next task. Input: The recommendation, draft, evidence gaps and preparation state. Output: Reviewed next steps and a precise correction or implementation brief. Tools: Readiness checklist, Claude, Codex #### 8. Assemble a usable working package System role. Proposal assembly combines selected sections, assigned expert CVs, consortium information, cover details and a table of contents. It produces a structured proposal for PDF or DOCX rendering, with optional document-workspace output. Recorded pipeline outcomes can then inform the context used for later opportunities. Input: Reviewed sections, team records, partners and the selected document structure. Output: An assembled proposal object prepared for document rendering and continued workflow tracking. Tools: TypeScript, Document templates ### Context engineering For me, context engineering starts with understanding the work. I decide what the system needs to know, where that knowledge comes from and what is still uncertain. Then I shape the record so the next person or agent can continue with the relevant evidence and decisions in front of them. #### Assignment evidence The notice and the actual bid package are different inputs. Source-document status, requirements, evaluation criteria, dates, languages and risks remain attached to the assignment. #### Business memory I combine the company baseline with recorded outcomes, funder engagement, expert assignments, availability and partner evidence. Gaps in the outcome history remain visible. #### Role-specific context Specialists share the same evidence but answer different operational questions. Their available findings become input to synthesis and are selected again according to the proposal section being drafted. #### Context budget Reference-proposal text is capped at 15,000 characters. Existing sections contribute excerpts of up to 320 characters each. The model receives this bounded selection of the archive. #### Evidence quality Document sufficiency, relationship evidence, expert-bench quality, outcome history and funder familiarity travel with the facts. Missing availability weakens the assessment of whether a team can be assembled. #### Engineering continuity Module blueprints and structured handoffs preserve intent, changed files, checks, risks and next actions. I use them to coordinate Claude and Codex across implementation and review. ### Implementation I developed the system with Claude and Codex using TypeScript, React, Next.js and PostgreSQL. Gemini handles structured analysis and drafting inside the application. A separate Anthropic integration supports the governed assistant path. I keep the development tools and the models running inside the product distinct when I describe the architecture. TypeScript, React, Next.js, PostgreSQL, Gemini, Anthropic API, Zod, OCDS SourceAdapter and NormalizedTender contracts separate collection from the business workflow. Source references and deduplication identities survive normalisation, while richer duplicate arrivals can enrich existing records. Fan-out/fan-in orchestration runs three specialist analyses before an operations synthesis. Shared context and saved run status preserve the relationship between evidence, intermediate work and the final recommendation. Research sessions have runtime budgets, organisation-scoped locking and stale-session recovery logic. Database migrations define atomic pending-job claiming with row locks. Enterprise throughput still needs to be measured. Document sufficiency, preparation tasks, calendar events and stage checks connect research with the next piece of work. Drafting and assembly consume structured records instead of requiring a person to copy every answer between unrelated tools. The current business profile and relevance rules are tailored to one organisation. Reusing the architecture for another company requires configuring its capabilities, evidence permissions, sources and decision criteria, then testing that fit. ### Results #### Working output A connected bid workspace. Source intake, organisational context, specialist analysis, preparation tasks, section drafting and proposal assembly are represented in the inspected implementation. #### Architecture 3 specialist perspectives. Business development, bid coordination and compliance/data analysis feed a separate operations synthesis stage. #### Engineering check 121 tests passed. Policy and confirmation-token tests rerun offline on 9 October 2026, checking permitted actions and confirmation controls. ### Next step I see procurement becoming more structured for both people and AI workers. I want to develop a company-configurable evidence packet that stays with an opportunity through discovery, qualification, proposal preparation and authorised review. I would test it with a business team and examine source relevance, review effort, accepted drafts, model cost and the decisions made. Buyer-side notice publication and agent-to-agent procurement are future directions I want to explore. [Specialist orchestration implementation](/ai-labs/specialist-orchestration/) · [Context and structured generation](/ai-labs/context-and-generation/) · [Reusable context handoff](/context-handoff.md) Based on selected original working instructions and implementation reviewed on 10 October 2026, with the dated engineering check identified above. Private correspondence, client records and source archives are not part of the public material. ## Career operations system Knowledge management and accountable automation. Developed and used in 2026. Implemented working system. I built this because I wanted my experience to be understood in its full context. I connected sources, professional claims, application requirements, document versions and completed actions into a working system. The aim is to carry the knowledge forward instead of researching the same history again with every task. ### The problem My professional record was spread across documents, correspondence, different projects and repeated AI conversations. I needed the responsibilities, evidence and purpose of each project to stay together when that material was used again. I kept seeing different projects mixed together and operational responsibility reduced to a generic description. I was correcting the same things repeatedly. That became a development problem to solve by giving the corrections a durable place in the system. ### Decisions I made #### Keep the source behind the sentence An inventory records the original file, its hash and extraction policy. Retrieval returns a short, privacy-minimised passage with its source identifier. A reviewed claim can then be traced to the evidence used rather than reconstructed from conversation memory. #### Separate writing from factual permission Draft wording is checked against a claim registry. The validator checks claim and evidence identifiers, prohibited wording, unsupported numerical detail and stronger authority language. Strict automated submission uses exact pre-approved variants. #### Treat attempted and completed as different states The system records an attempt before an external action, checks duplicates and unknown outcomes, and requires a matching confirmation artifact before the application can become submitted. The receipt is bound to its application and file hash. ### How the work moves #### 1. Set the professional context My role. I identify the role or question, correct misleading descriptions of my experience, and distinguish work I performed from formal title, approval authority or a wider team's outcome. Input: The exact role, question or output requested. Output: A task scope and accurate responsibility boundaries. Tools: Haris, Reviewed profile #### 2. Index without losing provenance System role. The inventory retains paths, timestamps, SHA-256 hashes and scope policy, identifies duplicates and preserves materially different versions. Input: Approved source files and distinct versions. Output: An inventory that keeps source identity and provenance. Tools: Python, SHA-256 #### 3. Extract the relevant evidence System role. Approved documents are parsed into searchable text with privacy minimisation. Restricted document categories remain in a separate controlled location. Input: Documents permitted by the extraction policy. Output: Privacy-minimised searchable evidence. Tools: Python, Document parsers #### 4. Research with bounded context AI role. AI-assisted research uses retrieved source passages and reviewed profile facts. The local retrieval tool uses lexical matching and returns bounded snippets with source identifiers, giving each answer a specific evidence trail. Input: A focused research query and source index. Output: Bounded source passages linked to evidence identifiers. Tools: Lexical search, Claude, Codex #### 5. Review the interpretation My role. I correct responsibility, seniority, programme context and terminology. Those corrections belong in the durable profile and claim ledger so the next task does not repeat the same loss of context. Input: Proposed statements and their supporting records. Output: Corrections to wording, project ownership and scope. Tools: Haris, Claim ledger #### 6. Validate the prepared package System role. Each factual statement maps to a claim and evidence identifiers. The preparation workflow records documents, fields and readiness checks before an external action can be authorised. Input: Reviewed claims, requirements and prepared documents. Output: A package with readiness checks and exact claim mappings. Tools: Python, SQLite #### 7. Reconcile what actually happened System role. An integrity-checked confirmation artifact must match the application and its recorded hash before the state becomes submitted. Unknown outcomes stop retries until reconciled. Input: An attempted action and its confirmation artifact. Output: A reconciled state, or a stop while an outcome is unknown. Tools: SHA-256, SQLite ### Context engineering I know my career as a connected experience, but each task needs a selected part of it. I keep the relevant source, its interpretation and the current action state together so the system can work from the right context. #### Original sources Source identity, file integrity, scope policy and distinct document versions. #### Reviewed professional facts Claim identifiers, evidence links, approved wording and owner corrections. #### Task context The exact role, requirement, field and document where a statement will be used. #### Working memory Persistent application state, events, status history, reviews and follow-up records in relational data. #### Completion evidence A confirmation artifact, matching application identity and SHA-256 digest, separate from the agent's account of what it attempted. ### Implementation I used Python for source inventory, extraction, lexical retrieval, claim validation and workflow coordination. SQLite keeps applications, events, status history, claim usage and receipts connected. AI handles research and drafting around those deterministic checks. Python, SQLite, Document extraction, Lexical retrieval, SHA-256, Claude, Codex The local workflow records applications, events, status history, claim usage and receipts as related data. Deterministic checks handle source identifiers, approved wording, unsupported numerical claims and action readiness around the AI-assisted research. Receipt validation checks application identity and file integrity. A recorded attempt is not treated as successful completion. ### Results #### Working output A reusable evidence trail. Source records, reviewed claims, document packages and action receipts are connected instead of being reconstructed from memory. #### Control Completion needs confirmation. The receipt must match the application and its recorded hash. Unknown outcomes are reconciled before retrying. #### Context Corrections carried forward. My project distinctions and responsibility corrections have a durable place in profile and claim records. ### Next step I want to finish the remaining claim metadata work and measure how much repeat research and correction each prepared package needs. That will tell me where the system genuinely helps and where I should develop it further. [Receipt-bound completion mechanism](/ai-labs/receipt-bound-workflows/) · [Public evidence database](/portfolio.sqlite) Compiled from selected original working instructions and current implementation inspected on 9 October 2026. The public account omits private correspondence and client records. ## Claude and Codex working system Context engineering and delivery practice. February to June 2026. Working method with recorded project iterations. I enjoy working across Claude, Codex and VS Code, but I need them to understand the same project. I developed a working method that carries the business purpose, source material, decisions and unfinished work from one task to the next. ### The problem I was seeing generic recommendations and plans that lost the details of what had already been built. I wanted agents to collaborate on the same project rather than each begin with a different understanding. That meant developing the context, responsibilities and handoffs as carefully as the application. In February I asked Claude and Codex to exchange tasks and results through two Markdown files. In March I pushed that further into living blueprints for each module and workflow. By May, recovering the actual project state and reporting what was implemented had become an explicit part of the work. ### Decisions I made #### Keep the business reason beside the technical task I asked for each blueprint to explain what a module does and why it exists. An opportunity agent, for example, needed the company's actual work and bidding history, not only a list of funding keywords. #### Separate assessment from implementation I asked Codex to inspect the repository and challenge assumptions before turning the findings into Claude's execution brief. Specialist tasks then had a defined area to inspect or change. #### Carry corrections forward I required errors to be resolved before the next phase and the blueprints to be updated as work progressed. A new session needed the correction and its reason, not only the old plan. #### Prepare the working environment before the product In June I paused a product task to address the skills, plugins and MCP setup the coding environment needed. I also required local implementation, separate builder and tester roles, QA and security checks before the cloud step. ### How the work moves #### 1. Start from the operating problem My role. I describe what is failing for the person using the product and what a useful result would look like. Input: The current workflow, business purpose and the problem I have observed. Output: A concrete brief with a reason to build or change something. Tools: VS Code, Project documents #### 2. Read the implementation before proposing a fix AI role. I ask for a source-based assessment of the code, data flow and existing project records, with assumptions challenged explicitly. Input: The brief, current repository and relevant source material. Output: A diagnosis tied to the implementation and a defined next phase. Tools: OpenAI Codex, Repository search #### 3. Build the context for the next agent My role. I set the roles, the required source context and the information that must survive the handoff. Input: The findings, earlier decisions and unresolved work. Output: A task-specific execution brief rather than a fresh generic prompt. Tools: Markdown blueprints, Task and handoff files #### 4. Work in bounded specialist lanes AI role. Agents inspect or implement their assigned parts, record changes and return findings for integration. Input: A shared project plan and the context relevant to each task. Output: Code changes, implementation notes and issues to resolve. Tools: Claude Code, OpenAI Codex, VS Code #### 5. Challenge the result My role. I check whether the product behaves as intended, question unsupported claims and ask for testing and review before the next phase. Input: The changed product, test output and the original business requirement. Output: A correction, a decision to continue or a narrower next task. Tools: Local application, Test results, Code review #### 6. Leave the next session a usable state System role. Project files retain the decisions, implementation state and remaining work outside the chat window. Input: The current result and its unresolved dependencies. Output: A durable starting point for the next development session. Tools: Markdown, Repository history, Project handoffs ### Context engineering I treat context engineering as a working responsibility. I need to know what the agent should understand, where that knowledge comes from and what the next person or role will receive. The procedure and the handoff are part of the engineering. #### Business purpose The real workflow, the intended user and the reason the feature matters. #### Grounding material Relevant project records, earlier decisions and repository evidence selected for the task. #### Project state What exists, what changed, what failed and which dependencies remain unresolved. #### Execution contract The specialist role, the task boundary, the expected output and the checks to perform. #### Correction and handoff The result, its evidence and the information the next agent needs before continuing. ### Implementation I work from the files and the current project state, then delegate analysis, implementation and review with task-specific context. I keep separate harness guidance for Claude and Codex because their tools and behaviour need to be understood in their own environment. Claude Code, OpenAI Codex, VS Code, Markdown, Git, PowerShell Module blueprints connect the business purpose to the implementation and outstanding work. A PowerShell handoff utility writes the sender, receiving agent, task, touched files, verification, risks and next actions into Markdown, with the Git branch and bounded working-tree state. Bounded execution packs name the objective, scope, interfaces, assumptions to reject, checks, blueprint updates and completion criteria. Specialist review is separated from implementation when another perspective is needed. Local testing and staged cloud work keep product validation separate from publication. Project context stays in inspectable files. It gives the next task a working memory without changing the model weights. ### Results #### Working output A file-based agent handoff. The implemented handoff utility carries task state and verification between tools, rather than relying on conversation memory. #### Context refinement March 2026. Living module blueprints, task-specific specialists and a source-based review before execution. #### Delivery refinement June 2026. Explicit builder and tester roles, local QA, end-to-end testing and security review before cloud publication. ### Next step I want another person to try the public context-and-handoff guide on one bounded change. Can they understand the project and continue the work without the original chat? Their experience will help me make the method easier to share with a team. [Context and handoff guide](/context-handoff.md) · [Read the project casebook](/project-stories.md) Drawn from dated working instructions and project artifacts. Client documents and original conversations remain private. ## Local model laboratory Model adaptation and provider routing. Experiments recorded in 2026. Experimental implementation and saved run artifacts. I wanted to understand how the working system could keep its own context and use different models. Alongside my everyday work with hosted models, I directed experiments with small instruction models, adapter training and model routing. ### The problem I wanted more flexibility in how a workflow uses models. Which parts could run through smaller local models? What changes with a domain-specific adapter? How should a request move between providers when its requirements change? Those questions gave the experiments their purpose. My question was about the architecture as much as the model. Could the workflow keep its knowledge and choose a suitable model, rather than rebuild everything whenever the model changed? ### Decisions I made #### Adapt an existing instruction model The lab uses parameter-efficient fine-tuning with LoRA adapters over pretrained Qwen2.5 models. This keeps the experiment focused on a task and a small trainable parameter set. #### Make the run inspectable Each saved run carries its training configuration, sample count, runtime, parameter counts and adapter artifact. I can return to the setup instead of relying on a chat summary. #### Separate model selection from dispatch The selector uses task sensitivity, provider availability and budget signals, and returns the reason for its choice. Dispatch is a separate operation that records failed provider attempts and the fallback chain. ### How the work moves #### 1. Define the job for the model My role. I frame the capability and portability question before committing to a model or a training run. Input: The workflow, task sensitivity and available hardware. Output: A bounded experiment and a candidate base model. Tools: Claude, Codex #### 2. Prepare instruction examples System role. The trainer loads prompt/completion pairs, formats them as instruction examples and tokenises them with a sequence-length limit. Input: A selected local JSONL training set. Output: A tokenised dataset for the experiment. Tools: Python, Transformers #### 3. Train a small adapter System role. The training code attaches low-rank adapters, configures rank and target projections, and uses gradient accumulation. Saved variants change the model size and adapter setup. Input: A pretrained instruction model, dataset and training configuration. Output: An adapter checkpoint and recorded training summary. Tools: PyTorch, PEFT, LoRA #### 4. Inspect the saved run My role. I review the configuration and saved artifacts to understand what ran and the scale of the experiment. I need a separate held-out comparison to assess task quality. Input: Runtime, parameter counts, logs and saved adapter files. Output: An inspectable experiment record and the next evaluation question. Tools: Run summaries, Adapter configuration #### 5. Choose and dispatch System role. Model selection returns a provider choice and the reason for it. The separate dispatch path records failed provider attempts and the fallback chain. Unit tests exercise routing decisions without paid inference. Input: A request, sensitivity classification and availability signals. Output: A provider choice or an explicit failure chain. Tools: Python, Provider adapters ### Context engineering I keep model configuration, task context and evaluation evidence separate so I can understand what each change does. An adapted model still needs a clear assignment and the right working context. #### Task What the workflow needs, why the task is sensitive and what result a person will accept. #### Training configuration Base model, adapter rank, target projections, learning settings and selected examples. #### Run record Saved adapter, parameter counts, runtime and training logs tied to the same experiment. #### Runtime request Task context and provider constraints assembled at inference time. ### Implementation My local lab contains Python training and routing code, saved PEFT adapters and configuration records for Qwen2.5 0.5B and 1.5B instruction models. I work with Claude and Codex on the engineering. The training workload uses PyTorch and Hugging Face tooling. Python, PyTorch, Transformers, PEFT, LoRA, Qwen2.5, Provider abstraction The trainer exposes adapter rank, alpha, target modules, learning-rate schedule, gradient accumulation and checkpointing as run parameters. One inspected 1.5B configuration targets query, value, output and down projections with rank 16 and alpha 32. The routing tests cover input validation, task sensitivity and provider-health signals. A budget signal in the router is not a hard spending limit. ### Results #### Saved experiment Qwen2.5 1.5B. The inspected adapter configuration records the pretrained instruction model and rank-16 adapter setup. #### Run scale 2,721 examples. The saved 1.5B run summary records two epochs and 8,257,536 trainable parameters. These are experiment dimensions, not an accuracy score. #### Routing check 13 tests passed. Model-selection unit tests rerun on 9 October 2026, with no paid-provider call or new training run. ### Next step I want to compare the base model and adapter on the same licensed held-out tasks. I will record acceptance quality, failure cases, latency and cost before deciding what role the adapted model could play in a working system. [Read the complete project casebook](/project-stories.md) · [Bounded model control patterns](/ai-labs/bounded-control-plane/) · [Inspectable public control-plane reference](https://github.com/Haris88m/servari-open) Training code, adapter configurations and saved summaries were inspected on 9 October 2026. Training data and weights remain private. The next held-out evaluation is planned work.