Zero-Trust Edge Enclave

AI advises on encrypted delivery, never sees the file

Comment

Zero-Trust Edge Enclave delivers an encrypted file only against the approved person's own token, so the file and its key are released only to the person the sender approved, and two people who share a name are told apart by employee number and a double confirmation. An AI adviser (NVIDIA Nemotron 3 Super 120B on Nebius Token Factory, or a local Nemotron 3 Nano 4B) advises on routing and follow-ups, by default from five pseudonymous fields, and by default never sees a name, a document or a key; fixed code validates every answer before anything acts. AI is used only where a deterministic design needs flexibility: the follow-up judgment call (wait, remind or escalate) and, as the simplest case of the same boundary, proposing a channel; who may receive a file, when a key is released and expiry stay in fixed code, with no AI. "Enclave" means a software boundary here, not a hardware TEE.

Friday, 5 p.m. A confidential board report has to reach one employee named 劉文祥. Two employees share that name. One wrong click is a breach.

Zero-Trust Edge Enclave guards that click by giving each part one job. Fixed code holds the authority. It decides who may receive a file (the sender tells the two apart by employee number and confirms twice), releases the key only against the approved person's own token, and validates every answer before anything acts. The AI adviser holds no authority and no data. It sees only coded fields and answers from a closed set: which already-approved channel to use, or whether to wait, remind or escalate. It cannot choose a recipient, read a document or touch a key. The model is used only where a deterministic design needs flexibility. Anything that must be exact (who receives a file, when a key is released, expiry) stays in fixed code with no AI, because using AI there would be over-engineering. The adviser covers what exact rules handle badly: judging whether to wait, remind or escalate (routing is close to an if today: the first approved channel on the first try, a pause otherwise) and, on the local build only (opt-in), reading a free-text note such as 業務那個姓劉的 into the find boxes (details below). Its room to act is a closed set and fixed code checks every answer, so an invented or off-list answer is rejected before anything acts.

This is a prototype of a two-outlet layout. In the intended deployment, data arrives first in a zone the organization controls, and only coded fields cross to a model. The outlet fits the scenario: an internal model (a local Nemotron 3 Nano 4B on that host), an external model (Nemotron 3 Super 120B on Nebius Token Factory), or both in a cascade. Switching outlets is configuration, not a rewrite, and the same fixed code validates the answer either way. Whether a model is used at all, and where it runs, follows the policy of the zone it serves: a closed intranet zone runs the local Nano on the same host, or no model (the default fixture calls none); a zone that may reach the internet can use the hosted Super. The model is a deployment choice, not a requirement. Where Token Factory helped: a 120B-class model was reachable over a plain OpenAI-compatible endpoint, so no GPU had to be provisioned and no bespoke client written, and the same request builder reaches the hosted 120B and a local 4B without branching, so swapping the model is one setting. No other Nebius service is used (no AI Cloud, Serverless Endpoint or Job). The hosted instance is the same code with Super, so judges can try it without installing anything. Encryption happens in the sender's browser and the server holds the wrapped key by design (not end-to-end; see Trust boundary). On the hosted demo the legacy paths that send more are off; /api/health shows it (legacyHostedAdviceOff: true).

Live record, 2026-10-30. Twelve real calls to Nemotron 3 Super on Nebius Token Factory, through the production request function; all 12 answers passed the fixed-code validator. The shipped setting (thinking off) answered in a median 0.93 s, inside the 5 s deadline; thinking on took a median 6.4 s, which is why it is not the default. A later full run of all 36 inputs gave 29 accepted, 5 refused by the validator, 2 past the deadline, median 1.9 s; a refusal or a timeout costs a late nudge, not a wrong recipient. Cost of one follow-up call, read from the provider's usage field on one separate call: under $0.0004. Full figures, caveats and the rerun command are under "What the model contributes, measured".

