• 

  NESTOR running live with GPT-5.6 Sol on the production deployment.

• 

  Deterministic, application-owned panels explain what changed and compare both response modes.

• 

  Disabling a signal removes it from the context supplied to NESTOR and from the visible attribution layer.

• 

  The user can inspect and suppress any synthetic Human Context Passport signal before generation.

• 

  Two independent GPT-5.6 calls compare a context-free Baseline with a task-scoped NESTOR response.

NESTOR

Personalisation before the first prompt — with the human in control

Why I built it

NESTOR began with a practical observation from my own use of AI.

An advanced AI agent may reason effectively from the first prompt, but it does not yet know how a specific person prefers to communicate, weighs risk, structures decisions, manages uncertainty, or responds to competing priorities.

Most personalisation develops gradually through repeated conversations, accumulated memory, and probabilistic inference.

I wanted to test a different starting point.

In an earlier private experiment, I initialised my personal AI agent with structured outputs generated by Soft Screen X-RAY®, PYLI NET’s AI-independent mathematical framework with deterministic results.

I did not train or modify the base language model.

I did not ask AI to infer, measure, score, or diagnose my personality from my messages or behaviour.

Instead, I supplied consented and structured human context before the first substantive prompt.

The improvement in relevance was immediate enough to raise a product question:

Can this experience become repeatable, transparent, measurable, privacy-preserving, and fully controlled by the person using the AI?

That question became NESTOR.

What NESTOR does

NESTOR receives a minimal Human Context Passport generated independently of the language model.

The passport is not:

• a conversation transcript,
• a behavioural-surveillance record,
• a clinical assessment,
• a diagnosis,
• or a complete and permanent definition of the individual.

It is a structured collection of user-controlled signals intended to improve collaboration between a person and an AI agent.

Soft Screen X-RAY® can generate deterministic results across predefined dimensions such as:

• personality structure,
• professional trust,
• soft skills,
• behavioural competencies,
• risk posture,
• and non-clinical readiness.

The proprietary Soft Screen X-RAY® mathematical framework remains entirely independent from the AI system.

For this OpenAI Build Week prototype, the Human Context Passport is entirely synthetic.

It contains:

• no real personal data,
• no names or contact details,
• no raw questionnaire responses,
• no identity-mapping information,
• no clinical or diagnostic information,
• and none of the proprietary mathematical logic behind Soft Screen X-RAY®.

The synthetic demonstration passport contains only the signals required to demonstrate the concept:

• direct, structured communication,
• calibrated-cautious risk posture,
• systems-synthesis strengths,
• relationship-building strengths,
• avoidance of premature commitment,
• and preference for decision support using explicit criteria and thresholds.

The user can inspect these signals and enable or disable each one before generating a response.

The browser sends only:

• the business question,
• and the IDs of the enabled signals.

The server validates those IDs, retrieves the corresponding synthetic context, and constructs a minimal, task-scoped context brief.

The Baseline call receives only the business question.

The NESTOR call receives the same business question together with only the enabled, server-controlled synthetic context signals.

Privacy and identity separation

The public Build Week demonstration uses synthetic data only.

For a future production architecture, I defined a stronger principle:

A person may be securely authenticated while their identity remains undisclosed to the AI layer.

In production, Soft Screen X-RAY® would assign each Human Context Passport an opaque, non-semantic identifier.

That identifier would not encode:

• a name,
• an email address,
• a telephone number,
• an age,
• a gender,
• a location,
• or any other directly interpretable personal information.

The natural person would authenticate securely within a private context environment and activate their own Human Context Passport.

The person would retain the real-world meaning of references relating to:

• themselves,
• family members,
• trusted people,
• professional relationships,
• and other relevant circumstances.

NESTOR and the language model would not require access to that identity mapping.

The AI layer would receive neither names nor the real-world identities behind the opaque references.

It would receive only the minimum user-authorised context required for the current task.

For example, the model may receive a task-relevant contextual signal such as:

“A close family dependency makes irreversible financial commitment especially consequential.”

It does not need to receive:

• the name of the family member,
• their contact information,
• the precise nature of the relationship,
• or the Human Context Passport identifier itself.

The intended production architecture therefore separates three functions:

1. Authentication
   Confirming that the user is authorised to access the private context environment.

2. Identity mapping
   Preserving the private real-world meaning of opaque IDs and personal references.

3. Context authorisation
   Determining which specific signals the user permits NESTOR to use for the current task.

