Reference Patterns

The following annotated examples illustrate effective context management across the three tiers and common task types within GLBNXT Workspace. Each pattern is designed to be adapted rather than copied verbatim.

---

Pattern 1: Single Document Analysis (Tier 1)

Use case: Analysing a supplier contract for key commercial terms.

You are a commercial analyst reviewing a supplier contract on behalf of a 
European enterprise procurement team.

Extract the following information from the contract provided and present it 
as a structured summary:

1. Contract duration and renewal terms
2. Payment terms and conditions
3. Service level commitments and remedies for non-performance
4. Termination rights and notice periods
5. Data processing and confidentiality obligations

For each item, quote the relevant clause reference alongside your summary.
If any item is not addressed in the contract, state "Not specified."

<contract>
[paste contract text here]
</contract>

Notes: The delimiter cleanly separates the instruction from the contract text. The structured extraction format prevents the model from producing a narrative summary when a structured one is needed. The "Not specified" instruction is an anti-hallucination measure that prevents the model from inferring terms that are absent.

---

Pattern 2: Multi-Document Comparison (Tier 1)

Use case: Comparing two versions of an internal policy document.

Compare the two policy document versions provided below. 

Identify:
1. Clauses that appear in Version B but not in Version A (additions)
2. Clauses that appear in Version A but not in Version B (removals)
3. Clauses that appear in both versions but with substantively different wording (modifications)

Present your findings in three labelled sections corresponding to the above categories.
For each finding, include the section reference and a one-sentence description 
of the nature of the change.
Do not summarise unchanged content.

--- VERSION A ---
[paste Version A here]

--- VERSION B ---
[paste Version B here]

Notes: Section delimiters make the two documents unambiguous to the model. The instruction to omit unchanged content prevents padding and focuses the output on what is actionable.

---

Pattern 3: Knowledge Base Query with Grounding Instruction (Tier 2)

Use case: Answering a compliance question from a knowledge base of regulatory documents.

Based on the documents in the knowledge base, answer the following question:

What are the mandatory notification timelines for a personal data breach under 
GDPR as they apply to our organisation?

Ground your response exclusively in the retrieved documents.
Cite the document name and section for each point you make.
If the retrieved documents do not contain sufficient information to answer 
the question fully, identify the specific gap rather than supplementing 
with general knowledge.

Notes: The grounding instruction prevents the model from mixing parametric knowledge with retrieved content, which would make it impossible to verify the source of each claim. The citation requirement creates an audit trail. The gap identification instruction is particularly important for compliance queries where completeness matters.

---

Pattern 4: Inline Context with Knowledge Base Background (Combined Tiers 1 and 2)

Use case: Drafting a response to a client query using both a current client email and background product documentation from the knowledge base.

You are a senior account manager at a European enterprise software company.
Draft a professional response to the client email below.

The knowledge base contains our current product documentation, pricing framework, 
and standard service terms. Use it as background reference.
The client email takes precedence over any generalised product descriptions 
in the knowledge base. Respond to what the client has specifically asked.

Keep the response to four paragraphs. Do not include marketing language.
Close with a clear proposed next step.

<client_email>
[paste client email here]
</client_email>

Notes: The precedence instruction establishes that the inline content (the specific client email) governs the response while the knowledge base provides background. This prevents the model from producing a generic product overview when a specific, personal response is needed.

---

Pattern 5: Structured Data with Analytical Context (Tier 1)

Use case: Analysing quarterly performance data with organisational context provided inline.

Analyse the performance data provided below. 

Context: This data covers the three European regional teams. 
The Q3 target for all regions was 15% growth. 
The organisation is in the second year of a three-year expansion plan 
with particular focus on the DACH market.

Provide:
1. A summary of which regions met, exceeded, or missed the Q3 target
2. An assessment of DACH-specific performance trends across the three quarters
3. Two to three observations about patterns in the data that warrant 
   further investigation

Do not speculate about causes. Describe what the data shows.
Flag any figures that appear anomalous without explaining them.

| Region  | Q1 Revenue | Q2 Revenue | Q3 Revenue | Q3 Target |
|---------|------------|------------|------------|-----------|
| DACH    | 420,000    | 455,000    | 498,000    | 490,000   |
| Benelux | 310,000    | 298,000    | 315,000    | 357,000   |
| Nordics | 275,000    | 302,000    | 344,000    | 318,000   |

Notes: The organisational context preceding the data gives the model the frame it needs to interpret the numbers meaningfully. The instruction to describe rather than speculate about causes is a precision constraint that prevents the model from producing plausible-sounding analysis that is not supported by the data. The anomaly flagging instruction is a useful signal for downstream review.

---

Pattern 6: Large Dataset Context via External Pipeline (Tier 3 Reference)

Use case: Querying a large internal knowledge base managed through an n8n RAG pipeline.

This pattern does not prescribe a specific prompt structure, because the prompt construction in Tier 3 workflows is typically handled at the workflow level rather than by the end user directly. The relevant disciplines are:

Query design. Queries submitted to an external pipeline should follow the same principles as Tier 2 retrieval queries: specific terminology, decomposed sub-questions, and explicit grounding instructions in the generation step.

Metadata filtering. If the pipeline supports metadata-filtered retrieval, use it. A query constrained to documents from the last twelve months, or to documents tagged with a specific classification or department, will produce more relevant results than an unfiltered semantic search across the full corpus.

Retrieval transparency. Workflows should be designed to surface which documents contributed to each response, either through citation in the model output or through logging in the workflow itself. Without this transparency, it is impossible to verify or audit the basis for a response.

Fallback handling. Every external pipeline should include explicit handling for the case where retrieval returns no relevant results. The model should be instructed to report this condition rather than generating a response from parametric knowledge, and the workflow should log the failed retrieval for review.

For implementation guidance, refer to the n8n integration documentation in the GLBNXT Platform section of this knowledge centre.

---

Closing Notes

Context management is the most consistently underinvested skill in everyday AI use. The gap between a user who pastes raw documents and hopes for the best, and one who selects, prepares, labels, and structures context deliberately, is one of the largest single determinants of output quality available to anyone using GLBNXT Workspace.

The tiered structure of this tutorial is not a hierarchy of sophistication where everyone should aspire to Tier 3. It is a map. Most knowledge workers will find that Tier 1 and Tier 2 cover the full range of their needs, provided they apply the preparation and structuring disciplines in Chapter 5 consistently. Tier 3 is the right answer for specific, large-scale, automated retrieval problems, and the wrong answer for everything else.

Start with the simplest approach that meets your requirements. Build the preparation habits before building the pipeline. The discipline of structuring context well is the foundation on which every more sophisticated capability is built, and it pays returns at every tier.