What the model contributes, measured (details under "Where the model actually decides something"; the Super, Nano and Ultra comparison recomputes offline, the 60-call prompt comparison is a recorded summary): because the adviser holds no authority, models can be swapped and compared on one fixed contract. The 36 inputs are the adviser's entire follow-up input space (4 time positions × 3 pickup states × 3 nudge counts), so the comparison is exhaustive, not a sample. On the same 36 inputs, Super escalated in 1 of the 12 inputs where the fixed table does on 2026-10-08, and in 0 of 12 on a second full run the evening of 2026-10-30 (29 of 36 answers accepted that time: the validator refused 5 and 2 calls passed the 5 s deadline); Nemotron 3 Ultra escalated in 11 of 12 on 2026-10-16. On Nebius Token Factory, Super answered 60 follow-up calls at p95 1.2 s with 100% reason coherence once the prompt was rewritten as lookup tables (88.3%, p95 1.7 s as prose; coherence means the validator accepted every reason as consistent with its input, not ground-truth accuracy). On the 36-input run of 2026-10-08, the median was 0.99 s hosted against 2.86 s for the local 4B on a Mac mini. Fixed code stays in charge whichever model answers, so a cautious model costs a late nudge, not a wrong recipient. The suite is 882 tests (CI skips 6 that need ffmpeg), and scripts/compare-followup-advisers.mjs reruns the comparison without a network or a key.

The 2026-10-30 live record in full. Nemotron 3 Super 120B on Nebius Token Factory, called through the production request function (requestFileAdvice: same prompt code path, request shape and validator; outside the worker and the spending cap) with five coded fields and enable_thinking:false, on the six near-deadline inputs with the pickup incomplete: 6 of 6 answers accepted by the fixed-code validator, 4 REMIND and 2 ESCALATE, 786 to 1,908 ms (median 928 ms). Accepted means consistent with its input, not that it matched the fixed table (the table is a yardstick, not ground truth; it escalates on all six inputs, and the model did on 2). The same six inputs with thinking on (not the default; 4,096 tokens, 60 s limit): 6 of 6 accepted, ESCALATE on 3, median 6,405 ms, every call above the 5 s production deadline. Twelve live calls in the comparison. Hosted calls are sent at temperature 1 (the local path uses 0), so a rerun will not repeat these exact figures, and six calls per setting cannot separate thinking from run-to-run variation. By design none of these answers can change who receives a file: fixed code resolves recipients from the approved snapshot. The record is docs/agent/fixtures/hosted-thinking-2026-10-30.json in the repository. Rerun with your own key: NEBIUS_API_KEY=... node scripts/compare-followup-advisers.mjs --cloud --yes-spend --thinking both.

Trust boundary

Where it runs. The backend and the key vault run on a host the organization controls and handle all the private data: the documents, the identities and the keys. By default the model, local or cloud, only ever receives coded fields (the opt-in NOTE_AI=local sends the sender's free-text note to the loopback model only), and its outlet is a configuration choice that fits the scenario. Local only (LOCAL_ONLY=true, the default) keeps every model request on the host: a local Nemotron Nano answers over loopback when COORDINATOR_PROVIDER=local_openai_compatible, and the default fixture calls no model. Hosted: Nemotron Super on Nebius Token Factory answers, and with LEGACY_HOSTED_ADVICE=off (set on the demo) only the five coded fields leave the host. (Two optional review modes, MATCH_AI_REVIEW and STATE_AI_REVIEW, are off unless set; when set to dual they also send 7 and 8 coded fields to the hosted model, in separate calls; the opt-in RECIPIENT_RANKING=vector sends names from the sender's own list to a local embedding model on loopback only.) Cascade (opt-in): the local model first, Super only if the local call fails or its answer is rejected, the same five fields, once per call. Switching is configuration, not a rewrite, and fixed code validates every answer either way. In every mode the file and its key are served only to a holder of an approved recipient's token and decrypted in that recipient's browser; the server can unwrap the key, and on the hosted instance both also pass through Cloudflare's TLS termination. The hosted instance is the same code in hosted mode, with Cloudflare terminating TLS; bearer tokens must travel over TLS.

Cost per outlet. The local Nano has no per-call fee but needs an always-on host (it has been run on a Mac mini, Apple M2 Pro, 16 GB; its power and hardware cost are not measured here). The hosted Super costs under $0.0004 per follow-up call at list prices (100 follow-up decisions cost under US$0.04), counted by the server against a USD 20 ceiling that is an estimate, not Nebius billing. The opt-in cascade pays for a hosted call only when the local call fails or its answer is refused. What leaves the host by default: nothing in edge mode (loopback only); in hosted mode the five coded fields; in the cascade the same five fields, and only after a local failure or a refused local answer; never the document, an address or a key.