This is a privacy-by-design approach based on:

• data minimisation,
• pseudonymisation,
• purpose limitation,
• identity separation,
• task-scoped processing,
• and user control.

NESTOR does not claim that pseudonymisation automatically removes GDPR obligations or converts personal data into anonymous data.

The purpose of the architecture is to reduce unnecessary exposure by allowing the AI layer to receive relevant contextual meaning without requiring direct identity disclosure.

The demonstration

The live demonstration uses the same consequential business question in two modes:

“I have been offered a promising international partnership that requires significant investment and immediate commitment. How should I decide?”

The two modes are:

1. Baseline mode
   GPT-5.6 receives only the business question and neutral decision-support instructions.

2. NESTOR mode
   GPT-5.6 receives the same question, the same model settings, and only the enabled synthetic Human Context Passport signals.

Both responses are produced through independent, parallel OpenAI Responses API calls.

The Baseline response provides sound but general decision support.

The NESTOR response adapts:

• communication,
• decision framing,
• prioritisation,
• safeguards,
• and next steps

to the enabled Human Context Passport signals.

Depending on which signals are active, the NESTOR response may emphasise:

• staged rather than irreversible commitment,
• evidence gates before investment,
• bounded downside exposure,
• structured validation periods,
• collaborative negotiation,
• explicit no-go conditions,
• clear decision criteria,
• and concrete next actions.

The user can disable a signal and regenerate the comparison.

Disabling a signal removes it from:

• the context supplied to NESTOR,
• and the visible Context Used attribution.

This does not mean that the model can never independently use a similar concept through its general reasoning.

The demonstration includes three transparent, application-owned panels:

• Context Used shows which enabled signals were supplied to NESTOR and the intended role of each one.
• Personalisation Delta explains what changed and identifies the deterministic context rule associated with that change.
• Evaluation compares the Baseline and NESTOR modes through a predefined, application-owned rubric.

These explanatory panels are not generated by GPT-5.6.

I deliberately kept them outside the language-model response and implemented them through deterministic application logic so that the personalisation process remains visible, controlled, and auditable.

After production reliability hardening, the deployed application completed five consecutive successful live comparisons, including controlled tests in which different Human Context Passport signals were disabled.

The production responses reported the returned model identifier as gpt-5.6-sol.

How it works

The prototype contains six functional layers.

1. Synthetic Human Context Passport

A typed JSON fixture represents the synthetic passport used in the public demonstration.

The passport is validated through strict Zod schemas before use.

2. User-controlled signal selection

The user can inspect the available passport signals and enable or disable each one.

Only the IDs of enabled signals are submitted from the browser.

3. Server-side context compilation

The server validates the selected IDs and retrieves the corresponding signals from a server-controlled source.

It constructs a minimal context brief containing only:

• the signal ID,
• a human-readable label,
• a concise summary,
• and its permitted application to the current task.

4. Independent GPT-5.6 comparison

NESTOR performs two independent OpenAI Responses API calls in parallel.

Both calls use:

• the same GPT-5.6 model configuration,
• the same reasoning effort,
• the same output-token limit,
• the same business question,
• strict Structured Outputs,
• and store: false.

The only permitted input difference is:

• the Baseline call receives no Human Context Passport information,
• while the NESTOR call receives only the enabled synthetic context brief.

5. Strict validation and reliability controls

Every model response is validated against strict JSON Schema and Zod contracts.

Before parsing the output, the application checks:

• whether the response completed successfully,
• whether it was incomplete,
• whether the output-token limit was reached,
• whether a content filter interrupted the response,
• whether the model refused,
• whether message content is missing,
• whether the output is empty,
• whether the JSON is malformed,
• whether the structured response violates the schema,
• and whether the final comparison object is valid.

The final production settings are:

• Model configuration: gpt-5.6
• Returned production model identifier: gpt-5.6-sol
• Reasoning effort: low
• Maximum output-token limit: 4000
• Internal timeout: 60 seconds
• Server-route maximum duration: 90 seconds
• Storage: store: false

Safe diagnostics identify the failure stage without logging:

• prompts,
• questions,
• Human Context Passport content,
• personal identifiers,
• API keys,
• authorisation headers,
• raw model outputs,
• rejected values,
• or sensitive stack traces.

If a live API request cannot be completed, the static demonstration remains available.

6. Deterministic transparency and evaluation