Inside the boundary, operated by the organization in the intended deployment: the backend, the key vault, the audit trail and the fixed-code gate. Trusted, not hardened: the vault is a permission-checked file on the same host and process, with no KMS or key rotation. Each document has its own random key, wrapped under the host's vault key and released against one-use tickets; approval, revocation and expiry are checked at every ticket and key release. Revocation stops future releases; it cannot recall a key or a file already delivered. The server holds the wrapped key by design, so the operator is a trusted party: the control is who may receive, not secrecy from the operator, and a compromised backend is outside what this build protects. This is not end-to-end encryption, and "enclave" is a software boundary, not a hardware TEE.

Outside the boundary (it holds no key and no authority, even when a local Nano runs on the same host): the adviser model. In the delivery workflow, by default, it sees five coded fields and a fixed instruction, and nothing else: no document, name, address or key. No model decides who may receive: recipients are resolved by fixed code from the approved snapshot; a model can only choose among the already-approved channels, or pause, and every answer is validated and re-authorized before anything acts. For each delivery, the last 10 calls of each adviser are kept with what was sent, what came back (a refused answer keeps its reason code and a short fixed-form detail) and which outlet answered. The contract is small and fixed, five coded fields in and one answer from a closed set out, which is what lets an organization inspect it and place a strict gateway in front of a cloud model later.

Scope of this build. Tested on synthetic documents; notices are dry-run files written to a local outbox folder instead of being emailed. Each person keeps their own token file safe, as with any key.

Where this applies

Two places where the wrong person seeing one document is the actual harm. A sales director hands a price quote to two named account managers and later needs to show who received it. A hospital team hands a patient file to the two clinicians treating the case. Hospitals have leaned on mail and fax for this kind of exchange: about seven in 10 U.S. non-federal acute care hospitals used mail or fax to send or receive summary of care records in 2018 (ONC Data Brief No. 51).

This system enforces the approval for one document at a time: the selected people open it, and the record shows who did.

How to test (for judges)

Live demo: https://enclave.jace0423.com. The site uses a judge sign-in to protect the Token Factory budget. The hosted instance stays online, free of charge, through the end of the Judging Period. The sign-in and the role tokens are in the file ZTE-Judges.zip, attached to this submission under "Additional info" (open README.txt first). If you cannot open it, use the no-sign-in route at the end.

The 5-minute path (a computer for the manager, a phone for the employee):

  1. Open the site and sign in with the judge login. On the sender page, press Choose token file and pick the manager-sender token, then Choose document and pick a sample (in the zip, and in the repo under docs/demo/samples/). It is encrypted in your browser.
  2. Tick sales-a, leave sales-b unticked (the cover image shows the mirror case, sales-b approved and sales-a refused; the gate behaves the same either way), press Confirm 1: Lock draft and Confirm 2: Approve delivery. Under Package result, copy Recipient link (send this to the employee).
  3. Open that link on a phone. No judge sign-in is asked for. Choose the sales-a token, then Download from My inbox: the file decrypts in the phone's browser.
  4. Choose the sales-b token instead: nothing is waiting, and the same link shows ACCESS DENIED. Same company, a different person, not on this delivery.
  5. Open /audit.html with the manager token: the sales-b refusal is logged with no name, and Evidence chain shows the five pseudonymous fields Nemotron on Token Factory was given and which model answered.

Same-name recipients, the case this is built for: in the sender page's find box, type 劉文祥. Two employees match (north and south), and the page asks for the employee number instead of guessing. That ambiguous result counts as one failed match, so enter the employee number it shows next (a match resets the count). Seven failed or ambiguous matches in a row lock the sender, and the hosted demo shares one sender token among all judges, so please do not repeat the name search (a safety rule; the site owner clears a lock).

No sign-in route: clone https://github.com/jiarong0423/zero-trust-edge-enclave and follow Run Locally in the README (npm run setup:local, then SKIP_LOCAL_ENV=true LOCAL_ONLY=true npm run dev). Without a key, the local route uses a synthetic adviser.

Inspiration

The usual way to put AI into an internal workflow is to hand it the data and trust the prompt. In a regulated setting that option does not exist, and "the model was told not to look" is not a control.

So I narrowed the question. Instead of asking how much a model can do with full access, I asked the opposite: how much can it contribute when it is given almost nothing? Five pseudonymous fields. No document. No names. Not even the number of recipients.

What it does

Zero-Trust Edge Enclave delivers an encrypted document to an approved list of people, reports back which of them the server recorded downloading and acknowledging it, and prepares a reminder for the ones who did not.

  • The sender's browser encrypts the file with AES-GCM before anything leaves it.
  • Recipients are addressed by group codes regenerated on every revision, so a code never becomes a durable pseudonym.
  • Fixed code re-verifies identity, authorization, revocation, snapshot version, channel allowlist, expiry and retry budget before dispatch, and resolves recipients from the snapshot rather than from the model's answer.
  • Keys are wrapped per document and released against one-use tickets.
  • The sender picks a department and can untick anyone in it; the ticked people are frozen into an immutable snapshot and confirmed twice.
  • Identity and access are shown apart: a person can be verified as signed in and still be refused a document they were not approved for, and the refusal is logged against the task without naming them.
  • The sender can open an evidence chain for each delivery: what was approved, the private mapping, exactly what each model call was given and answered, and whom fixed code actually reached.
  • Per-recipient receipts tell the sender which of the N approved people downloaded, verified and acknowledged.

Where the model actually decides something

Two decisions run through the same contract, each with its own five-field projection and its own validator. Routing is given taskAlias, snapshotVersion, channels, state and attempts; follow-up is given taskAlias, snapshotVersion and the three codes below.

Routing is the simple one: given a prepared job and an approved channel set, a deterministic rule reaches the same answer. It is in the system because it is the simplest thing to check the boundary with. It is also the part where a fixed rule has to be rewritten whenever the channel set or the task states change, while the adviser takes them as input and fixed code still validates the answer.

Follow-up is the decision I would least want to hard-code. A delivery that must be acknowledged has gone out, nobody has collected it, and the deadline is still days away. Wait, remind again, or raise it to a person? That depends on how time remaining, reminders already ignored, and partial collection sit against each other, and the right answer differs between tasks.

For that decision the model is told, besides taskAlias and snapshotVersion, three things, none of which it can convert back into anything real:

  • timeCode — a position in the task's own window, so an identical value means a different hour on a two-day task and a two-month one
  • nudgeCount — 0, 1 or 2
  • pickupCode — PICKUP_NONE, PICKUP_SOME or PICKUP_ALL, never a count

It answers WAIT, REMIND or ESCALATE. It is never told who the recipients are or how many there are, and it does not decide who a reminder reaches — fixed code resolves that from receipts the model never sees, and silently passes over anyone who already collected.

Every answer is validated by fixed code before anything acts on it. If an answer fails validation, or the adviser cannot be reached, nothing is done on that check and it is tried again later: a minute apart for the first three tries, then at the midpoint of the time left, until the deadline. Once everyone has collected, the follow-up adviser is not asked at all.

What the comparison shows. On the same 36 inputs, with the default prompt, the models were cautious near the deadline: the local 4B answered WAIT in all 34 accepted cases, and the hosted 120B escalated in 1 of the 12 cases where the rule escalates on 2026-10-08 (0 of 12 on 2026-10-30). Two things change that without touching the boundary. An opt-in prompt profile makes the 120B match the rule on 20 of the 24 inputs the product can send. A larger model does too: Nemotron 3 Ultra on Token Factory escalated in 11 of the 12, at a median of 0.9 s, with 33 of its 36 answers passing the validator and 3 refused; it escalated in all six deadline-near cases with the pickup incomplete. Across the 24 inputs the product can send, it chose REMIND 2 times, against 8 for the table.

The prompt's effect on reason coherence and latency is the measurement above, a finding available only because the validator and the evidence chain score every answer. Under the default prompt Ultra gave the table's action on 17 of the 24 inputs the product can send and Super on 6 (2026-10-08 runs); with the opt-in directive prompt (tuned on those same 24 inputs, single runs) Super and the local Nano each match 20 of 24. No run shows a model beating the table, which stays the yardstick; the model proposes inside a contract that fixed code validates, so changing the model changes who proposes, never who may receive the file or whom a reminder reaches.