The Context Used, Personalisation Delta, and Evaluation panels are generated through deterministic application logic.

This keeps the explanation of personalisation outside the probabilistic model response.

How Codex and GPT-5.6 were used

I used Codex as the development agent throughout the Build Week workflow.

It helped me:

• scaffold the Next.js and TypeScript application,
• define the typed Human Context Passport schema,
• implement the server-side Responses API route,
• build the side-by-side comparison interface,
• create deterministic context and evaluation logic,
• develop automated tests,
• inspect production failures,
• diagnose schema-validation defects,
• strengthen Structured Output handling,
• improve reliability and safe observability,
• and prepare reviewable GitHub pull requests.

GPT-5.6 is used only to generate the two structured decision-support responses:

• the context-free Baseline response,
• and the context-aware NESTOR response.

GPT-5.6 does not:

• generate the Human Context Passport,
• decide which signals are enabled,
• infer or score personality,
• diagnose the individual,
• receive direct identity information,
• or generate the deterministic Context Used, Personalisation Delta, and Evaluation panels.

The central product and governance decisions were mine.

I defined:

• the product hypothesis,
• the relationship between NESTOR and Soft Screen X-RAY®,
• the permitted Human Context Passport fields,
• the privacy boundaries,
• the distinction between identity and context,
• the user-control principles,
• the evaluation criteria,
• the permitted claims,
• and the limits of the demonstration.

I reviewed the generated code, tested the production behaviour, inspected failures, decided which corrections were acceptable, and retained responsibility for the final submission.

Soft Screen X-RAY® remains independent from the AI system.

Challenges and what I learned

The hardest challenge was not producing an impressive response.

It was making the comparison:

• reliable,
• strictly validated,
• transparent,
• privacy-aware,
• and robust enough for a live demonstration.

The first production deployment exposed a strict-schema issue.

The Baseline response correctly returned an empty appliedContextIds field, but the application later rejected that field when constructing the public Baseline result.

After that defect was corrected, intermittent invalid Structured Output failures revealed that the application needed to inspect the complete Responses API status before parsing the output.

The final reliability implementation added:

• response-completion checks,
• incomplete-output detection,
• content-filter and refusal handling,
• aligned JSON Schema and Zod constraints,
• a larger output allowance for reasoning and Structured Output,
• longer execution limits,
• strict final-result validation,
• privacy-preserving diagnostics,
• and deterministic fallback behaviour.

The final production build then completed five consecutive successful live comparisons.

The main lesson was clear:

A production AI system needs more than a capable model. It needs deterministic contracts, explicit boundaries, observability, fallback behaviour, privacy controls, and human-owned evaluation.

What makes NESTOR different

NESTOR does not use AI to infer, measure, score, or diagnose the person.

The Human Context Passport is generated independently under predefined deterministic rules.

The passport is not treated as:

• a permanent truth,
• a fixed label,
• or a complete definition of a human being.

It is a transparent and contestable starting context.

The user decides which signals are available for a task and can suppress any signal before generating an answer.

The production concept also separates personal identity from contextual meaning.

NESTOR does not need to know the person’s name in order to provide more relevant support.

The innovation is not another chatbot personality.

It is a reusable and governed human-context layer capable of initialising different AI agents from Day One while keeping:

• identity,
• context selection,
• and decision authority

under human control.

Who it is for

The initial use case is professionals, founders, advisers, and executives who use AI to support complex decisions and need relevant guidance before months of conversational history have accumulated.

The same architecture could later support:

• professional coaching,
• onboarding,
• education,
• leadership development,
• personal knowledge systems,
• and enterprise copilots,

subject to appropriate:

• legal safeguards,
• security controls,
• domain-specific restrictions,
• and independent validation.

Why it matters

NESTOR explores a focused hypothesis:

Better personalisation may depend not only on more capable language models, but also on better initial human context.

More importantly, that context does not need to require direct identity disclosure to the AI layer.

NESTOR provides personalisation through user-authorised context, rather than through identity disclosure or AI-based personality inference.

NESTOR does not decide for the person.

It does not replace professional judgement.

It helps the person receive more relevant, explainable, privacy-aware, and controllable support from the first prompt.

Built With

• api
• codex
• css3
• github
• gpt-5.6
• html5
• javascript
• json
• next.js
• node.js
• npm
• openai
• react
• responses
• serverless
• tailwind
• typescript
• vercel
• vitest
• zod