What ships. The shipped demo uses Super, and one variable, NEBIUS_MODEL_FOLLOWUP, switches the follow-up decision to Ultra while routing stays on Super. An opt-in fixed floor (FOLLOWUP_FLOOR=true, off by default) turns an accepted WAIT at the last window position with the pickup incomplete into an escalation; without it the validator checks that an answer is coherent, not that it is decisive. The lookup table (36/36 coherent, about 1 ms) is the yardstick across the same 36 inputs. Token Factory is the larger-model outlet for an organization that allows it and the cascade's second tier; an organization that does not allow it runs the same code on the local Nano.

On the local build only (NOTE_AI=local; off by default, and it sends the sender's free-text note, not five fields): the local Nano can read the sender's free-text note such as 業務那個姓劉的 and fill the find boxes (21 of 24 invented notes exactly right, against 13 for a keyword reader; the checks were written after seeing failures on the same set, so the number is optimistic; details in docs/agent/recipient-matching.md). The note goes only to the model on the same machine and is never stored; the model sees a closed vocabulary of departments and tags, never the people. It selects nobody; fixed code keeps only what the note supports and what belongs to someone on the authorization.

Where a model answer changes an outcome. It can pause a delivery, or delay the moment a person is told (a WAIT where ESCALATE was due; FOLLOWUP_FLOOR, off by default, closes that). No answer can add a recipient, release a key early, exceed the reminder budget or act after everyone has collected. In this build ESCALATE notifies no one: fixed code records FOLLOWUP_ESCALATED on the task, and the decision appears in the evidence chain.

How I built it

Prior work: the idea grew out of my earlier Shared Room MCP project; this codebase was started on 2026-09-07, after the hackathon opened on 2026-08-26. The repository still contains two legacy advice paths that send more than five fields; they are off on the demo (legacyHostedAdviceOff: true), and the cascade mode refuses to start unless they are off. The demo video's narration is an AI text-to-speech voice, and its opening and transition clips were generated with Google Veo.

node scripts/compare-followup-advisers.mjs (no key, no network) prints the lookup table beside the recorded Super, Nano and Ultra runs, recomputed per input; docs/agent/adviser-evidence-table-2026-10-29.md lists every quoted number with its record.

Two NVIDIA open models sit behind one contract. nvidia/nemotron-3-super-120b-a12b is served by Nebius Token Factory; nvidia-nemotron-3-nano-4b runs on the backend host through an OpenAI-compatible local runtime. The projections, the system boundaries, the output schemas and the validators are identical for both. Only the endpoint rule and the answer budget differ, so swapping a hosted 120B model for a local 4B one is a configuration change. They can also run as an opt-in cascade, tiered the way the track suggests: the small local model answers first, and the larger hosted one is asked only when the local call fails or its answer is refused by the validator (never by confidence, because the models return none). Each model call is recorded with the projection it was given, the validated answer or refusal, and which outlet answered, so the sender can check the boundary rather than take it on trust. "Edge" here means your own machine and network, and the local build runs on a Mac mini, not on NVIDIA edge hardware. The hosted demo runs the Token Factory outlet; the local outlet and the cascade run on the local build (LM Studio) and are shown in the video and the gallery. The app is one Node process calling Token Factory directly, with no Serverless Endpoint or Job.

Everything else is plain Node with no third-party runtime packages: one process serving the pages (sender, recipient inbox, audit, administration and the judge sign-in) and the API from one origin, JSON-backed stores, a hash-chained audit trail, and a local key vault that refuses a directory readable by anyone else.

The judging instance at https://enclave.jace0423.com runs the same code on a self-hosted Coolify server behind Cloudflare. It calls Token Factory at runtime, behind a sign-in and under a USD 20 spending cap enforced in code, because Token Factory documents no per-key limit.

Challenges I ran into

An empty response that was not empty. The local outlet failed two of six cases with what looked like a transport fault. Diagnostics showed HTTP 200, finish_reason: "length", and zero characters of content. The model had spent its entire answer budget reasoning: 511 of 512 tokens, with 1940 characters of partial deliberation sitting in a separate field. Raising the budget fixed those two — and then a second, different problem appeared. Under a JSON schema constraint the model answers correctly in 55 tokens and seven seconds, but LM Studio assembles that answer into message.reasoning_content and leaves message.content empty. My client read only content, so it recorded a failure against a request that had succeeded. Reading both fields and constraining the output took the local outlet from 5 of 6 at 8.4–35.7 seconds to 6 of 6 at 3.7–4.1 seconds, with completion tokens falling from 645–1089 to 64–73.

The runtime changed under me. The day before recording, the local outlet went from about four seconds to between seven and twenty-seven. My request and prompt had not changed; LM Studio had started applying the JSON schema only after the model's reasoning, so the constraint no longer suppressed it. Turning reasoning off per request (reasoning_effort: "none") brought it to 2.3–2.7 seconds, but greedy decoding turned out to matter too: without temperature: 0, three of eighteen answers picked a reason the lookup table rules out, and the validator refused each.

A prompt written as prose. The follow-up prompt explained each field's ordering and each reason code's precondition in two paragraphs of English. Measured over 60 hosted calls, the model chose the right action nearly always but gave a reason contradicting its own input 11.7% of the time — reporting "no pickup yet" against a fully collected delivery. Rewriting the same facts as two lookup tables, changing no value, removed those contradictions (numbers under Measured).

Numbers that were not the same kind of number. An early version labelled the window position TIME_1 through TIME_4; next to a numeric reminder count, the model read the two as one scale and proposed a reminder at the very start of the window. Words that count down what is left fixed it. A control with meaningless symbols scored 76.7% against 86.7–88.3% for every labelled form: what a model needs here is a value it already understands, not a distinct one.

Accomplishments that I'm proud of

The boundary is exercised by the test suite rather than only asserted. A one-off fuzz run on 2026-09-18 (script not kept; the same invariants are asserted on fixed inputs in scripts/delivery-followup*.test.mjs) of 40,000 projections and 2,400 worker ticks against advisers returning hostile and malformed advice found zero invariant violations: no identity, group code, recipient count or clock value ever reached a projection, no accepted advice left the allowlists, the reminder budget was never exceeded, and a fully collected delivery was never chased.

The full suite is 882 tests (all 882 pass with ffmpeg installed; GitHub Actions runs it on every push to main and on pull requests, and skips the 6 that need ffmpeg). Three local security scanners ran on the published tree for the review dated 2026-09-27; the results are in SECURITY_SCAN_EVIDENCE.md.

What I learned

The small local model was slower than the hosted large one. With reasoning turned off, the 4B local outlet takes 2.3–2.7 seconds on the 09-24 runtime (2.6–7.8 s, median 2.86 s, on the current one) where the hosted 120B takes 0.75–1.5 s (median 0.99 s, 2026-10-08). That inverts the usual assumption behind running the small one locally. And a local runtime can change underneath you: measure it again before you rely on an old number.

Where a model is not needed, say so. Routing would work as an if. Saying that plainly cost nothing and made it obvious which decision actually earns its place.

Constraining a model is a design position, not a limitation. Once the adviser could only see five fields and could only answer from a fixed set, the interesting work moved to what happens around it — re-verification, abstention handling, receipts, and who a reminder is allowed to reach.

What's next

Real transport instead of a dry run. Independent key custody, beyond the current server-held key boundary. Moving the adviser call across a controlled one-way or gateway-mediated transfer between a closed network and a cloud model: not built here; the five-field contract is what would make it feasible. And running the local outlet on hardware built for local inference, which the dual-outlet contract already makes a one-variable change.

Judging criteria, with where to look. Technological Implementation: effective here means fitted to the scenario. In a closed intranet zone the right amount of model is a small local one, or none; in a zone that may reach the internet it is the hosted Super. Both outlets run through one contract, with 882 tests, the live record and cost per call above, and the evidence table showing what each outlet adds. Design: the two-role flow (employee phone and evidence page in the gallery; the sender page in the video), the employee's phone inbox (nothing to install; the file decrypts on the device) and the trust-boundary diagram. Potential Impact: two concrete scenarios (a price quote to two named account managers, a patient file to two clinicians), stated with what the prototype does not claim (not end-to-end, synthetic data only). Quality of the Idea: deterministic control. Fixed code decides who may receive a file, when a key is released and when it expires; by default the model gets five coded fields and can propose a channel or slow a delivery, never widen it: it cannot add a recipient, release a key early or extend an expiry, and it picks from a closed set of answers, every routing and follow-up answer passes a validator before anything acts, and the last ten routing and follow-up calls of each kind on a delivery, refused answers included, are kept in the sender's evidence chain (the opt-in reviews leave audit codes only). The measurements show where the model helps and where a lookup table does as well.

Built With

Share this project:

Updates

Submission history